Introduction
On August 22, 2026, the Model Context Protocol maintainers published their roadmap for the next six to twelve months. Just a month after the 2026-07-28 specification — which introduced a stateless core for remote servers — this document outlines five priority workstreams and formalizes governance through dedicated working groups. The ambition is clear: turn a promising protocol into a reliable integration standard that enterprise engineering teams can actually build on.
Eliminating the Dual Transport Stack
Anyone who has built an MCP server knows the friction: remote servers run on Streamable HTTP, local servers rely on stdio, and SDKs end up maintaining two separate pipelines — each with its own behavioral edge cases. The chosen solution is HTTP/2 over stdio: the HTTP protocol encapsulated directly within a subprocess's stdin/stdout communication, while preserving the lifecycle guarantees of traditional process management. For engineering teams, this means a unified testing and CI toolchain and the elimination of an entire class of bugs born from that duality.
The workstream also introduces ETags for caching tool and resource results, building on the TTLs shipped in July. The expected outcome: fewer redundant calls, with no additional logic required on the client side.
Agent Identity, Without the Current Anti-Patterns
This is the workstream security teams will care about most. MCP integrations still rely too often on shared API keys or long-lived refresh tokens — precisely the patterns a SOC 2 audit or a zero-trust policy flags as unacceptable.
The roadmap targets two complementary mechanisms. DPoP (RFC 9449) binds a token to the client's ephemeral private key via a JWT signature: an intercepted token becomes immediately unusable, with no PKI to operate and no certificates to manage. Workload Identity Federation (SEP-1933) allows a cloud agent to obtain permissions through its workload identity, with no stored credentials whatsoever. Both efforts are being coordinated with the IETF OAuth and WIMSE groups — opening a convergence path with enterprise identity stacks already running in production.
Progressive Discovery and the Tools Interface Redesign
The tools/call interface currently returns both content and structuredContent simultaneously, which has produced divergent implementations across servers and clients. The planned redesign settles the semantics definitively.
More impactful still: progressive discovery will let clients load a server's tools on demand rather than ingesting the full catalog at startup. For a server exposing hundreds of tools, this is a direct architectural shift — with measurable effects on initial latency and model context saturation.
An Open Governance Model
The document formalizes the Specification Enhancement Proposals (SEPs) framework with one clear rule: SEPs aligned with a priority domain receive expedited review. Each domain is overseen by a Working Group with publicly named maintainers. For teams that want to influence where the protocol goes, the path is now documented — Working Group first, formal SEP second.
Spec-Generated SDKs
Current SDKs are hand-maintained and drift from the specification between releases. The goal for this cycle is to generate a reference SDK directly from the spec, validated against a published conformance test suite. Less drift, fewer post-release corrections, and getting-started examples that actually match the version running in production.
What to Act On Today
This roadmap doesn't mandate immediate migration, but it does frame the decisions worth making now. Aligning implementations on Streamable HTTP today lets you absorb the shift to HTTP/2 over stdio without breaking changes down the line. Evaluating DPoP for cloud workloads avoids building on patterns the standard will progressively deprecate. For teams with specific requirements, the Working Groups are open — and the window to shape the next specification is right now.