MCP Goes Stateless: What Breaks and How to Fix It

The Model Context Protocol just reset the clock on every MCP server you have shipped. The 2026-07-28 specification — the protocol’s largest revision since launch — removes the initialize handshake, kills the session ID, and deprecates Roots, Sampling, and Logging in a single update. If you built an MCP server in the past 18 months, you have a concrete migration ahead of you. The good news: you have until at least July 2027. The bad news: clients are already upgrading to the new SDK.

What Actually Changed #

The headline is deceptively simple. Two SEPs do the heavy lifting: SEP-2575 removes the initialize/ initialized handshake entirely, and SEP-2567 removes Mcp-Session-Id. Together, they make the protocol core genuinely stateless for the first time.

Previously, running a remote MCP server meant fighting your infrastructure. Sticky sessions, a shared Redis instance for session state, or a gateway doing packet inspection — all because a stateful protocol was sitting on top of HTTP. Every request was tied to a session, and that session had to land on the same server instance. Horizontal scaling was a headache by design.

Under the new spec, every request is self-describing. Protocol version, client info, and capabilities now travel in a _meta field on each request rather than during a one-time handshake. Any request can hit any server instance behind a plain round-robin load balancer. No sticky sessions. No shared state store. The full spec announcement is on the MCP blog.

What Breaks on Your Server #

Three deprecations in SEP-2577 are the most likely to catch developers off-guard:

• Roots (roots/list ,notifications/roots/list_changed ) — Deprecated. Replace with tool parameters or config.
• Sampling (sampling/createMessage ) — Deprecated. Call the LLM provider API directly instead.
• Logging — Deprecated. Use stderr or OpenTelemetry.

There is also a quiet error code change worth catching: resource-not-found errors move from -32002 to the standard -32602. Servers running the new spec must not emit -32002. Any client-side error handling keyed to the old code will silently break.

The Tasks API is redesigned as well. The blocking tasks/result pattern is replaced with polling: tasks/get, tasks/update, and tasks/cancel. The tasks/list endpoint is removed. Servers now return task handles unsolicited; the client manages the lifecycle.

The 6-Step Migration #

The BetterStack migration guide has a thorough walkthrough, but the core checklist is short:

1. Upgrade your SDK. TypeScript splits into two packages:@modelcontextprotocol/client@2 and@modelcontextprotocol/server@2 . The old@modelcontextprotocol/sdk 1.x line is maintained for 2025-era servers. Python moves tomcp-sdk>=2.0.0 , Go togo-mcp/v2 , C# toMcpSdk 2.x .
2. Drop session ID assumptions. If your gateway or routing logic depends onMcp-Session-Id , rewrite it. Use explicit handles for any state you need to preserve.
3. Emit the new headers. AddMcp-Method andMcp-Name headers. These replace session-based routing for any infrastructure inspecting request metadata.
4. Migrate Tasks. Removetasks/list usage. Switch to the polling pattern and wire uptasks/get ,tasks/update , andtasks/cancel .
5. Add ttlMs to list responses. New caching requirement. Clients use it to decide when to re-fetch.
6. Harden auth. The spec ships six OAuth SEPs covering issuer validation, credential binding, and PKCE. Review theWorkOS breakdown of the auth changes if you handle auth yourself.

How Long Do You Have? #

The old 2025-11-25 spec is deprecated, not dead. The deprecation policy guarantees a 12-month overlap, meaning the features above cannot be pulled before July 2027. New v2 SDKs serve both 2025-era and 2026-era clients simultaneously during the transition.

That said, clients are upgrading now. Claude Code, Cursor, and the major MCP clients are tracking the new spec. Once a user updates their client, it will no longer send initialize. If your server expects it, the connection fails silently. The AWS architecture blog covers what well-architected MCP deployments look like under the new spec.

What You Gain on the Other Side #

Beyond the scaling fix, the new spec ships two meaningful additions. The Extensions Framework lets new capabilities land as opt-in extensions with their own versioning and repositories, keeping the protocol core stable while the ecosystem experiments. MCP Apps let servers render interactive HTML UIs directly in the client — sandboxed iframes, same JSON-RPC protocol — which opens a new class of server-side UI patterns.

The MCP Dev Summit Toronto runs October 5–6 at the University of Toronto and will focus on the enterprise questions the spec still leaves open: per-request authorization, agent delegation, and audit trails. If you are deploying MCP at scale, it is worth watching.

Bottom Line #

This is not an emergency. The 12-month window gives you room to plan. But a planned migration only works if you actually plan it. Audit your servers now: check for initialize handler dependencies, remove session ID routing logic, and schedule the SDK upgrade. The clients are not waiting for you.