What the Largest Revision Since Launch Targets
Locked on May 21, 2026, the MCP 2026-07-28 release candidate is being called the protocol's largest revision since launch. The initialize/initialized handshake, the Mcp-Session-Id header, and protocol-level session management are all removed, so any MCP request can now land on any server instance. The sticky routing and shared session stores that horizontal deployments used to require are no longer needed at the protocol layer. A remote MCP server can sit behind a plain round-robin load balancer, route traffic on an Mcp-Method header, and let clients cache tools/list responses.
Extensions Become First-Class Citizens
Extensions are now identified by reverse-DNS IDs, negotiated through an extensions map on client and server capabilities, maintained in their own ext-* repositories by delegated maintainers, and versioned independently of the specification. MCP Apps — server-rendered UI — ships as an official extension that renders interactive HTML in a sandboxed iframe, and Tasks, the long-running work primitive that arrived experimental in the 2025-11-25 release, moves out of the spec body into an extension after production use surfaced enough redesign to warrant it.
The Window a 12-Month Grace Period Opens
Roots, Sampling, and Logging all carry deprecation notices. The policy now mandates at least twelve months between a deprecation notice and the earliest possible removal, so all three keep working throughout the grace period. Reach for a soon-to-be-deprecated feature in new code, though, and you have booked yourself a rewrite twelve months out — which is why migration should treat this grace period as a window with a fixed deadline, not a way to buy unlimited time.
From Design to Operations: A Stateless MCP Migration Checklist
(a) Planning and target numbers: declare what moves and where the bar sits before writing code. The first metric is the count of session-dependent code points. Sweep every path that layered user state onto Mcp-Session-Id or the initialize step, set the target to 0, and make "error rate after the stateless deploy stays within +0.5pp of baseline" the cutover bar. Build the per-extension version matrix up front, too, so it is obvious at a glance which extension negotiates under which reverse-DNS ID and version.
(b) Failure patterns: failures recur along three lines. A server that stashed user state, cart contents, or auth context on the session ID loses that state the moment it goes stateless. A load balancer with leftover sticky-session config throws away the round-robin advantage and piles traffic onto one instance. Pulling deprecated Roots, Sampling, or Logging into a new feature plants a twelve-month time bomb by hand.
(b') Recovery branches: design recovery to push state out of the server. Move whatever rode on the session into the request payload or an external store (Redis, a database), and make every instance answer identically regardless of which request it receives. Before you strip the sticky config, run a canary that mixes round-robin and sticky, raising the stateless-instance share 5% → 50% → 100% while watching error rate and tools/list cache hit rate together. If an anomaly crosses the threshold, revert the routing config alone and recover in minutes.
(c) Operations checklist and quality: pre-deploy scenario tests must include "do consecutive requests from the same logical session return the same result when they land on different instances." Log the handling instance ID, the Mcp-Method, the negotiated extension IDs and versions, and a stateless flag, so requests scattered across instances stay traceable on one dashboard. Pin the grace-period milestones to a calendar: spec finalized July 28 → extension version matrix frozen in August → session-dependent code removed and stateless deploy shipped September–November → Roots/Sampling/Logging call sites replaced within the following twelve months. Sequenced that way, no two deadlines collide.
(d) Improvement loop: extensions version independently of the spec, so the version matrix keeps moving even after the migration lands. With each release, gather negotiation-failure and unsupported-extension logs to refresh the matrix, and run a regression check to confirm the session-dependent code-point count does not creep back above 0. Put error rate and cache hit rate after the stateless deploy next to their prior values, and the numbers show whether the round-robin switch actually spread instance load evenly.
Takeaways at a Glance
Surviving the 2026-07-28 spec — with the session handshake and Mcp-Session-Id gone — is a redesign that pushes state out of the server. Set the bar at zero session-dependent code points and error rate within +0.5pp after the stateless deploy, ramp a 5→50→100% canary on round-robin once the sticky config is gone, and put the extension version matrix and the 12-month deprecation calendar on the checklist — then the July 28 final spec runs on what you already built.
References
The 2026-07-28 MCP Specification Release Candidate — MCP Blog