Most coverage of the 2026-07-28 MCP spec focuses on servers going stateless. But there's a change that lands squarely on the *client* side and is easy to miss: the `initialize`/`initialized` handshake is gone. If you write an MCP client or maintain an SDK, this reshapes how a session begins — here's what moved, and where it moved to.
What went away
Classic MCP opened every connection with a handshake: the client sent initialize with its protocol version, client info and capabilities; the server replied; the client confirmed with initialized. That exchange created a protocol-level session — a stateful pin between one client and one server instance. The 2026-07-28 spec removes it entirely. There is no handshake, and no session to establish before the first real request.
Where the handshake data went
The information didn't vanish — it relocated. Protocol version, client info and client capabilities now travel in the _meta field on every request. Instead of announcing them once and relying on the server to remember, the client restates them with each call. It feels redundant if you're used to the handshake, but that redundancy is the point: any request is now self-describing and self-contained.
Why: stateless scaling
A self-contained request needs no server-side memory of who you are, so any server instance can answer any request. That's what lets a remote MCP server sit behind a plain round-robin load balancer, route on the new Mcp-Method header, and let clients cache tools/list for as long as the server's ttlMs allows. The handshake was the last thing tying a client to a specific instance; removing it is what makes the stateless core actually stateless.
What client and SDK authors do now
Practically: stop sending initialize/initialized, and start attaching your protocol version, client info and capabilities to _meta on each request. Drop any logic that waited for the handshake to complete before issuing calls. If you rely on an SDK, this is mostly handled for you — the beta Python, TypeScript, Go and C# SDKs already implement the release candidate — but if you hand-rolled a client against the old flow, it needs updating before the spec finalises.
Going further
This sits alongside the other transport changes: the Mcp-Method and Mcp-Name headers and cacheable results with ttlMs. For the full picture, read the 2026-07-28 spec changes overview and how transports compare in Streamable HTTP vs SSE vs stdio.