The Model Context Protocol's session-based architecture has been a quiet production liability since day one. The 2026-07-28 release candidate, locked since May 21, eliminates Mcp-Session-Id, the initialize handshake, and sticky routing requirements in one sweep.
If you run an MCP server that handles real agent traffic, you have until July 28 to decide what breaks and what to do about it.
This post works through the actual changes from the official RC announcement and the SDK beta release notes, not summaries of summaries.
What the stateless core actually removes
Until now, every MCP connection started with a handshake: the client sends initialize, the server responds with its capabilities and hands back an Mcp-Session-Id, and every subsequent request carries that header so the server can find the conversation again. On paper that is tidy. On real infrastructure it is a tax. If your server runs as serverless functions, there is no "the server" to remember the session. You either pin clients to instances with sticky routing, or you push session state into shared storage and pay the latency on every single request.
Two specification enhancement proposals combine to make MCP genuinely stateless. SEP-2567 removes the Mcp-Session-Id header and the protocol-level session that came with it. SEP-2575 removes the initialize/initialized handshake - the connection setup that negotiated protocol version, client info, and capabilities at the start of every session. Those values now travel in _meta on every individual request. A new server/discover method covers the cases where clients still need to fetch server capabilities up front.
The routing story changes with it.
Every Streamable HTTP request must now include Mcp-Method (e.g., tools/call) and Mcp-Name (the name of the tool or resource). This lets load balancers, API gateways, and rate limiters route on the operation without buffering and parsing the JSON-RPC body. L7 routing on a header is significantly cheaper than body inspection - your Cloudflare Workers and gateway configs will be simpler, not more complex.
The old failure mode was subtle and nasty: pod A handled initialize and issued the session ID, then the SDK's long-lived SSE GET stream silently hashed to pod B - which knew nothing about that session - and returned a 404. Teams spent days debugging what looked like a network issue.
That class of bug is gone.
Application state did not disappear, though. It moved somewhere more honest.
Tools now return explicit opaque handles - think a basket_id or job_id. The model can see these handles, reason about them, and pass them forward on subsequent calls. Your server stores actual state in Redis, PostgreSQL, or wherever makes sense. The state is visible to the agent, which makes debugging substantially easier and agent behavior more predictable.
The three deprecations: Roots, Sampling, and Logging
Three first-class MCP primitives are deprecated in the 2026-07-28 RC: Roots, Sampling, and Logging. Nothing is removed yet. The deprecations are annotation-only. All three methods and their capability flags continue to work in this release and in every spec version published within twelve months of the final July 28 spec. You have at least until mid-2027 before they stop working.
That grace period matters, but the direction is set. The replacements: tool parameters or resource URIs for Roots, direct LLM API integration for Sampling, and stderr or OpenTelemetry for Logging.
Sampling is the one most worth planning around now. Sampling lets MCP server tools piggyback on the client's LLM for completions - a lightweight way to add inference without calling a separate API. The spec maintainers want servers to make direct LLM provider API calls instead. The argument is cleaner separation of concerns. Developers who built lightweight inference flows using Sampling are now looking at refactoring work. The methods still work today, but plan the migration.
For the first time, MCP adopts a formal feature lifecycle and deprecation policy. It defines three states - Active, Deprecated, Removed - and a registry of deprecated features. The key guarantee is a minimum deprecation window: a feature must remain Deprecated for at least twelve months before it is eligible for removal. There is one carve-out: an expedited removal can shorten the window for things like a published security advisory or in-the-wild exploitation, but must still provide at least ninety days.
The Tasks API is not backward-compatible
Anyone who shipped against the 2025-11-25 experimental Tasks API faces the most concrete migration work.
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. tasks/list is removed because it cannot be scoped safely without sessions. Anyone who shipped against the 2025-11-25 experimental Tasks API will need to migrate to the new lifecycle.
The Tasks extension handles long-running operations - CI pipelines, batch processing, human-in-the-loop approvals. Instead of blocking, servers return a task handle and clients poll with tasks/get.
For agents in Slack and Teams that kick off multi-step workflows, this is the right shape: the agent can post a progress update mid-task without holding a connection open.
What the SDK betas actually mean for your migration timeline
The Python SDK v2 reworks the package: FastMCP becomes MCPServer, and the decorator API carries over. The core server shape is familiar.
The headline from the SDK betas is that
upgrading your server does not strand existing clients: a v2 server answers the legacy initialize handshake alongside server/discover, so clients on 2025-11-25 keep connecting.
Serving the new revision over HTTP is an explicit opt-in: the streamable HTTP transport accepts 2026-07-28 only when you set StreamableHTTPOptions.Stateless = true. Leave it unset and clients negotiate down to 2025-11-25.
A concrete error-code change worth catching:
a missing resource now returns JSON-RPC -32602 instead of the MCP-custom -32002. If your client matches on the literal value, update it.
The release candidate is locked as of May 21, 2026. 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.
The triage is straightforward. If you run a local stdio server, 2026-07-28 is a real breaking migration for infrastructure-heavy MCP deployments. Local toy servers may barely notice. Remote multi-tenant servers will. Run the stateless RC branch now if you are in the second group.
What is genuinely new versus incremental
The stateless core is not incremental. It eliminates the specific infrastructure requirement - session stores, sticky routing, deep packet inspection at the gateway - that made remote MCP expensive to operate at scale. Every change points the same direction: away from protocol cleverness, toward boring, scalable HTTP - stateless requests, header-based routing, standard error codes, standard schema, standard tracing. Each of those choices makes an MCP server cheaper to run and easier to put behind infrastructure you already have.
The extensions framework is also a real structural change, not just a feature drop.
Extensions existed in the 2025-11-25 release but had no formal process behind them. The new spec adds that: extensions are identified by reverse-DNS IDs, negotiated through an extensions map on client and server capabilities, live in their own ext-* repositories with delegated maintainers, and version independently of the specification. A new Extensions Track in the SEP process gives them a path from experimental to official.
W3C Trace Context propagation in _meta is now documented, locking down the traceparent, tracestate, and baggage key names so distributed traces correlate across SDKs and gateways. A trace that starts in a host application can now follow a tool call through the client SDK, the MCP server, and whatever the server calls downstream, and show up as a single span tree in an OpenTelemetry-compatible backend.
That is unglamorous work that makes production debugging tractable.
What is incremental: the auth hardening is meaningful but largely catches the spec up to what production deployments were already doing. Read the auth SEPs regardless - SEP-2468 (issuer validation per RFC 9207) is the one most likely to be exploited in the wild between now and July 28.
The MCP ecosystem is large enough now that this revision has real weight behind it. The TypeScript and Python SDKs hit 97 million monthly downloads in March 2026, up from 2 million at launch. There are over 9,400 public servers in production today. More than 80% of Fortune 500 companies running AI agents in production connect those agents to tools via MCP. When a spec this widely deployed removes its session layer, teams running agents in Slack and Teams - where an AI teammate like Beagle might be handing off work between steps - feel the change immediately in how reliable those cross-step handoffs become.
The honest summary: this is the spec becoming infrastructure you can actually standardize on. 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. Migrate at the SDK's pace - nothing forces a hot cut-over - but do not wait until July 29 to read the changelog.