MCP's New Roadmap Enables Stateless, Horizontally Scalable Servers

Servers no longer have to hold connections open

MCP (Model Context Protocol) core maintainers have published an updated roadmap. MCP, the shared standard for connecting AI to external tools and data, is often described as "the USB-C of AI." The most notable change in this roadmap is that servers no longer need to keep track of connection state with clients. Through SEP-2575 and SEP-2567, protocol-level sessions and the initialization handshake have been eliminated, which means servers can now scale horizontally without maintaining state.

How far things have come since the March roadmap

The roadmap released last March laid out four priorities: transport evolution and scalability, agent communication, governance maturity, and enterprise readiness. The maintainers say meaningful progress has been made across all four areas over the past five months, with most of the changes landing in the 2026-07-28 spec release — developers have likely already encountered them in SDKs and documentation.

Beyond removing sessions, clients can now call server/discover before connecting to a server to check supported versions and capabilities upfront, and list results can now be cached (SEP-2549). On the agent communication side, feedback from early adopters led the Tasks feature to graduate into an official extension (SEP-2663). A new Multi Round-Trip Requests pattern (SEP-2322) also arrived, replacing the old model where servers initiated requests with one that works even with stateless servers.

Governance and security got a tune-up too

On governance, the project formally adopted a Contributor Ladder and shifted to having each working group review SEPs (Spec Enhancement Proposals) within its own domain. The spec also gained a formal feature lifecycle and deprecation policy, with the 2026-07-28 deprecations marking the first case to follow it.

Enterprise readiness work over the last cycle focused mainly on security: issuer validation, issuer-bound client credentials, and adopting Client ID Metadata Documents (CIMD) as the preferred approach to client registration. Enterprise-Managed Authorization, previously available as an extension, has now become stable.

The new roadmap regroups 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 that treats remote MCP servers like ordinary HTTP workloads to local servers too (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 in particular. Right now, MCP authentication still relies on a human approving access directly in a browser. But that model is falling short as more agents run under their own identity in the cloud, act on a user's behalf while the user isn't present, or delegate narrow permissions to sub-agents. To address this, the maintainers plan to finish rolling out the Demonstrating Proof of Possession standard and, building on discussions around Workload Identity Federation, define pathways for agent identity and permission delegation. They also intend to keep expanding collaboration with the IETF OAuth and WIMSE working groups.

How to propose a SEP

SEPs that fall within these five priorities will move through review faster and stand a better chance of adoption. Proposals outside the priority areas aren't automatically rejected, but with maintainers' review time limited, priority-area proposals get first attention. If you're working on a SEP, the first step is figuring out which priority area it falls under, then submitting it to the relevant working group to refine it collaboratively. The roadmap page lists which core maintainers own each area, and anyone interested in contributing is invited to reach out via Discord.

Editor's take

Back in March, MCP's roadmap set a fairly vague goal around "transport scalability." Against that backdrop, eliminating sessions and the handshake entirely is a fairly bold move. Stateful servers were always awkward to run behind a load balancer in multiples, and any dropped connection meant losing whatever task context was in flight. Stripping that out at the protocol level and letting MCP servers behave like ordinary HTTP workloads is a choice that lowers both infrastructure cost and complexity for companies running these servers.

Earlier in August, OpenAI's Agent Plugins standard — released alongside AWS, Cursor, and GitHub — also supported packaging MCP server configurations. MCP's continued push toward a stateless, lightweight spec effectively firms up the ground those standards need to stand 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 SDKs, there are two immediate things to check. First, review how the session removal and server/discover changes in the 07-28 release affect existing server code. Second, keep an eye on the agent identity work ahead of time. The current practice of pasting API keys directly is likely to be replaced before long by DPoP or token-exchange-based authentication, and migrating authentication systems always costs more the longer you wait to start.

In the coming months, expect draft specs to emerge first for server-initiated events via webhooks and channels, along with progressive discovery mechanisms for servers with large tool lists. Both efforts target long-running agent loops that today's simple request-response pattern can't really handle, so teams running MCP in production would do well to follow the SEP discussions in this area.