The Model Context Protocol, the open standard connecting AI models to external tools and data, releases its biggest revision since launch and removes the session state that until now forced servers to keep track of every client.
On July 1, 2026, the Model Context Protocol team published beta SDKs and a draft specification for the protocol's largest revision since its 2024 launch. The headline change in the 2026-07-28 release candidate is not a new feature; it is the removal of a foundational one. The new spec drops the initialize handshake and the protocol-level session that every MCP server built to date has had to maintain.
The operational consequence is the part that matters for builders and operators. Under the draft changelog, MCP servers can now scale behind a simple round-robin load balancer. The sticky-session routing and shared session stores that the protocol's previous stateful design forced on operators are no longer required at the protocol layer.
This is the move the team telegraphed seven months ago in "The Future of MCP Transports", where they laid out a stateless-by-default transport roadmap. The July 28 spec completes that plan in code.
The mechanics are worth a closer look. In current MCP, a client opens a session with an initialize call, the server allocates state for that session, and every subsequent request has to land on the same server instance, or hit a shared session store, for the protocol to function. Statelessness ends that. A request carries enough context for any server instance to handle it; the load balancer can distribute by simple round-robin. For operators running MCP at any non-trivial scale, this removes a class of infrastructure that the previous design made mandatory.
That subtraction is paired with one addition. The spec introduces Multi Round-Trip Requests, or MRTR, a new client-side pattern that lets servers drive richer, multi-step interactions with the client. The pattern lands in the draft alongside the four Tier 1 SDKs now in beta: Python v2, TypeScript v2, Go, and C#. MRTR is new and there is no production adoption to point to yet, so its practical effect is forward-looking and should be treated as such until server implementations ship.
The team is explicit that today is not a breaking change. Existing clients and servers keep working; the new design sits alongside the old. But "backward compatible" and "no operational change" are not the same thing. The teams that take the betas against real workloads before July 28, and the protocol team is asking them to, are the ones who will find out which stateless guarantees hold, which break under real traffic, and what edge cases show up when a request lands on a different server instance than the one that saw the previous request.
Three things to watch between now and the July 28 general-availability date. First, whether any of the Tier 1 SDKs reveal API changes that affect existing integrations as the team shakes out the betas. Second, whether MRTR's draft specification settles into a stable shape or continues to shift as server implementations catch up. Third, whether operators with stateful MCP deployments actually pull their session-affinity configuration in production; the real signal will be how many of them do, and how cleanly the migration goes.