When Anthropic introduced the Model Context Protocol in November 2024, most developers were skeptical. Another standard? The graveyard of AI integration specs was already crowded. Sixteen months later, MCP is natively supported by Anthropic, OpenAI, Google, and Microsoft, ships in millions of daily active developer tool sessions, and has just published a serious 2026 roadmap from its lead maintainer.
The roadmap — written by David Soria Parra and published March 9, 2026 — reads less like a product announcement and more like a protocol growing up. Here’s what it says and what you should care about.
Why the Roadmap Format Changed#
Previous MCP roadmaps organized work around release milestones: version X will include Y. That framing made sense when a small Anthropic team owned the entire spec. It no longer fits.
MCP is now a multi-company open standard under the Linux Foundation. The community has grown large enough that no small group of core maintainers can realistically review every proposed spec change — and organizing work around milestones that one team controls doesn’t scale.
The 2026 roadmap switches to Working Groups and Interest Groups as the primary vehicle for protocol development. Instead of “version 2.0 ships in Q2,” you get “the Transport WG owns Streamable HTTP improvements and drives its own timeline.” SEPs (Spec Enhancement Proposals) in the four priority areas get expedited review. Everything else goes into the queue.
This is how successful open standards work. It’s a meaningful structural maturation.
The Four Priority Areas#
Core maintainers ranked candidate areas and landed on four that will receive the most attention and the fastest SEP reviews in 2026.
1. Transport Scalability#
Streamable HTTP gave MCP a production-ready transport — the right call to move away from the original SSE-only approach. But running it at scale has surfaced real gaps.
The current spec assumes you can maintain a session with a single server instance. The moment you put a load balancer in front of your MCP server, things break in subtle ways. The roadmap proposes evolving Streamable HTTP to run statelessly across multiple server instances with proper session creation, resumption, and migration semantics.
Alongside that, the working group is designing MCP Server Cards — a standard for exposing server metadata at a .well-known URL so registries can discover what a server does without actually connecting to it. Think of it as a capabilities manifest: what tools does this server expose, what scopes does it need, what transports does it support.
For teams deploying MCP servers in production today, stateless transport isn’t optional. This work is overdue.
2. Agent Communication (Tasks)#
MCP currently lets clients start asynchronous Tasks — fire-and-forget agent jobs. But early production deployments have revealed that the lifecycle semantics are underspecified.
What happens when a task fails? When should a client retry? How long are completed results retained before expiration? The current spec leaves these as implementation details, which means every team is making up their own answers — and interoperability breaks.
The roadmap proposes clearer lifecycle rules for tasks: defined retry behavior for failed jobs, explicit retention policies for completed results. This sounds like plumbing. It is plumbing. It’s also exactly the kind of thing that separates a toy protocol from one you’d bet production systems on.
If you’re building agentic workflows where a Claude Code session hands off tasks to background MCP agents, this directly affects you.
3. Governance Maturation#
This is the least flashy priority area and arguably the most important for the long-term health of the protocol.
Right now, every SEP must be reviewed by the full group of core maintainers regardless of what it affects. A change to the TypeScript SDK’s error handling and a change to the core spec transport layer go through the same full-council review. That doesn’t scale — maintainer time gets spread thin, and contributors outside the core group have no clear path to taking on more responsibility.
Two SEPs are already in flight: a Contributor Ladder SEP that defines progression from community participant to WG lead to core maintainer, and a delegation model that lets Working Groups with a proven track record accept SEPs within their own domain without requiring a full core-maintainer vote.
The goal is a protocol that can continue growing without creating a bottleneck at the top. For developers contributing to MCP tooling, this means your SEPs may move significantly faster once WG delegation is in place.
4. Enterprise Readiness#
Enterprises are deploying MCP at scale and hitting walls the spec doesn’t address.
The three specific gaps called out in the roadmap:
- Audit trails and observability: Who called what tool, when, with what arguments? Enterprises need logs that satisfy compliance requirements. MCP currently has no standard way to emit or structure this data.
- Enterprise-managed auth: SSO-integrated flows where identity comes from the organization’s IdP, not a developer-managed OAuth app. The current auth model works fine for individual developers; it’s the wrong shape for enterprise IT.
- Gateway and proxy patterns: Many enterprises route all external API traffic through security gateways. MCP needs defined semantics for how an intermediary sits between a client and server without breaking the protocol.
Importantly, the roadmap notes that most enterprise readiness work will land as extensions rather than core spec changes. Enterprise needs are real, but the solution shouldn’t make the base protocol heavier for everyone who doesn’t need it. Smart call.
SDK Ecosystem Status#
The roadmap doesn’t exist in isolation from the SDK implementations. As of March 2026:
- TypeScript SDK v1.27.1 is the reference implementation with the most active conformance work. If you’re building MCP servers, start here.
- Python SDK v1.26 is tracking close behind. The gap between TypeScript and Python has narrowed significantly since 2025.
- OpenAI Agents SDK v0.12.5 introduced MCP retry and error normalization — essentially implementing the task lifecycle rules the spec is still formalizing.
- Google ADK v2.0 pre-release added a structured Task API for agent-to-agent delegation.
The multi-vendor SDK convergence is one of MCP’s strongest signals. When OpenAI’s own agent SDK ships MCP support and invests in conformance, the “this is just an Anthropic thing” concern disappears.
What This Means If You’re Building on MCP Today#
If you’re integrating MCP into your tools now, a few practical implications:
Build with Streamable HTTP. SSE-based transport is legacy. The entire roadmap’s transport work is anchored on Streamable HTTP. If you’re starting a new MCP server, don’t touch SSE.
Don’t design around session stickiness. The stateless transport work is coming, and servers that assume a single-instance session will need to be refactored. Design for statelessness now.
Expect the TypeScript SDK to move fastest. It’s the reference implementation. New features land there first. If you’re writing Python and something feels unsupported, check whether it’s in the TypeScript SDK yet.
Watch the Governance WG. Once the delegation model ships, SEP review times for targeted spec areas should drop significantly. If you have protocol proposals in flight, timing a submission for after delegation is in place may get you faster review.
The Bigger Picture#
MCP moved from zero to multi-company open standard in roughly 16 months. The 2026 roadmap reads like a protocol that’s survived contact with real production workloads and is now doing the less glamorous work of growing up: governance, observability, enterprise auth, stateless transport.
The protocols that win aren’t always the most elegant. They’re the ones that show up for the boring production-readiness work after the initial hype fades. MCP appears to be doing exactly that.
Sources: