What data am I missing to get from a MVP development company?

Does this project have any 'business' behind it? I only see mentions of technical stuff, but there's always business (of some kind) behind. So I see the lack of 'functional' artifacts in this list. Follow my comments inline:

1- story map.

It must be seen as paramount to keep the traceability between business requirements and the stories, into which the high-level business requirements were transformed, then to functional + non-functional requirements, created from them. I'm speaking from the experience of enterprise projects (in the role of a business analyst), where it was our own pain to track the traceability (more intently than even the Customer does it), so I do believe this should be provided in the opposite direction (to outsource).

3- Technical specifications i.e. language, database, DevOps & development methodology.

Same note as for the 1st bullet: the lifeline is 'High level requirements (business) - features/stories - functional + non functional requirements. There should be functional requirements (technical specifications only support, but do not provide the functionality, which is going to solve the business requirements). This is also does not seem a task for outsourcing, because you, internally, are the generator of requirements.

To start a project first ensure you understand what your business needs. Then if you already know which outsource company you're going with:

1. Create pictures or text description of what needs to be done with the terminology that's important to the product. Define both what final product should do and what you expect from MVP.
2. Send it to the software company and ask then to review it and research the terminology. Terminology is important so that the engineers know what to search for on the internet. And of course it's required for them to understand you and your stakeholders.
3. Have a kick off meeting with you (and stakeholders ideally) where you explain the intent of the product verbally and answer their questions.
4. Then ask them to prepare mockups and draw some workflow diagrams.
5. Have another review meeting with them to go through whatever they prepared, answer new questions.
6. Now they're ready to estimate and propose technologies.

What you need from them:

• Languages, tools and technologies that they will use. Check with your IT that they can support such technological stack.
• More detailed mockups that you and your stakeholders agree with
• Human resources that will work on different stages of the project. And how much they cost of course. If you want to be Agile you probably don't want to make it a fixed price project, but of course you'd be interested in how much you'll have to pay every month (year?).
• Rough plan with high-level features and their sequence. You don't want the story mapping - it's too detailed and takes too much efforts (and at the same time will get outdated very soon).
• Same goes for ERD - it won't help at this stage of the project. Unless you want to go through the diagrams and explain the team where they misunderstand the domain.

If they're going to use their own infrastructure for development somewhere in the middle of the development you'll need them to set up (or write instructions to set up) same infrastructure on your side.