MCP's biggest revision since launch ships today: the handshake is gone

The 2026-07-28 Model Context Protocol spec published today, and it removes two things every MCP server currently depends on: the initialize/initialized handshake and the Mcp-Session-Id header. Both are gone. Not deprecated. Gone from the core. (Model Context Protocol Blog)

What that buys you is real: any MCP request can now land on any server instance behind an ordinary round-robin load balancer. No sticky routing. No shared session store in Redis just so instance 3 knows what instance 1 negotiated. If you've deployed an MCP server to anything more serious than a single box, you've fought this. I've fought this. The session ID was the reason MCP deployments looked more like WebSocket infrastructure than HTTP infrastructure, and now they don't.

Long-lived SSE streams are gone too, replaced by an InputRequiredResult that carries the prompt plus echoed request state, so any instance can pick up the retry. Servers can only initiate a request while actively processing a client request, which kills the whole class of "server randomly calls back into your model at 3am" designs.

The replacement for protocol-level session state is what the spec calls the explicit-handle pattern: your server returns something like a basket_id, and the model threads it through subsequent calls as an ordinary tool argument. Read that twice, because it's a genuine design shift. State that used to hide in transport metadata is now visible to the model, present in the transcript, auditable, and replayable. That's strictly better for debugging and strictly worse if you were using session state to hide things from the model on purpose.

Tasks moved out of experimental core into a redesigned extension (tasks/get, tasks/update, tasks/cancel) after production use exposed design flaws, which is a refreshingly honest reason to break something. MCP Apps lets servers render interactive HTML in a sandboxed iframe with every UI action routed through the same JSON-RPC audit and consent path. Six auth SEPs harden OAuth/OIDC alignment.

The migration list you actually need (Stacktree): support Mcp-Method and Mcp-Name headers on Streamable HTTP POSTs, implement a mandatory server/discover RPC advertising versions and capabilities, read io.modelcontextprotocol/protocolVersion and /clientCapabilities from _meta on every request, add ttlMs and cacheScope to your tools/list, resources/list, and prompts/list results (SEP-2549). Client side: handle InputRequiredResult instead of server-initiated reverse calls, validate the OAuth iss parameter per RFC 9207, key persisted credentials by issuer.

The one that will silently break you: error code -32002 becomes standard JSON-RPC -32600. If you've got a client matching on -32002 in a catch block, it will stop matching and you will not get an exception. You'll get wrong behavior.

MCP also finally has a deprecation policy. Active / Deprecated / Removed lifecycles with a 12-month minimum window. Roots, Sampling, and Logging (SEP-2577) and the HTTP+SSE transport (SEP-2596) all started their clock today, meaning July 2027 at the earliest. Expedited removal requires 90 days' notice. If your server calls back into the client's model via Sampling, you now have a dated deadline instead of vague anxiety.

All four first-party SDKs shipped betas (MCP Blog): Python mcp[cli]==2.0.0b1 where MCPServer replaces FastMCP (a major rewrite, budget for it), TypeScript splitting into @modelcontextprotocol/server and @modelcontextprotocol/client, Go at v1.7.0-pre.1 keeping the same module path, C# 2.0.0-preview.1 leaving stable v1.x APIs intact. Maintainers say pin exact versions because public APIs may still shift.

Your v1 servers keep working. The v2 upgrade is optional. But if you're deploying MCP servers behind a load balancer today and paying for sticky sessions, this is the release that lets you stop.