MCP just deleted its own handshake.
The 2026-07-28 release candidate removes initialize, removes notifications/initialized, and removes the Mcp-Session-Id header. Two control messages before your first useful tool call became zero. The release candidate was locked on May 21, 2026. The final specification is scheduled for July 28, 2026.
Here is the part that matters for anyone running a remote MCP server. You can now put it behind a plain round-robin load balancer. No sticky sessions. No shared Redis for session lookup. No gateway peeking inside JSON-RPC bodies to figure out which instance owns the connection.
Here is the damaging admission. The complexity did not disappear. It moved into your application code, and your code is probably not ready for it.
The Complexity Conservation Law
Complexity never gets deleted. It gets relocated.
Four numbers that define the stateless migration window.
The old MCP model handled continuity for you. A client sent initialize, the server replied with protocol metadata, and a session ID pinned every later request to one backend instance. Convenient, right up until you had three replicas behind a load balancer. Then it became cryptic timeouts whenever a request landed on an instance with no memory of the session.
The release candidate fixes that by making every request self-contained. Protocol version, client identity, and capabilities now ride in a _meta object on each request envelope. Capability discovery happens on demand through server/discover instead of one upfront negotiation. So one handshake became N per-request metadata blocks. That is a trade, not a free lunch.
The maintainers were explicit about the design goal: a stateless protocol does not require stateless applications. Your shopping cart, your browser session, your multi-step retrieval workflow all still need state. That state just becomes a visible handle in your tool schema instead of hidden transport plumbing. You now own the part that used to be free.
The 20% of the Migration That Gets 80% of the Result
The old protocol was a phone call. The new one is a vending machine. Every request walks up, says what it wants, pays, and leaves. No relationship, no memory, no hold music.
Three changes do most of the work. The rest is cleanup.
One: stop assuming the first message is initialize. New clients will not send it. If your server runs a state machine that waits for a handshake before accepting tools/call, it hangs or 400s on July 28. One-line fix in a lot of codebases. A genuine rewrite in others.
Two: mint explicit handles from your tools. If you were accumulating context per connection, move it into named arguments the model passes back. Return a basket_id, a browser_id, a run_id. Normal HTTP APIs have carried cart_id this way for twenty years, so you already know the pattern.
Three: sign those handles. This is where most teams will get hurt. An opaque state blob a client can edit is a parameter a client can escalate. Akamai's threat research team flags client-controlled state tampering and cross-agent workflow hijacking as new risk classes in the stateless design.
Now the operational upside, because there is real upside. Gateways can route on the new Mcp-Method and Mcp-Name headers instead of doing deep packet inspection on the body. Header inspection is cheap. Body parsing at the edge is not.
tools/list responses can also advertise a ttlMs field, which moves your manifest from "fetched on every new connection" to "fetched at most once per TTL window." Small change, big effect on chatty agent fleets.
There is a second-order risk on those headers that nobody should skip. Akamai documents developers mapping sensitive inputs, including API keys and customer IDs, into MCP-specific headers because the gateway expects routing metadata there. Once a secret is in a header, it is in your load balancer logs, your CDN, and your WAF dashboard. A scaling win, turned into an exfiltration surface.
The protocol also went unidirectional. Server-to-client requests are restructured out of the core, which is why Roots, Sampling, and Logging are deprecated in this release. Servers can no longer reach back into the client mid-conversation and ask for a model completion. If your architecture depended on that callback, you are rebuilding it as an extension, most likely with MCP Apps or the Tasks extension.
My read on this: the trade is correct and the timing is uncomfortable. Sticky sessions were the single most common reason production MCP deployments fell over, and killing them at the protocol layer is the right call. But the security burden lands on every implementer at once, and the average team has never designed a signed capability token before.
Three signals inside the same shift
MCP servers finally deploy like ordinary HTTP microservices.
With initialize and Mcp-Session-Id gone, a plain round-robin proxy is enough. No shared Redis for session lookup, no gateway peeking inside JSON-RPC bodies, and routing can happen on the new Mcp-Method and Mcp-Name headers instead.
Unsigned state handles become escalation parameters.
Akamai flags client-controlled state tampering and cross-agent workflow hijacking as new risk classes in the stateless design, plus developers stuffing API keys and customer IDs into MCP headers that land in load balancer and WAF logs. If SDKs do not ship signed handles by default, expect tampered-handle disclosures through 2027.
Statelessness is the property that made HTTP scale.
WorkOS frames the release candidate as the largest foundational rewrite since launch, and the bet is on infrastructure rather than intelligence. Every existing load balancer, tracer, cache, and blue-green pipeline works on MCP servers for free.
2031
Zoom out five years and this stops looking like a spec revision. It looks like MCP admitting what it actually is.
Protocols that win get boring. HTTP won because any machine that received a request could answer it. That property is what made CDNs, autoscaling, and edge compute possible. The 2026-07-28 release candidate picks the same property, and the WorkOS writeup on the spec frames it as the largest foundational rewrite since launch.
The asymmetric bet here is on infrastructure, not intelligence. A stateless protocol means MCP servers deploy like ordinary HTTP microservices, which means every existing tool in the ops ecosystem works on them for free. Load balancers, tracing, caching layers, WAFs, blue-green deploys. No amount of clever session logic buys you that.
The near-term cost is fragmentation. Arcade.dev warns that some clients will auto-update to the stateless spec while servers lag, leaving teams debugging a version matrix where 1.5 works and 1.7 does not. The Agentic AI Foundation's commentary on the release candidate is blunter about the direction: there are breaking changes, and the direction is still healthy.
Whether the official SDKs ship signed state handles as a default rather than an example is still an open question. If they do, the library layer absorbs most of the new security risk. If they do not, expect a wave of tampered-handle disclosures in agent platforms through 2027.
The contrast pair worth remembering: stateful protocols buy you convenience, stateless protocols buy you scale. Convenience is a feature. Scale is a moat.
What to Build This Weekend
Do not migrate your production server first. Build one throwaway server against the release candidate and feel the difference.
Step one. Pull the TypeScript or Python MCP SDK with release candidate support. Write a server with exactly two tools. One that starts a piece of work and returns a handle. One that continues that work using the handle as an argument. That is the entire new state pattern in about forty lines.
Step two. Sign the handle. An HMAC over the handle payload plus a user ID plus an expiry timestamp is enough for a weekend build. Validate it on every call and reject anything that fails. If you have never done HMAC, it is a keyed hash: a signature only your server can produce and verify.
Step three. Run two copies of your server on different ports and put a plain round-robin proxy in front. Then hammer it. If your handles are correct, requests bounce between instances and nothing breaks. That test is the whole point of the release candidate, and it takes ten minutes.
Step four. Pick a workflow tool you already use and wrap one real action. Taskade exposes
Feel the stateless model on a throwaway server before you touch production.
- Write two tools, not a migration. Pull the TypeScript or Python MCP SDK with release candidate support and build one tool that starts a piece of work and returns a handle, plus one that continues that work using the handle as an argument. That is the entire new state pattern in about forty lines.
- Sign every handle you mint. Compute an HMAC over the handle payload plus a user ID plus an expiry timestamp, then validate it on every call and reject anything that fails. HMAC is just a keyed hash: a signature only your server can produce and verify.
- Prove it survives a round-robin proxy. Run two copies of your server on different ports, put a plain round-robin proxy in front, and hammer it. If your handles are correct, requests bounce between instances and nothing breaks. That test is the whole point of the release candidate.
Convenience is a feature. Scale is a moat.
Sticky sessions were the single most common reason production MCP deployments fell over, and killing them at the protocol layer is the right call. But the release candidate did not delete complexity, it relocated it: state now lives as a visible handle in your tool schema, and the security burden lands on every implementer at once on July 28, 2026. Roots, Sampling, and Logging are deprecated, so any architecture that relied on server-to-client callbacks gets rebuilt as an extension. Arcade.dev is already warning about a version matrix where 1.5 works and 1.7 does not. Build the throwaway server now, sign your handles, and let the version skew happen to someone else.