MCP's new roadmap enables stateless horizontal scaling for servers

How far things have come since the March roadmap

The roadmap published back in March laid out four priorities: transport evolution and scalability, agent communication, governance maturity, and enterprise readiness. The maintainers say they've made substantial progress across all four areas over the past five months, with most of the changes landing in the 2026-07-28 spec release — developers may already have run into them in SDKs and documentation.

Beyond removing sessions, clients can now call server/discover before connecting to check supported versions and capabilities up front, and list results can now be cached (SEP-2549). On the agent communication side, feedback from early adopters led the team to move the Tasks feature into an official extension (SEP-2663). They also introduced a Multi Round-Trip Requests pattern (SEP-2322), which replaces the old model of servers initiating requests first and works even with stateless servers.

Governance and security got an overhaul too

On governance, the team formally adopted a Contributor Ladder, and each working group now reviews SEPs (Spec Enhancement Proposals) in its own area directly. The spec also gained a formal feature lifecycle and deprecation policy, with the deprecations in the 2026-07-28 release marking the first to follow it.

Enterprise readiness work over the past cycle centered on security: issuer verification, issuer-bound client credentials, and Client ID Metadata Documents (CIMD) as the preferred path for client registration. Enterprise-Managed Authorization, previously available as an extension, has now become stable.

The new roadmap is organized around five priorities

Priority	Key focus
Agent communication	Introduce server-initiated events (webhooks/channels); promote the Tasks extension to a formal spec
Transport unification	Extend the approach of treating remote MCP servers like standard HTTP workloads to local servers as well (Streamable HTTP over stdio)
Agent identity	Authenticate agents using DPoP, Workload Identity Federation, and standard token exchange instead of browser-based approval
Tool calling and result handling	Standardize tool call response formats into a single contract; introduce progressive discovery for large tool lists
SDKs	Improve usability, spec compliance, and documentation quality for SDKs across platforms and languages

Agent identity stands out here. Today, MCP authentication still relies on a human directly approving access through a browser. But that model is becoming inadequate as more agents run in the cloud with their own identities, act on a user's behalf while the user isn't present, or delegate narrow permissions to sub-agents. To address this, the team says it plans to finish rolling out the Demonstrating Proof of Possession standard and define pathways for agent identity and delegated authority based on discussions around Workload Identity Federation. They also intend to deepen collaboration with the IETF OAuth and WIMSE working groups.

How to propose a SEP

SEPs that fall within these five priority areas will get faster review and a better shot at adoption. Proposals outside the scope aren't automatically rejected, but given the maintainers' limited review bandwidth, priority-area proposals get first attention. If you're preparing a SEP, the recommended path is to first figure out which priority area it fits into, then bring the proposal to the relevant working group to refine it together. The roadmap page lists the core maintainers responsible for each area, and anyone interested in getting involved is invited to reach out via Discord.

Editor's take

Given that MCP's March roadmap set out the fairly vague goal of "transport scalability," eliminating sessions and the handshake altogether is a fairly bold move. Stateful servers are notoriously hard to run multiple instances of behind a load balancer, and when a connection drops, whatever task context was in flight tends to disappear with it. Stripping that out at the protocol level — so MCP servers can be treated like ordinary HTTP workloads — is a choice that cuts both infrastructure cost and complexity for companies running these servers.

The Agent Plugins standard that OpenAI released with AWS, Cursor, and GitHub in early August also supported packaging MCP server configurations. MCP continuing to refine its spec toward being stateless and lightweight is, in effect, laying firmer ground for those standards to build on. We've seen this pattern before: once a protocol stabilizes, the number of tools and standards built on top of it tends to grow.

For teams in Korea running their own MCP servers or integrating the SDK, there are two things worth doing right away. First, check how the session removal and server/discover changes in the 07-28 release affect your existing server code. Second, keep an eye on the agent identity work. The current practice of pasting in API keys directly is likely to be replaced before long by DPoP- or token-exchange-based authentication, and authentication overhauls always get more expensive to migrate the longer you wait to start.

Over the next few months, expect draft specs to emerge first for server-initiated events via webhooks and channels, and for progressive discovery that only surfaces the relevant parts of large tool sets. Both efforts are aimed at long-running agent loops that the current request-response pattern simply can't handle well — so teams actually running MCP in production would do well to follow the SEP discussions on this front.