Why the Handshake Disappeared

The MCP specification release candidate (2026-07-28), published May 21, 2026, removes the initialize/initialized handshake and the Mcp-Session-Id header. Client metadata now travels in the _meta field on every request, so no single server instance has to hold state, and any instance can pick up traffic behind a standard round-robin load balancer. New Mcp-Method and Mcp-Name headers open up routing, caching, and tracing directly at the HTTP layer.

MCP server implementations that lean on sticky sessions or a shared session store sit squarely in the blast radius of this change. A proxy or gateway that resolved state by session ID now has to behave identically no matter which server instance answers a given request — get that wrong, and the first request after a scale-out event fails.

Why Elicitation Moved From a Stream to a Re-Request

Elicitation used to hold an SSE stream open while waiting on user input; under the stateless core it's replaced by an InputRequiredResult response pattern. The server returns a list of input requests plus a requestState, the client collects the user's answers, and it resubmits the original call carrying both inputResponses and the echoed requestState. Because every bit of context lives in the payload, any server instance can pick up the retry.

Server-initiated requests are now restricted to windows when the server is actively processing a client request, which rules out — at the spec level — a server popping up an unsolicited prompt nobody asked for. The safety rules are explicit too: servers must not collect passwords or API keys through form-mode elicitation and must use URL mode for anything sensitive instead.

Why Tasks Dropped From Core Into an Optional Extension

Tasks moves from an experimental core feature to an optional extension with a redesigned lifecycle. Instead of tasks/list, clients now drive execution directly through tasks/get, tasks/update, and tasks/cancel, and the creation model reverses — the client advertises the extension, and the server decides whether a given call runs as a task. Any integration still calling the old Tasks API breaks compatibility right here.

From Design to Operations: An MCP Stateless Migration Checklist

The RC window runs from May 21 to July 28, which leaves 6 days until the spec finalizes as of today. Set the goal as passing both the legacy initialize handshake and the new stateless discover request in staging within that window. Four Tier 1 SDKs — Python, TypeScript, Go, and C# — already ship in beta, so real workloads can be validated ahead of GA.

Failures repeat along four lines: a load balancer that depends on sticky sessions conflicting with the new stateless request distribution; an older SSE-based client that can't parse the InputRequiredResult format, stalling elicitation; a server that still calls tasks/list against an implementation that hasn't adopted the extension; and an OAuth client that skips iss parameter validation, leaving it exposed to issuer spoofing.

Recovery starts with keeping v2 servers answering both the legacy initialize handshake and the new server/discover request. Per the official announcement, v1.x keeps receiving security patches for at least six months after v2 ships, so declare a branch in code that reroutes traffic to the v1 path — without rolling back the deployment itself — the moment canary error rates cross a threshold.

Three scenarios belong in every pre-deploy checklist: elicitation returning an empty array of responses, a server that never fires an unsolicited request outside an active call, and a static check confirming no credential leaks through form-mode elicitation. Log the protocol version (v1/v2), handshake type, and elicitation round-trip count so both versions' metrics land on the same dashboard.

Add RFC 9207 iss parameter validation now rather than later — it's optional today but becomes mandatory in the final spec. Put any client that hasn't declared application_type in Dynamic Client Registration at the top of the migration backlog.

Track the share of traffic still arriving on the v1 handshake weekly, and chase down the source server whenever it falls short of 100%. After the August GA, flip remaining opt-in stacks — Go and C# among them — to stateless-by-default, and keep servers that haven't adopted the Tasks extension in a separate migration backlog.

Takeaways at a Glance

The stateless transition succeeds or fails on how well v1 and v2 coexist, not on a benchmark score. Land iss validation and the elicitation safety rules first, pin an exact SDK beta version and validate it in staging, then wire in a canary-error-rate rollback path — and the same process keeps running after the July 28 GA lands.

References

The 2026-07-28 MCP Specification Release Candidate — Model Context Protocol Blog

Beta SDKs for the 2026-07-28 MCP Spec Release Candidate — Model Context Protocol Blog