MCP's New Roadmap: What It Means for People Building on It

On 22 August the maintainers of the Model Context Protocol published an updated roadmap covering the next six to twelve months of protocol work. It names five priority areas, the Core Maintainers responsible for each, and a quiet but important rule about which proposals get reviewed first. The previous roadmap, from March, promised four things and mostly shipped them in July's specification release, so this one has earned the right to be taken seriously. My read: MCP is deliberately becoming ordinary web infrastructure, and the useful question for builders is which part of your stack that changes first.

Key Takeaways - The roadmap sets five priorities: agentic messaging, a single HTTP-native transport, agent identity and enterprise security, cleaner tool primitives, and SDKs generated from the specification. - Specification proposals (SEPs) inside these areas get expedited review. Outside them, expect a longer queue and a higher bar. - The March roadmap's promises largely landed in the 2026-07-28 spec: a stateless core, cacheable list results, and Multi Round-Trip Requests. - The two changes most likely to touch your code are agent identity (DPoP and workload identity federation) and progressive tool discovery for large catalogues. - Treat the roadmap as direction, not commitment. The maintainers say so themselves. Don't pause your build for it.

What did the MCP maintainers actually announce?

The facts first. The updated MCP roadmap, dated 22 August 2026, organises the next spec cycle around five priority areas, each with named Core Maintainers and one or more Working Groups behind it:

1. Agentic messaging primitives: server-initiated events (channels, subscriptions, webhooks) so clients stop polling, plus a composition review to make Tasks, triggers and progress notifications share one lifecycle.

2. HTTP-native transport unification and hardening: Streamable HTTP as the single binding, eventually spoken over stdio for local servers, and caching extended to ETags.

3. Agent identity and enterprise-ready security: finalising DPoP (Demonstrating Proof of Possession) and defining an opinionated path for agent identity and delegation, built on existing IETF standards.

4. Improved primitives: a redesign of the tools/call result shape, and a new progressive discovery effort so clients learn a server's catalogue as they need it.

5. Improved SDK developer experience: an extension contract, and an experiment to generate a Tier 1 SDK and its quickstarts directly from the specification.

Alongside the five areas sits a rule that will shape everything else: SEPs that fall inside the priority areas get expedited review, and proposals with a Working Group behind them move fastest. In the maintainers' own words, "maintainer review time is scarce. We spend it here first." The roadmap also states plainly that it reflects current thinking rather than firm commitments, so individual items can slip or arrive in a different shape.

The MCP roadmap published on 22 August 2026 sets five priority areas for the next six to twelve months: agentic messaging, HTTP-native transport, agent identity, improved tool primitives, and spec-generated SDKs. Proposals inside these areas get expedited review; proposals outside them face a longer queue.

Why does this roadmap matter?

It matters because the last one delivered. Roadmaps from young open-source projects are often aspirational documents that quietly age out. This one has a track record. The March 2026 roadmap set four priorities, and the bulk of them shipped five months later in the 2026-07-28 specification release:

Adoption gives the roadmap its weight. By July 2026 the protocol's Tier 1 SDKs were seeing close to half a billion downloads a month, with the TypeScript and Python SDKs each past a billion total downloads. When a protocol at that scale tells you where it's going, it's worth reading the map.

Source: MCP roadmap (March and August 2026) and the 2026-07-28 specification announcement.

The March 2026 MCP roadmap promised transport evolution, agent communication, governance maturation and enterprise readiness. Five months later, the 2026-07-28 specification shipped a stateless protocol core, the Tasks extension, Multi Round-Trip Requests, and a formal deprecation policy with a twelve-month minimum window.

What does it mean if you're building on MCP?

For builders, the immediate impact is uneven. Two of the five areas will change your code within a year. The other three change how the protocol is governed and maintained around you. Here's each area translated.

Agentic messaging: the end of polling

Real agent work doesn't fit request and response. Jobs run for minutes, servers finish while the client isn't looking, and today the client's only answer is to poll, which is expensive and ugly. The roadmap prioritises server-initiated events: channels, subscriptions and webhooks, so a server can tell your client when work is done. The composition review matters just as much. Tasks, subscriptions/listen and progress notifications currently risk becoming three different answers to "the server isn't done yet", and the maintainers want them to share a lifecycle, a cancellation model and an error surface. If you build long-running tools, this is the area to watch on Discord.

One transport, spoken everywhere

The 2026-07-28 release made a remote MCP server an ordinary HTTP workload. The roadmap now wants to erase the split between remote and local: Streamable HTTP as the single binding, spoken over stdin and stdout for local servers, with HTTP/2 providing multiplexing while the subprocess keeps its security and lifecycle guarantees. Today every HTTP-native feature needs a second stdio-specific design or it doesn't work locally, and SDKs maintain two transport pipelines. One transport model means less of that. Caching extends too: ETags on top of the ttlMs and cacheScope hints that arrived in July, so tool call results can be versioned rather than refetched.

Agent identity: the one that bites soonest

MCP authorisation assumes a person with a browser at consent time. Increasingly the caller is an agent: a cloud workload with its own identity, acting for a user who isn't present, or spawning sub-agents that should get narrower authority than their parent. Honeycomb, quoted in the July release announcement, already puts nearly 20% of its monthly interactive queries down to agents. Meanwhile a lot of production MCP servers still lean on pasted API keys and long-lived refresh tokens, which is exactly the practice this work is meant to retire. The plan is DPoP finalised and adopted, plus a standard delegation path through Workload Identity Federation (SEP-1933), the ID-JAG grant behind Enterprise-Managed Authorization, and RFC 8693 token exchange, coordinated with the IETF OAuth and WIMSE working groups.

MCP's authorisation model was built for a human approving access in a browser, but agents are becoming the callers. The roadmap prioritises DPoP and a standard delegation path built on Workload Identity Federation and RFC 8693 token exchange, so servers can recognise agent identities without pasted API keys or long-lived tokens.

Tool results and progressive discovery

Two confusions get fixed here. The first is tools/call returning both content and structuredContent at once, which has produced divergent implementations because a server author can't know which form the client will show the model. That contract gets redesigned. The second is scale: connect to a server with a hundred tools and the model pays for the entire surface before the user has asked a single question, and tool selection gets worse as the list grows. The token bill is not theoretical. In Cloudflare's February 2026 test, exposing a 2,500-endpoint API as MCP tool definitions consumed roughly 1.17 million tokens, versus about 1,000 through code-calling. Progressive discovery is the proposed answer: a small entry point that reveals more of the catalogue as the conversation narrows, tied into the caching work above. I've written about when that overhead makes a plain API the better call; progressive discovery is MCP's attempt to shrink the gap.

SDKs generated from the spec

The quietest item may be the most telling. Today the SDKs, reference servers and quickstarts are maintained by hand. The roadmap runs an experiment: generate a candidate Tier 1 SDK and its companion quickstarts from the specification itself, validate both against a conformance test suite, and publish the findings, including which layers should be deterministic codegen and which should be model-assisted. If it works, spec clarity bugs get surfaced by generation failures, and SDKs stop drifting from the document they're supposed to implement.

What should you do now?

Four things, in order of urgency:

1. This week: stop building new work on deprecated surfaces. Roots, Sampling, Logging and the legacy HTTP+SSE transport were deprecated in the 2026-07-28 spec with a twelve-month minimum window. They still work. New implementations shouldn't adopt them.

2. This month: make your server cache-friendly. List results already carry ttlMs and cacheScope, and ETags are coming. A server that emits sane cache hints today is one migration ahead.

3. This quarter: audit how your agents authenticate. If any MCP server you run trusts a pasted API key or a long-lived refresh token for an unattended caller, that is the exact pattern the Agent Identity Working Group exists to replace. Track the group rather than rolling your own delegation scheme. The governance angle connects to what I covered in governing AI agents.

4. If you want to shape the protocol: write your SEP inside a priority area. Raise it with the relevant Working Group first and bring that group's support. Proposals aligned with the roadmap get expedited review; proposals outside it queue.

Two things not to do. Don't pause a build waiting for the next spec: the current one is the stable base, and the deprecation policy now guarantees you a twelve-month warning on anything that breaks. And don't treat the roadmap as a promise. It says, in its own first section, that priorities may shift and unlisted work may still ship. If you're earlier in the journey, my hands-on walkthrough for a first MCP server and shortlist of servers worth wiring in are the practical starting points.

The 2026-07-28 MCP specification deprecated Roots, Sampling, Logging and the legacy HTTP+SSE transport with a twelve-month minimum window. The release announcement confirms they keep working during that period, but new implementations should not adopt them.

The bigger picture

Step back and the pattern is a protocol growing up in public. MCP was donated to the vendor-neutral Agentic AI Foundation under the Linux Foundation in December 2025, with OpenAI and Block as co-founders. Since then it has gained a contributor ladder, a feature lifecycle, a deprecation policy, and now a public statement of where maintainer attention goes. The extensions framework does quiet but real work here too: SEP-2133 lets any Working Group experiment in an experimental-ext- repository before a formal proposal, so ideas get tested without destabilising the core.

The thing I'd watch over the next two quarters is whether HTTP over stdio lands. If local and remote servers genuinely converge on one transport, "MCP server" stops being a special kind of software and becomes a web service with a standard face. That's the point where the protocol disappears into the plumbing, which is what good infrastructure is supposed to do.

Frequently asked questions

Is MCP stable enough to build on now?

Yes, with migration discipline. The 2026-07-28 spec introduced a formal deprecation policy with a twelve-month minimum window, and SDKs ship with migration notes for breaking changes. The protocol will keep moving, but it now tells you a year in advance when something you rely on is going away.

What happened to MCP sessions?

They were retired in the 2026-07-28 specification. The initialize handshake and the Mcp-Session-Id header are gone (SEP-2575, SEP-2567). Every request is now self-describing, carrying its protocol version and client capabilities in _meta, and an optional server/discover call replaces the handshake for clients that want capabilities up front. Any request can land on any instance behind a round-robin load balancer.

Should I wait for the next spec before building?

No. The roadmap describes direction for the next six to twelve months, not committed features, and the maintainers say so explicitly. The current spec is stable, cacheable and stateless. Build on it, keep away from the deprecated surfaces, and track the two Working Groups whose output will touch you most.