Does Your MCP Server Need to Migrate Before July 28?

Short answer: almost certainly not on July 28 itself. The MCP 2026-07-28 specification removes the initialize/initialized handshake (SEP-2575) and the Mcp-Session-Id session header (SEP-2567), but v2 servers keep answering the legacy 2025-11-25 handshake, so existing clients keep connecting. The servers that must act first are remote HTTP servers that depend on sticky sessions or a shared session store.

This is the largest revision of the Model Context Protocol (MCP) since launch. The spec goes final on 2026-07-28, beta SDKs are already out (@modelcontextprotocol/[email protected] and @modelcontextprotocol/[email protected] on npm; mcp==2.0.0b1 on PyPI), and stable v2 is targeted for 2026-07-27. That window is creating urgency that, in most cases, isn't warranted. Whether you need to move now depends on one question: does your server depend on session affinity?

What actually changes on 2026-07-28

The stateless core is the headline change. The initialize/initialized handshake is removed (SEP-2575): protocol version, client info, and capabilities that previously traveled once at connection time now travel in _meta on every request. The Mcp-Session-Id header and the protocol-level session are gone (SEP-2567); a new server/discover method lets clients fetch server capabilities up front when they need them.

Beyond statelessness, three things become first-class: the Tasks extension (standardised long-running operations with create/query/cancel and immediate task-id responses), MCP Apps (a packaging standard for server-rendered UIs), and authorization hardening with token scopes. The Enterprise-Managed Authorization (EMA) extension is now stable and has been adopted by Anthropic, Microsoft, and Okta. A formal deprecation policy lands too, so the protocol can evolve without breaking what you've shipped.

Which servers must migrate, and which can wait

The distinction comes down to transport and session architecture.

• Remote server using `Mcp-Session-Id` or sticky sessions: plan the migration. This is exactly what the spec removes. Your load-balancer config changes, your gateway routing changes, and you need to read `_meta` instead of relying on connection state.
• Remote server already stateless behind a round-robin load balancer: low-effort upgrade. Adopt `server/discover`, read `_meta`, attach `ttlMs` and `cacheScope` to your list and read results, and route on `Mcp-Method`/`Mcp-Name` headers instead of session affinity.
• Local `stdio` server: no urgency. Nothing about your transport changes on day one. Migrate on your own schedule after stable v2 ships.
• Using experimental Tasks: move to the Tasks extension. The blocking `tasks/result` pattern moves to polling: create task, get task-id back immediately, query status, cancel if needed.
• Running a gateway or proxy: route on `Mcp-Method` and `Mcp-Name` headers instead of session affinity. Update your gateway config before July 28 if you have remote servers behind it.

Why nothing breaks on day one

Backward compatibility is explicit in the spec: a v2 server continues to accept legacy 2025-11-25 handshake requests. Clients on the old protocol keep connecting and can upgrade independently. This means the ecosystem migrates gradually: your server can ship v2 support while existing clients stay on v1, and vice versa. The protocol version a client speaks is now in _meta, so a v2 server can detect and serve both.

What migrating actually involves

When you do migrate a remote HTTP server, the mechanical steps are: read protocol version and capabilities from _meta instead of the handshake; implement server/discover (the new capability-discovery method); drop session affinity at your gateway in favor of routing on the Mcp-Method and Mcp-Name request headers; attach ttlMs and cacheScope to your list and read results so clients can cache them correctly.

For the full before/after HTTP wire diff, including the exact header changes, cache semantics, and four mechanical server-side changes, see the live walkthrough at mcporbit.com/blog/mcp-stateless-migration-checklist.

The upgrade you should not defer: test against the beta SDK now

Even if your server doesn't need to migrate urgently, the beta SDK is out and stable v2 is one week away. Run your test suite against @modelcontextprotocol/[email protected] (npm) or mcp==2.0.0b1 (PyPI) now. The old npm package @modelcontextprotocol/sdk stays on v1; the v2 beta ships as two new packages: @modelcontextprotocol/server and @modelcontextprotocol/client, both at 2.0.0-beta.1. Python's stable v1 line is at 1.28.x; Go and C# betas are also available.