The headline change in the MCP 2026-07-28 release candidate is that MCP is now stateless at the protocol layer. Six Specification Enhancement Proposals work together to get there, completing the plan laid out in the December transport futures post. If you run a remote MCP server in production - behind a gateway, a load balancer, or any autoscaling infrastructure - you have work to do before July 28.
This is not a vague architectural direction.
The release candidate, locked May 21, removes the initialize handshake, kills the Mcp-Session-Id header, and makes every MCP request self-contained.
The current stable spec, 2025-11-25, is still what you should be running in production today. But the RC is the spec you should be testing against now.
What the session removal actually means for your deployment
The biggest technical change is that MCP is becoming stateless at the protocol layer. In previous MCP versions, a Streamable HTTP client established a session first. The server returned an Mcp-Session-Id, and the client carried that ID into later requests. That meant deployments had to care about sticky sessions, shared session stores, and gateway behavior that understood enough about MCP to route traffic correctly. That is manageable during experimentation, but it gets painful when you are running remote MCP servers behind load balancers, gateways, and rate limiters.
The 2026-07-28 release candidate removes the initialize/initialized handshake and the Mcp-Session-Id header that pinned a client to one server instance. Protocol version, client info, and capabilities now travel inline in a _meta field on each request. Any server instance can serve any request, so a remote MCP server can run behind a plain round-robin load balancer without sticky sessions or a shared session store.
Two specific SEPs do the structural work:
SEP-2575 removes the initialize/initialized handshake entirely. SEP-2567 kills Mcp-Session-Id. Together, they mean every request now carries its own protocol version, client identity, and capabilities inside a _meta object on the JSON-RPC envelope.
For infrastructure teams, the routing consequence is immediate.
New Mcp-Method and Mcp-Name headers let load balancers and gateways route on the operation without body inspection. Servers reject requests where headers and body disagree.
Your gateway can now rate-limit and log MCP traffic based on the specific operation - the same way it handles any well-behaved HTTP API - without parsing JSON-RPC bodies to figure out what is happening.
The honest operational read: if your current setup has at least one band-aid - sticky sessions, a Redis session store, deep packet inspection - that exists only because of the stateful protocol, migrating lets you delete that code. And code you delete is code that cannot break in production.
The Tasks extension redesign is a breaking migration if you shipped early
Tasks shipped as an experimental core feature in 2025-11-25. Production use surfaced enough redesign that the right home for it is an extension rather than the specification. The Tasks extension reshapes the lifecycle around the stateless model: a server can answer tools/call with a task handle, and the client drives it with tasks/get, tasks/update, and tasks/cancel. Task creation is server-directed: the client advertises the extension and the server decides when a call should run as a task.
If you built against the experimental Tasks API in 2025-11-25, you need to migrate. Before 2026-07-28, teams implemented custom polling or webhook patterns for operations that took longer than a request timeout. The Tasks extension standardizes this with a three-endpoint pattern: create task, query status, cancel task. Tasks return a task identifier immediately and clients poll for completion. This works naturally with the stateless core because task state lives in a backing store, not in server memory.
The extension model means you can adopt Tasks incrementally. Servers that do not implement the Tasks extension fall back to synchronous operations. Clients that require Tasks can fail fast if the server does not advertise the extension. This prevents runtime failures from missing features.
What is deprecated, not removed - and why the timing matters
Three features enter deprecation in this release: Roots (replaced by tool parameters or config), Sampling (call the LLM provider API directly), and Logging (use stderr or OpenTelemetry). A formal deprecation policy guarantees a minimum twelve-month window between deprecation and removal, so none of these break on July 28.
The twelve-month runway matters because it gives you until mid-2027 at minimum before removal is even eligible. Migration paths exist for each: Roots - pass workspace paths as tool parameters or resource URIs; Sampling - call the LLM API directly from your server code; Logging - write to stderr or ship to OpenTelemetry. Follow your SDK's migration timeline.
Do not rip these out when the final spec drops in July. Wait for SDK guidance - for the TypeScript SDK, which has 66 million npm downloads and 27,000-plus dependent packages, that migration will be well-documented and gradual.
The extensions framework itself is also new in this release.
Extensions get reverse-DNS IDs, live in dedicated ext-* repositories, and are negotiated through a standard capabilities map. Two extensions ship with the spec itself: the Tasks extension and MCP Apps.
MCP Apps lets servers ship interactive HTML interfaces that hosts render in a sandboxed iframe, with every UI-initiated action going through the same audit path as a direct tool call.
What you should do before July 28
The final specification will be published on July 28, 2026. The ten-week window is for SDK maintainers and client implementers to validate the changes against real workloads; under the SDK tier system, Tier 1 SDKs are expected to ship support within this window.
A focused checklist for server operators:
Most servers need a focused checklist: upgrade the SDK, drop Mcp-Session-Id assumptions and use explicit handles for state, emit the new Mcp-Method and Mcp-Name headers, migrate experimental Tasks to the new lifecycle, add ttlMs to list responses, and harden auth.
One practical note on auth:
the release candidate formalizes W3C Trace Context propagation in _meta, which improves distributed tracing across hosts, SDKs, MCP servers, and downstream systems. In organizations already using OpenTelemetry, this is especially significant - MCP traffic becomes much easier to correlate with the rest of an application's telemetry.
If your server depends on a community SDK that is not a Tier 1 maintainer, you do not have a guarantee that the SDK will ship 2026-07-28 support before July 28 itself. Plan a quarter of slack. Do not promise a migration date until the SDK author publishes their own.
The stateful handshake was incompatible with the way production HTTP is actually deployed: load balancers had to parse JSON-RPC bodies to route, sticky sessions blocked autoscaling, and a single server restart blew up every in-flight session. The RC fixes all of that. The tradeoff is a real migration for anything that built early against the experimental surface. The spec is worth reading - the official release candidate announcement and the 2026 roadmap are the primary sources. A teammate like Beagle, routing agent actions through MCP tool calls, will benefit from the cleaner audit path that stateless requests and explicit handles provide.
The window is real. Test before July 28.