Sixteen months after its open-source release, MCP has an official roadmap. Not the usual “Q2: Feature X, Q3: Feature Y” list, but four priority areas owned by Working Groups that set their own timelines. That’s a signal: MCP is behaving like an industry standard now, not a startup project.
If you’ve read our posts on the MCP Maturity Model and Skills vs. MCP, you’ll see the same themes — the roadmap now puts an official label on the pain points we already sketched. The rest covers what changes in practice — and where gaps remain.
What the roadmap says
David Soria Parra, Lead Maintainer, published the roadmap on March 9. Four priorities, each assigned to a Working Group.
1. Transport: Stateless and discoverable
Streamable HTTP enabled remote MCP servers, but production exposed the limits: stateful sessions clash with load balancers, horizontal scaling requires non-standard workarounds, and there’s no way to discover a server’s capabilities without connecting to it.
The planned fix has two parts. First: evolve Streamable HTTP to run statelessly, with defined mechanisms for session creation, resumption, and migration. Second: MCP Server Cards (SEP-1649), a .well-known URL standard where servers expose structured metadata. A simple HTTP GET to /.well-known/mcp/server-card.json is enough to read capabilities — no full MCP handshake (initialize, capability negotiation, session state) required.
Server Cards are interesting because they could attack the token bloat problem at its root. If a client knows what tools a server has before connecting, it can filter instead of loading everything. Same progressive disclosure pattern we covered in Skills vs. MCP — one layer deeper in the stack.
Target: finalize SEPs in Q1 2026, potential spec release in June 2026.
2. Agent communication: Tasks maturing
The Tasks primitive (SEP-1686) shipped as experimental. It enables a call-now-fetch-later pattern for long-running operations. Production usage revealed gaps: What happens on transient failures? Who decides whether to retry? How long do results persist after completion?
These sound like details, but for agentic workflows they’re exactly the questions that separate demo from production. The Agents Working Group will iterate: release experimentally, collect production feedback, refine.
3. Governance: Less bottleneck, more delegation
Currently every SEP requires full Core Maintainer review regardless of topic specialization. That doesn’t scale.
The Governance Working Group will define a Contributor Ladder (community participant through Core Maintainer with explicit promotion criteria) and a delegation model where trusted Working Groups can accept SEPs within their domain independently. Plus a charter template for every Working Group with scope, deliverables, and retirement conditions, reviewed quarterly.
This is the less glamorous but probably most important change. A protocol that depends on a handful of maintainers has a bus-factor problem. The formalization via SEP-1302 (Working Groups) and SEP-2085 (succession and amendments) signals they’re serious.
4. Enterprise readiness: Intentionally left open
The fourth priority is deliberately vague. Audit trails, SSO integration (away from static client secrets, toward Cross-App Access patterns), gateway behavior (authorization propagation, session semantics), configuration portability.
Notable: An Enterprise Working Group doesn’t exist yet. The roadmap explicitly says practitioners should drive this work. And most output should land as extensions, not core spec changes.
That’s a deliberate design choice. The core spec stays lean, enterprise features come as opt-in extensions. Whether this works in practice remains to be seen. The extensions system is still young (MCP Apps as the first GA extension since January 2026), but the three-layer approach (core spec, supporting projects, extensions) is clean.
What’s on the horizon
Beyond the four priorities, the roadmap lists lower-priority topics for community-driven work:
- Triggers and event-driven updates: Webhooks instead of polling/SSE
- Result type improvements: Streaming for incremental results, reference-based results for large payloads
- Security: DPoP (SEP-1932), Workload Identity Federation (SEP-1933), least-privilege scopes, a vulnerability disclosure program through the Linux Foundation
- Extensions ecosystem: A Skills primitive for composed capabilities, first-class extension support in the registry
In parallel, validation infrastructure is taking shape: conformance test suites, SDK tiers (SEP-1730) signaling which SDKs track the spec most closely, and reference implementations.
What the roadmap reveals about MCP’s state
The roadmap is unusually honest about production gaps. Streamable HTTP has “production pain points.” Tasks has “gaps revealed by production usage.” Auth is still the hardest unsolved problem. These aren’t weaknesses of the roadmap. They’re its strength: it describes the actual state, not a marketing vision.
But there’s legitimate criticism. Perplexity CTO Denis Yarats said publicly in early March that Perplexity is moving away from MCP internally. His argument: tool descriptions consume 40-50% of the context window before agents do any work. One team reported 143,000 of 200,000 tokens (72%) consumed by tool definitions alone. Benchmarks show 4-32x more tokens compared to CLI equivalents.
That doesn’t contradict the roadmap. Server Cards and transport evolution are aimed at this gap — but the spec doesn’t deliver it yet. Anyone going to production with MCP now needs their own mitigations: tool filtering via a gateway, progressive disclosure through an orchestration layer, or both.
What this means for us
The roadmap validates the trajectory we described in the MCP Maturity Model. The Level 1 problems (token explosion, poor descriptions, missing auth) are now official priorities.
Three concrete takeaways:
Watch Server Cards. If SEP-1649 lands in the June spec, the discovery story changes fundamentally. Instead of blindly loading all tools, a client can filter upfront. That’s the single biggest lever against token bloat at the protocol level.
For enterprise concerns, the protocol deliberately stays thin: auth, audit trails, and gateway behavior live in extensions that still have to mature. Many teams already address that with a gateway layer — policy, auth propagation, tool filtering — instead of waiting on the spec. The roadmap implies that enterprise readiness needs an infrastructure layer above MCP, not just a fatter core spec.
Worth watching too: the MCP Dev Summit on April 2-3 in New York, 95+ sessions including conformance testing (Anthropic), mix-up attacks (Microsoft), and “When MCP Isn’t Enough” (Datadog). The conversations there will show whether the Working Group structure has traction or stays a governance experiment.
MCP has won as a standard. The roadmap shows the maintainers are taking that seriously. But between “de facto standard” and “enterprise production-ready” there’s still work to do. The maturity model still applies: if you stay at Level 1, you’ll hit the problems. If you build toward Level 3 and 4, you now have a clearer view of where the protocol itself is headed.