On 22 August 2026, the Model Context Protocol core maintainers published an updated roadmap covering the next specification release and beyond. It is short, organised into five priority areas, and it reads like a governance update. It is not. Read it as an engineer and it is a list of the assumptions the protocol is about to stop making, which makes it a list of the code your team wrote last year that now has a shelf life.
Three items the previous roadmap parked as “on the horizon” have been promoted to priorities in their own right: server-initiated events, result type improvements, and agent identity. When a maintainer group moves something from horizon to priority, it is telling you the workarounds people invented in the meantime are about to be replaced by a standard. If you built one of those workarounds, the useful time to plan the migration is before the specification lands.
TL;DR
- The MCP roadmap published on 22 August 2026 sets five priority areas: agentic messaging primitives, HTTP transport unification, agent identity and enterprise security, improved primitives, and SDK developer experience.
- Server-initiated events (webhooks and channels) are coming, which makes client-side polling loops a temporary pattern rather than an architecture.
- MCP authorisation today assumes a human approving access in a browser. The roadmap commits to workload identity, DPoP and delegation, so long-lived pasted API keys are explicitly the thing being designed out.
- Progressive discovery is being introduced because servers exposing a hundred tools make the model pay for the whole surface before the user asks anything. Large tool catalogues are now a known anti-pattern.
- Specification Enhancement Proposals inside these five areas get expedited review. Everything else queues behind them, which is the practical route for teams that need a gap closed.
Treating protocol governance as somebody else’s problem was defensible when MCP was a way to hand a local model a filesystem tool. It stopped being defensible the moment agents became production workloads with budgets, audit requirements and blast radius. A release note tells you what changed; a roadmap tells you which of your current choices the maintainers consider a problem worth solving, and those are the ones that cost you a rewrite.
1. Request and response stopped being enough
The roadmap opens by stating plainly that modern agentic workloads no longer fit the standard request-and-response pattern. Loops run long, servers push streamed results, and work needs steering mid-flight. MCP has grown towards this already with Tasks, subscriptions/listen and progress notifications; the new work is making those primitives compose properly, and adding server-initiated events through webhooks and channels so clients are not left polling.
The practical consequence: if your agent platform contains a poller, a loop asking “is it done yet” every few seconds because there was no other way to find out, that component is scaffolding. It is probably also your least explicable source of latency and a real chunk of your token spend, since most teams re-send context on every check. Isolate it behind an interface now so swapping in a push transport later is a contained change rather than a project.
The Tasks extension (SEP-2663) is being matured for promotion into the specification proper. If you are running long jobs through an MCP server on a bespoke job-id convention of your own design, that convention is the thing being standardised. Read the SEP before you extend yours.
2. One transport, everywhere
The 2026-07-28 release made a remote MCP server indistinguishable from any other HTTP workload, which is why hosting one on your existing infrastructure suddenly became unremarkable. The roadmap now stretches that model to cover the remaining deployment modes, including local servers speaking Streamable HTTP over stdio.
That is a bigger deal than it sounds. Transport-specific branching is a quiet complexity tax in every MCP integration we have looked at: one code path for the local server, another for the remote one, subtly different error handling in each, and bugs that only appear in whichever mode has less test coverage. Unification removes the fork, and turns any abstraction layer you built to paper over the difference into dead weight.
3. Agent identity is the one that should worry you
This is the widest gap between how MCP is specified and how it is actually deployed. Authorisation today is built around a person approving access in a browser, which works for an interactive client and fails completely for the cases that now dominate: agents running as cloud workloads with their own identity, agents acting for a user who is not present, and agents delegating narrower authority to sub-agents.
What most teams did instead was paste an API key into a config file, and the roadmap names that directly: servers should recognise and trust agent identities “built on existing standards rather than pasted API keys and long-lived tokens”. The building blocks are named too. Finalising Demonstrating Proof of Possession (DPoP) and driving its adoption, plus an opinionated path for identity and delegation through Workload Identity Federation, the ID-JAG grant behind Enterprise-Managed Authorization, and standard token exchange. The maintainers are engaging the IETF OAuth and WIMSE working groups so the underlying standards evolve alongside.
Three things follow. Every long-lived token in your MCP configuration is now on a deprecation path, so start inventorying them. Sender-constrained tokens via DPoP improve your threat model immediately, because a stolen bearer token stops being sufficient on its own, so pull that forward rather than waiting. And if you cannot answer “which agent, acting for whom, under what delegated authority” from your logs today, no protocol progress fixes it: the specification hands you identity primitives, but recording and enforcing them is still your architecture.
4. Your hundred-tool server is the problem
Two changes sit under improved primitives. The first is a result-handling contract: a tools/call response can currently carry the same output in more than one form, and a server developer has no way to know which form a given client will put in front of the model. Standardising on one contract kills a category of “works in one client, silently wrong in another” bug that is miserable to debug.
The second is progressive discovery. As the roadmap puts it, connecting to a server with a hundred tools means the model pays for that entire surface before the user has asked a single question, and tool selection gets worse as the list grows. The fix being explored is letting a server offer a small entry point and reveal more of its catalogue as the conversation narrows.
Until that ships, treat tool count as a budget rather than a feature list. Splitting one sprawling internal server into several narrow ones, and connecting only what a workflow needs, buys measurable accuracy today. It is not a workaround you will unpick later either, because narrow, well-scoped servers are exactly what progressive discovery makes cheaper to compose.
5. The SDKs are being written for agents now
The final priority is SDK ergonomics and specification conformance, and the stated reason generalises: many developers now build MCP clients and servers by pointing an agent at the libraries, so clear APIs and accurate documentation decide whether the generated code works. Library design has become an input to code generation quality. If you maintain internal SDKs, ask whether your documentation would survive being the only context an agent gets.
If you need something the roadmap does not cover
The prioritisation rule is explicit: proposals inside the five priority areas get expedited review, and while everything else is not rejected automatically, scarce maintainer review time goes to the roadmap first. SEP-2133 also lets any Working or Interest Group experiment in an experimental extension repository before committing to a formal proposal. For a team with a real gap that is a route rather than a wall, and it beats forking the behaviour locally and carrying a patch that compounds every release.
What to do this quarter
- Inventory your MCP credentials. Every long-lived token, where it lives, what it can reach, and who would notice if it leaked.
- Find your polling loops. Put them behind an interface so a push transport is a swap rather than a rewrite, and measure what they cost in latency and tokens.
- Count your tools per server. If one server exposes dozens, split it by workflow and connect narrowly. The benefit is immediate.
- Check your transport branching. Anywhere local and remote take different code paths is a liability that unification will make unnecessary.
- Assign somebody to watch the Working Groups. Not a committee. One engineer, an hour a fortnight, reading SEPs in the areas that touch your product.
The wider point
MCP is maturing from a clever integration trick into infrastructure, and infrastructure has a different relationship with the people who build on it. The teams that stay comfortable are the ones tracking where the protocol is heading rather than integrating once and hoping, and that ongoing cost is far smaller than the surprise migration it prevents.
At REPTILEHAUS we build and run agent systems in production: MCP server design that will not need unpicking in six months, identity and delegation that stands up to an audit, and the DevOps around it so a protocol change is a routine upgrade rather than an incident. If you have agents in production and no plan for where the standard is going, get in touch.
📷 Photo by Vitaly Gariev on Unsplash
