The Model Context Protocol has been running in production at companies large and small for over a year. A lot of those deployments carry a quiet infrastructure debt: sticky sessions, shared session stores, and gateways that have to crack open a request body just to route it. On May 21, the MCP maintainers published the release candidate for spec version 2026-07-28 - the largest revision of the protocol since launch - delivering a stateless core that scales on ordinary HTTP infrastructure, a formal extensions framework, and a deprecation policy so the protocol can evolve without breaking existing implementations.
The final specification ships July 28. That is ten weeks from the RC lock, and the clock is running.
What actually changed
The most important change is that MCP is now stateless at the protocol layer. In earlier versions, clients initialised a session, servers returned a session ID, and future requests had to carry that identifier. The release candidate removes that protocol-level session model entirely, with the protocol version, client info, and capabilities now travelling with each request.
The Mcp-Session-Id header and the protocol-level session that came with it are removed entirely. With both gone, any MCP request can land on any server instance, and the sticky routing and shared session stores that horizontal deployments needed before are no longer required at the protocol layer.
The practical relief is real.
A remote MCP server that previously needed sticky sessions, a shared session store, and deep packet inspection at the gateway can now run behind a plain round-robin load balancer, route traffic on an Mcp-Method header, and let clients cache tool-list responses for as long as the server's ttlMs permits.
The Streamable HTTP transport now requires Mcp-Method and Mcp-Name headers on every request, so load balancers, gateways, and rate-limiters can route on the operation without opening the request body. Servers reject requests where the headers and body disagree - a breaking change for any custom gateway layer sitting in front of your MCP servers.
There is also a cleaner answer for servers that genuinely need to carry state across calls.
Removing the protocol-level session does not mean your application has to be stateless. Servers that need to carry state across calls can mint an explicit handle - a basket_id, a browser_id - from a tool and have the model pass it back as an ordinary argument on later calls. In practice, this pattern turns out to be more than a workable substitute: it is often more powerful, because the model can compose handles across tools, reason about them, and hand them off between steps.
The stateless web made the same trade - heavier per-request overhead, horizontal scale for free. MCP is making it now.
The other changes that will catch teams off guard
Stateless transport is the headline, but three other changes deserve attention.
Tasks were experimental in the 2025-11-25 core spec. The 2026 RC moves Tasks into an official extension with a different lifecycle, using tasks/get, tasks/update, and tasks/cancel.
Anyone who shipped against the old experimental Tasks API has a migration on their hands, not just a version bump.
List and resource read results now carry ttlMs and cacheScope fields modelled on HTTP Cache-Control, so clients know exactly how long a tools/list response is fresh and whether it is safe to share across users. W3C Trace Context propagation is also now documented in _meta with locked-down key names - meaning a trace starting in a host application can follow a tool call all the way through the MCP server and downstream services as a single span tree in any OpenTelemetry backend.
For teams already running OpenTelemetry, that last change is underrated. MCP traffic becomes correlatable with the rest of your application telemetry without any bespoke instrumentation.
The 2026-07-28 RC eliminates protocol-level sessions, mandates two new HTTP headers, changes an error code that client code almost certainly pattern-matches against, introduces caching semantics via new response fields, locks down distributed trace propagation, and deprecates three first-class primitives. That is six material changes in a single spec bump.
Why the deprecation policy matters as much as the technical changes
Another major shift is that extensions are becoming a formal part of MCP governance. This matters because ecosystems become brittle when every new capability has to land in the core. Either the core grows too fast and becomes hard to stabilise, or innovation slows down. MCP's answer is to make extensions official, versioned, and independently governed.
The deprecation policy that ships alongside this RC is the quieter win. It gives implementers a twelve-month guarantee that deprecated features remain functional before removal. If you have been following MCP as connective tissue between AI hosts, agents, tools, and enterprise systems, this release candidate signals something important: MCP is moving from a promising integration protocol to infrastructure developers can actually standardise on. The changes make it easier to deploy, easier to secure, easier to evolve, and more credible inside production environments.
That is not a small thing. It means a team can build against 2026-07-28 knowing the protocol will not silently break their production servers in the next revision.
What to do before July 28
The work is not conceptually hard, but it requires finding the hidden session assumptions in your codebase before they surface as 404s in production.
If your agentic system depends on MCP servers, do not treat this as a spec-reading exercise. Test the parts that may fail first. Ask whether your requests can move across server instances without losing important context. If they cannot, 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 - and give it an explicit handle or scope that the client can see, log, and pass back safely.
The specific checks worth running now:
- Grep for
Mcp-Session-Idin server code and gateway configs. - Audit any custom client implementations that built an initialize handshake.
- Check whether your gateway or proxy inspects request bodies for routing - add the new
Mcp-Methodheader instead. - If you implemented Tasks against the experimental 2025-11-25 API, plan the migration to the extension-based lifecycle.
- Validate your OAuth implementation against the tightened issuer-identification guidance (RFC 9207).
Tier 1 SDKs - the official TypeScript and Python SDKs - are expected to ship 2026-07-28 support within the ten-week window. If you are using an official SDK, the migration path is largely handled at the SDK layer; you will need to update the version, move session initialization code out of your app startup, and add the new headers. If you rolled a custom MCP implementation, the work is more manual.
An AI teammate like Beagle, which sits inside Slack and Teams and calls tool servers on behalf of teams, will need exactly this kind of audit - any implicit session affinity becomes a scaling problem the moment a deployment runs more than one instance behind a load balancer.
2026-07-28 is the release that turns MCP from a prototype-friendly protocol into one you can run at scale on infrastructure that already exists. The stateless redesign, routing headers, caching metadata, and tracing keys close the operational gap with mainstream HTTP APIs. The extensions framework solves the governance problem of where to put features that do not belong in a wire spec. The deprecation policy makes future change cheaper.
The RC is locked. The path is clear. Ten weeks is enough time - if you start this week.