The TypeScript and Python MCP SDKs each crossed 1 billion total downloads sometime in the last few months. At that scale, the protocol's original assumptions - single client, single server, local stdio transport - were always going to break. On August 22, the MCP maintainers published a new roadmap that shows exactly what they're fixing next, and the priorities read like a checklist of things production teams have been complaining about since the stateless spec landed in July.
If you are building or buying any agent system that touches MCP servers, this roadmap is worth 20 minutes of your time. Not because it is a future promise - most of the hard design work already shipped - but because it tells you which bets are safe to make today and which ones to defer.
What the July 28 spec actually changed
The headline change is that MCP is now stateless at the protocol layer, with six Specification Enhancement Proposals working together to get there. Concretely: protocol-level sessions and the initialization handshake are gone, so a server can scale horizontally without holding state.
When MCP was first introduced in late 2024, it provided a session-oriented framework optimized for a single client talking to a single server on a local machine.
The original session model required persistent state, handshakes, and session pinning - built on stateful transports that broke the core tenets of modern cloud-native scalability.
The practical effect: a remote MCP server can now run behind any ordinary load balancer or on serverless infrastructure, the same way any other HTTP API does.
Three deprecations are the most immediately relevant for teams building today:
- Roots, Sampling, and Logging are deprecated. They still work and will keep working for at least twelve months. New implementations should not adopt them.
- The legacy HTTP+SSE transport is officially deprecated, with a year-long offramp.
- Dynamic Client Registration is formally deprecated in favor of CIMD. DCR continues to work for backward compatibility but will be removed in a future version of the spec.
None of those will break you today. They will break you at the worst possible moment - during a vendor upgrade cycle twelve months from now - if you do not migrate proactively.
The five priorities the August 22 roadmap names
The August 22 roadmap is the clearest statement yet of where the protocol is heading. It groups work into five named priority areas: agentic messaging primitives (server-initiated events, maturing the Tasks extension), HTTP-native transport unification across local and remote servers, agent identity and enterprise security, improved result-handling primitives and progressive tool discovery, and better SDK developer experience.
Agentic messaging is the most consequential for teams running anything with long-running jobs. Loops can run for longer, servers can push streamed results, and MCP has been growing to meet these requirements, introducing Tasks, subscriptions/listen, and progress notifications. The next step: server-initiated events (webhooks and channels, so clients aren't left polling for results), a composition review across the Agents, Transports, and Triggers & Events Working Groups, and maturing the Tasks extension (SEP-2663) so it can move into the specification.
Transport unification matters more than it sounds. The July 28 release made a remote MCP server a normal HTTP workload, but every HTTP-native feature now needs a second stdio-specific design or doesn't work locally, and SDKs maintain two transport pipelines with protocol metadata duplicated across HTTP headers and message fields. The goal is one transport model. Until it ships, local and remote deployments are drifting apart in ways that will bite teams when they try to promote a local prototype to production.
Agent identity is where the EU AI Act's timing gets interesting. Starting 2 August 2026, providers and deployers of certain AI systems must comply with the transparency obligations set out in Article 50 of the EU AI Act.
Noncompliance can trigger fines of up to €15 million or 3% of worldwide annual turnover, whichever is higher. MCP's roadmap response: future work targets Demonstrating Proof of Possession (DPoP) and Workload Identity Federation for agent identity. Those are not live yet, but they are the foundation that lets you prove, at an audit, which agent called which tool with which credential.
Progressive tool discovery solves a quiet scaling problem. If your server exposes more than ~20 tools, don't wait for progressive discovery to ship - apply scoping and description discipline now. A model handed 60 tool descriptions performs measurably worse than one handed 15 well-scoped ones. The spec will eventually enforce better patterns; teams that impose them early will see the improvement immediately.
What teams should actually do this week
The roadmap is forward-looking, but the actions it implies are present-tense.
| Area | Current state | What to do now |
|---|---|---|
| Session state | Removed in July 28 spec | Audit any server that stores data between tool calls - make that state explicit and client-visible |
| Roots / Sampling / Logging | Deprecated, 12-month runway | Do not build new implementations on these; start migration planning |
| Tasks (SEP-2663) | Official extension, stable | Adopt for any long-running work; do not use the old experimental core form |
| Auth / identity | CIMD replacing DCR | Update client registration; track DPoP for future compliance |
| Tool count | No spec limit yet | Cap your exposed tools at a number a model can reason over; 20 is a reasonable ceiling |
| EU Article 50 | Live since August 2 | If agents interact with EU users, disclosure that they are interacting with AI is now mandatory |
The deprecation runway for Roots, Sampling, and Logging sounds generous. Twelve months is less time than it appears when you factor in the typical 3-6 month vendor upgrade cycle on enterprise tooling.
Beagle in action#platform-eng, 11:42amOne non-obvious consequence of stateless MCP
One part of this release that is especially interesting is the distinction between protocol state and application state. Most MCP servers that feel stateless actually are not - they hold a repository path, a browser session handle, or a file descriptor in memory and assume the next request arrives on the same instance. Can your requests move across server instances without losing important context? If they can't, find the hidden session dependency now. Look at every place your server remembers something between tool calls. A repository path, browser session, task, or deployment environment should have an explicit handle or scope that the client can see, log, and pass back safely.
That is the migration the stateless spec demands - and it is not about changing your transport. It is about surfacing implicit state that has always been there.
The MCP roadmap is not a promise sheet. The core maintainers have a track record of shipping what they scope - the July 28 release landed on the date named in the release candidate announcement, which itself gave a ten-week validation window. The previously published roadmap came out in March with four priority areas, and significant progress was made in all of them over the five months since. That discipline matters when you are making architectural bets.
The bet worth making: stateless, HTTP-native MCP servers with explicit Task handles for long-running work and CIMD-based auth. Everything the roadmap is building toward assumes that foundation.
MCP agent infrastructure roadmap: common questions
What did the MCP 2026-07-28 specification actually change?
The 2026-07-28 MCP specification brought a stateless protocol core, Multi Round-Trip Requests, header-based routing, cacheable list results, authorization hardening, a formal extensions framework, and updated Tier 1 SDKs. The most disruptive change for existing deployments is the removal of the initialization handshake and session pinning.
Is Sampling still usable in MCP after the July 2026 spec?
Roots, Sampling, and Logging are deprecated as of the 2026-07-28 specification, not removed. Under the new lifecycle policy (SEP-2596), a feature must stay Deprecated for at least twelve months from its deprecating revision before it is eligible for removal. Build nothing new on them.
What is the MCP Tasks extension (SEP-2663)?
Tasks first shipped as an experimental core feature in 2025-11-25, but production use led to moving it out of the core protocol into an official extension (SEP-2663). The redesign replaces blocking tasks/result with polling via tasks/get, adds tasks/update for client input, removes tasks/list, and lets servers return task handles unsolicited.
Does the EU AI Act apply to teams using AI agents over MCP?
Article 50 of the EU AI Act imposes transparency duties on providers and deployers of chatbots, synthetic-media generators, emotion-recognition systems, and deepfake tools - regardless of whether the underlying system qualifies as "high-risk."
The AI Act applies globally to providers, deployers, importers and distributors of AI systems that place AI on the EU market or whose AI outputs are used within the European Union. If your agent interacts with EU users, disclosure is mandatory.
When will MCP get server-initiated events (webhooks)?
The work spans server-initiated events (webhooks and channels, so clients aren't left polling for results) and maturing the Tasks extension so it can move into the specification. The August 22 roadmap names this as an active priority but does not commit to a ship date. Polling via Tasks is the stable alternative available today.