The 2026-07-28 MCP release candidate is the biggest revision since launch, and its headline change is simple to state and far-reaching in practice: the protocol-level session is gone. No more initialize/initialized handshake, no more Mcp-Session-Id pinning a client to one server instance. If you run a remote MCP server, this is the one migration that actually changes your infrastructure.
What the session removal actually buys you
A stateful server needed sticky sessions, a shared session store, and a gateway smart enough to keep a client glued to the instance that held its state. That made horizontal scaling painful: two identical servers behind a round-robin load balancer produced split-brain sessions where state written on instance A was invisible to instance B. Remove the session and that whole class of problem disappears. Kubernetes autoscaling works without affinity rules. Serverless deployment on Lambda or Cloud Functions becomes viable because there's no long-lived connection to hold open. Rolling deployments stop killing active calls.
What moves into the request
Statelessness doesn't mean the handshake data vanishes; it moves inline. Protocol version, client info, and capabilities now travel in a _meta field on each request instead of being negotiated once up front. Every Streamable HTTP request carries two new headers: Mcp-Method (for example tools/call) and Mcp-Name (the tool or resource being targeted). The point: a load balancer or gateway can now route and throttle on the operation without parsing the JSON-RPC body — cheaper, faster, and easier to reason about at the edge.
"Stateless protocol" is not "stateless application"
This trips people up. Dropping the protocol session does not force your application to be memoryless. Servers that genuinely need to carry state across calls do what HTTP APIs have always done: mint an explicit handle — a basket_id, a browser_id, a run_id — from one tool and have the model pass it back as an ordinary argument on later calls. The state lives in your database keyed by that handle, not in a connection — which is more robust than the old implicit session, because the handle survives reconnects, restarts, and client switches.
The migration checklist
For most servers this is genuinely low-effort. Upgrade to an SDK that targets the 2026-07-28 spec. Audit any tool that quietly relied on cross-call session state and replace it with an explicit handle. Emit the new Mcp-Method and Mcp-Name headers. Add a ttlMs to your tools/list response so clients can cache the tool catalogue instead of re-fetching it every turn. Migrate anything you'd hacked together for long jobs to the proper Tasks extension, and harden auth while you're in there. Tier 1 SDKs are expected to ship support inside the ten-week validation window before the spec finalises on 28 July 2026.
Going further
Pair this with the other half of the 2026 transport story, MCP SSE deprecated: migrate to Streamable HTTP. Building servers? See build your first MCP server in Node.js and deploy to Docker and Cloudflare. For hosting trade-offs, read private MCP server hosting or browse the developer-tools category.