17 Aug 2026 7 min read

The MCP Handshake Died! What that means for you.

Anthropic put the Model Context Protocol out into the world in November 2024 (Introducing the Model Context Protocol - Anthropic). Twenty months later, its stewards tore out the foundational primitive. The initialize and initialized handshake, together with the Mcp-Session-Id header (the actual machinery every existing MCP deployment leans on just to open a connection), no longer exists as of the 2026-07-28 specification (Key Changes - MCP 2026-07-28 Changelog). Every request now has to carry its own protocol version, its own client identity, and its own capabilities, inline, every single time.

So, in other words, MCP just deleted the Handshake as of the July 2026 specification (The 2026-07-28 Specification - Model Context Protocol Blog).

I think the Engineering behind that move is sound, honestly. However, what actually bothers me is a separate issue, and it is this: that same release folded in a 12-month Deprecation Policy for specific features, then deleted the Handshake outside of it anyway, no Grace Period, none at all (MCP 2026-07-28 spec: what changed, what breaks - Stacktree). And nobody, as far as I can tell, has put a number on what this new "per-call tax" actually costs, either. Good architecture. But a forced roadmap-altering event.

Nobody serious is defending the handshake

Statelessness was the right call. Sticky Sessions and shared session stores are an infrastructure tax; they look fine in a demo, then turn into an incident category the moment you're at scale. Kubernetes co-creator Craig McLuckie put it plainly: the Model Context Protocol (MCP)'s statefulness "was really a by-product of its origin as a way to support developers using coding tools that tend to run locally," not a deliberate choice for production traffic (Model Context Protocol prepares to break with its stateful past - The Register).

Amazon Web Services (AWS) backs that up in its own account of AgentCore Gateway, and the detail is worth sitting with. Servers become "standard HTTPS endpoints" that scale behind a single UpdateGateway call; new Mcp-Method and Mcp-Name headers let gateways route traffic and rate-limit requests without ever opening the JSON-RPC body (How AgentCore Gateway supports the MCP 2026-07-28 spec - AWS).

This is the same session-affinity lesson the web learned twenty-five years ago, applied to a protocol that outgrew its laptop origins.

I don't expect anyone credible to argue for the Handshake's return. I wouldn't either, and frankly I'd be suspicious of anyone who did.

A new deprecation policy too!

The same release also delivered MCP's first formal feature-lifecycle policy (a 12-month minimum deprecation window before anything actually gets pulled), and applied it, correctly, to Roots, Sampling, Logging, and the HTTP+SSE transport (Key Changes - MCP 2026-07-28 Changelog).

The Handshake and the session header never made that list though. Both got deleted outright, carved out from the very Registry built to stop exactly this kind of shock. I think the reason is: you cannot half-deprecate a negotiation primitive: a server cannot simultaneously require and not require a Handshake on the same wire, and I accept that constraint completely. What I will not accept is the silence surrounding it: this is a standards body that just built its first governance policy and, in that very same release, kind of contradicted it.

Whatever mitigation exists right now is entirely vendor-built. AWS's Gateway can serve both protocol eras simultaneously and route clients by header (How AgentCore Gateway supports the MCP 2026-07-28 spec - AWS); the MCP TypeScript SDK's migration guide, for its part, ships an appendix comparing 2025-era and 2026-era behavior for this exact issue (Supporting protocol revision 2026-07-28). Neither one is spec-mandated. Both are goodwill, offered because a vendor decided the pain was worth solving, not because the specification required anyone to solve it.

A self-hosted operator without a vendor-built compatibility layer inherits the risk directly.

The actual break point comes down to whichever side of a client-server pair moves to the new era first, since a modern-only client simply cannot talk to a legacy-only server, and the reverse holds just as true (MCP 2026-07-28 Goes Stateless: What Breaks and How to Migrate to V2 - MCPJam).

That same asymmetry turns up again in authorization. RFC 9207 issuer verification and the audience-bound tokens under RFC 8707 do genuinely close a mix-up-and-replay hole; real progress, no argument there. But as one analysis of the release's OAuth hardening put it, "the token authenticates the client, not the agent" acting inside it (MCP's Auth Hardening: What the Six New OAuth SEPs Fix, and What They Still Don't - Tigera). That gap is why an IETF Internet-Draft, the Agent Identity Protocol, exists at all: because, in its own words, "MCP provides no built-in authentication layer" at the agent level (Agent Identity Protocol (AIP) - IETF Internet-Draft).

The surprising migration bill we did not plan for

The migration cost is real, in my view: genuinely real. For a stateful remote server, it will require a genuine architectural migration: your session state turns into hand-rolled handles, the sticky-routing assumptions you baked in get ripped straight out, and observability breaks down because a single multi-round-trip request now sprawls across multiple JSON-RPC IDs (MCP 2026-07-28 Goes Stateless: What Breaks and How to Migrate to V2 - MCPJam). Stacklok's 2026 survey puts the Model Context Protocol (MCP) at 41 percent of software organizations running it in limited-to-broad production, against roughly 97 million monthly software development kit (SDK) downloads (MCP Adoption Statistics 2026 - digitalapplied). Do the math on that gap. A lot of mid-size Platform Teams are sitting on a rewrite nobody budgeted for, and honestly, nobody warned them either.

Meanwhile, I have not come across a published number for the quieter cost, the one nobody seems to bother about yet: stamping protocol version and capabilities onto every single tools/call. The spec's new ttlMs caching helps, sure, but only for list and read calls; invocations get none of it (Key Changes - MCP 2026-07-28 Changelog).

What the same release does do is standardize OpenTelemetry trace-context conventions inside _meta via SEP-414. That is going to help. (SEP-414: Document OpenTelemetry Trace Context Propagation Conventions).

What actually got resolved here

Strip away the framing fight and something real is left standing underneath it: agreement.

The stateless architecture is correct, no argument there.

And the twelve-month deprecation policy? Genuine progress.

In my view, the Standards Body owes the ecosystem something more deliberate than what it has offered so far: a second, purpose-built governance instrument for this category of change, not a changelog entry that quietly leaves the whole issue out. The authorization hardening is real progress on client authentication, and yet it stays just as quiet on Agent-level accountability.

What I am watching next

Three things, really, over the next couple of quarters. First: whether any vendor besides the TypeScript SDK team ever publishes a formal "compatibility-matrix pattern," or whether every implementer just keeps building their own from scratch, which is more or less where things stand right now. Second, whether anyone actually runs a tools/call-heavy Agent loop through SEP-414 instrumentation and puts a real per-call overhead number in front of people, instead of leaving it a theoretical worry. And third, whether the Agent Identity Protocol draft picks up genuine momentum toward standardization, or just sits there as a gap everybody nods along to and nobody actually owns.

None of this requires MCP to reverse course. What it does require is for the ecosystem to finish the Governance work the spec started, and then, for whatever reason, stopped short of.

The part nobody gets to skip

MCP 2026-07-28 nailed the architecture. The accountability half of the release, though, got left unfinished, and that is not a small gap. Here is what happens when a standards body ships its first Deprecation Policy and its most consequential Breaking Change in the same release: the policy quietly turns out not to cover the change it was supposed to govern. Reverting the Handshake is not the fix, and I do not think anyone serious is asking for that. What is missing is someone, Spec Authors, platform teams, or both, finally writing the Playbook that currently exists only as one SDK team's optional Migration Guide and a single gateway vendor's dual-version routing hack.

Until somebody writes that Playbook, every team adopting this spec ends up drafting their own version of it, usually under production pressure, and rarely well. I would rather see it written once, properly, than fifty times over, badly, by every team just trying to keep its integrations from breaking.

Citations & Further Reading

Subhadip Chatterjee

A technologist who loves to stay grounded in reality.

Tampa, Florida