The MCP roadmap for 2026: scale, tasks and enterprise readiness

On 9 March, the lead maintainer of the Model Context Protocol, David Soria Parra, published the roadmap for MCP in 2026. It is not a list of release dates. It names four priority areas, and proposals that fit those areas will be reviewed faster than others. For integration teams, the list is a good guide to what will change in MCP over the coming year.

The four priorities

1. Transport and scale. Most production use of MCP runs over Streamable HTTP. Today, a server often has to keep the state of each session, which makes it hard to run many copies of the same server behind a load balancer. The goal is a transport and session model where servers can scale horizontally without holding state. The roadmap also points to a standard way to describe a server through a .well-known address, so clients and registries can see what a server offers without opening a connection first.

2. Agent communication. MCP has an experimental primitive called Tasks, used for work that takes longer than a single call. Early use has revealed gaps: what should happen when a task fails temporarily, and how long should results be kept? The roadmap wants clear rules for retries and expiry.

3. Governance of the project. Today, every change proposal must be reviewed by the core maintainers, which has become a bottleneck. Working groups with expertise in specific areas will be given more responsibility for evaluating proposals.

4. Enterprise readiness. Companies that run MCP internally need audit trails, login tied to their own identity provider (SSO), clear rules for how gateways should behave, and configuration that can be moved between environments. The maintainers want to solve most of this through extensions, not by making the core specification heavier, and they invite people with enterprise experience to help.

What it means for integration

The roadmap confirms what many integration teams have discovered: MCP works well on a developer’s machine, but running it at scale in production is harder.

• Stateless scaling fits the way integration platforms and API gateways already work. When MCP servers no longer need sticky sessions, they can be run and scaled like other APIs.
• Server descriptions at a fixed address make it easier to build catalogues and registries of approved MCP servers.
• Tasks with clear retry rules move MCP closer to what integration developers expect from asynchronous processes and queues.
• Audit and SSO are requirements most companies have for any integration. That they are now on the official list is a sign that MCP is growing up.

What you should do now

Do not wait for the roadmap before starting. Build MCP servers behind a gateway you already control, log calls, and use your own identity solution for access. Then you are ready when the specification catches up, and you have not bound yourself to a solution that disappears.

Also ask your iPaaS vendor how it follows MCP development: how quickly it supports new versions, and whether it takes part in the working groups.