MCP roadmap: what comes after the 2026-07-28 spec

Three weeks after the 2026-07-28 revision landed and quietly deleted sessions from the protocol, the maintainers published where MCP goes next. Five priority areas, dated 22 August, covering roughly six to twelve months. Read the note above them first, though. It says the roadmap reflects current thinking rather than firm commitments, and it is not being modest: there is not a single target date on the page, and no revision number for the next release either. Two of the Working Groups that own the work, Agent Identity and Core Primitives, are described as forming during this roadmap period. Which is a polite way of saying they have not started. So we read it backwards. Not what is promised, but which decisions in our own servers it makes wrong today. Two of them, as it turns out.

The five areas, minus the framing

Image: Model Context Protocol project

Agentic messaging primitives. Servers push instead of clients polling, through channels and webhooks, with a composition review across the Agents, Transports and Triggers and Events groups. That review matters more than it sounds, because MCP currently has several answers to “the server is not done yet” and they do not share a cancellation model.

HTTP-native transport unification. One transport binding instead of two. Local servers would speak Streamable HTTP over stdin and stdout, with HTTP/2 for multiplexing while keeping the lifecycle guarantees you get from a subprocess. Caching grows ETags on top of the ttlMs and cacheScope fields that arrived in July.

Agent identity. Covered below, because it is the one with teeth.

Improved primitives. The tools/call result shape, progressive discovery for large catalogues, and a question mark over content annotations.

SDK developer experience. The interesting half here is an experiment: generate a candidate Tier 1 SDK and its quickstarts from the specification, run both against the conformance suite, then publish what worked. Explicitly including which layers should be deterministic codegen and which should be model-assisted. Honest framing for a maintainer team that hand-maintains a lot of surface.

The bit that will touch your code

Here it is, plainly. tools/call lets a server return content and structuredContent at the same time, and a server author has no way to know which one a given client will actually show the model.

That is the defect the roadmap names. Not a nice-to-have.

If you maintain a server, this is already costing you. We have watched the same tool read perfectly in one client and arrive as an empty blob in another, purely because of which field the host decided to prefer. The fix is a redesigned contract, owned by a Core Primitives Working Group that does not exist yet, with no date. So the practical move is not to wait. Pick one field, put everything in it, and keep the other consistent rather than duplicated. Whatever the new contract looks like, a server that returns exactly one canonical form will be easier to migrate than one returning two that disagree.

The other item in that area is quieter and more interesting. Content annotations, which let a piece of content declare its intended audience and priority, might be deprecated. The roadmap says most implementers have not adopted them and may not know what they are for, then adds that if they are not useful, deprecation should be on the table. Roadmaps do not usually volunteer that a feature might be a mistake.

Agent identity, and why it is slow

The framing in the roadmap is sharp: MCP authorization assumes a person with a browser at consent time. Increasingly the caller is a cloud workload with its own identity, acting for a user who is not present, or spawning sub-agents that ought to get narrower authority than their parent got.

Today most servers handle that with a pasted key or a refresh token nobody rotates.

The answer named is not a new MCP mechanism. It is DPoP finalised and pushed toward adoption, Workload Identity Federation through SEP-1933, the ID-JAG grant that already sits under Enterprise-Managed Authorization, and RFC 8693 token exchange for handing down narrower authority. All of it coordinated with the IETF OAuth and WIMSE working groups.

Which tells you the pace. When your dependency is an IETF working group, “this roadmap period” is doing a lot of work in that sentence. I would not plan a migration around it landing inside six months.

Worth knowing if you are about to build on any of this: these are JWT-shaped grants, and JWTs are signed rather than encrypted. If you have never watched what is actually readable inside one, paste one into our JWT decoder and look, or read why a JWT hides nothing first. The number of teams putting user identifiers in a token they assume is opaque is not small.

What the March roadmap actually delivered

This is the part that makes the new one readable. The previous roadmap came out in March with four areas, and five months later the bulk of it shipped in one revision.

Protocol sessions and the initialization handshake went away, so a server scales horizontally without holding state, under SEP-2575 and SEP-2567. Clients got server/discover to learn versions and capabilities before doing anything else. List results became cacheable through SEP-2549. Tasks were reworked into an official extension after early adopter feedback, SEP-2663. Multi Round-Trip Requests, SEP-2322, replaced server-initiated requests so elicitation still works when there is no session to hang it on.

We wrote at the time about the gap between what that release removed and what it merely deprecated, because almost every summary blurred the two. That gap is still the thing to understand before reading any of this.

Governance moved too: a Contributor Ladder, Working Groups triaging SEPs in their own area, and a feature lifecycle with a deprecation policy that the July deprecations were the first to follow. On authorization, issuer validation and issuer-bound client credentials landed, and Client ID Metadata Documents became the preferred registration path for clients.

So the honest read on the new roadmap is not that it is vague. It is that the last one was vague in exactly the same way and roughly two thirds of it arrived within five months. That is a decent hit rate for a protocol run by working groups.

What we would do with it this week

Three things, and none of them require a spec.

Audit your tools/call responses and collapse them to one field. Then check what your server would look like if a client only ever fetched a handful of tools at a time, because progressive discovery is coming and a hundred-tool server is going to feel it. And if you have an open SEP that sits outside the five areas, adjust expectations rather than pinging maintainers, because the page is unusually direct that review time goes to the priority list first.

One caveat on all of this. I might be reading too much into two unformed Working Groups. Groups form fast when someone motivated shows up, and the Get Involved section is a genuine invitation rather than a formality: SEP-2133 lets any group experiment in an experimental-ext- repository before writing a formal proposal at all. If the tool result shape is costing you real time, that is a cheaper lever than waiting.

Sources

The announcement, the five priority areas and the March retrospective come from The New MCP Roadmap, published 22 August 2026 by Lead Maintainers David Soria Parra and Den Delimarsky. Named deliverables, Core Maintainer assignments, Working Group status and the SEP prioritization policy are on the MCP roadmap page, last updated 2026-08-22. The roadmap diagram is published by the Model Context Protocol project on the announcement post.

Frequently asked questions