Say you have an MCP server. It works, people use it, and you have not thought about the protocol in months. On July 28 the spec had its biggest revision since launch, and the question you want answered is whether you need to care.
Nothing breaks today. Old versions keep negotiating fine, anything retired has a twelve month floor, and the lead maintainer told a worried commenter on Hacker News that working code needs no changes unless you want the new features. Whether you care after today comes down to one question. Does your server remember anything between calls?
What Actually Changed
The connection used to be a conversation. Client said hello, server said hello back, they agreed a version, and from then on the server knew who it was talking to. A session ID in a header proved it. All of that is gone. Every request now shows up cold and carries what it needs to be understood on its own.
Your server is just an HTTP endpoint now. Serverless works, a plain load balancer works, no sticky sessions and no shared Redis tracking who is mid-conversation. The payoff is real, though the lesson is much older than the protocol: MCP is twenty months old and spent most of it rediscovering why the rest of the web went stateless.
The Claim Ticket
So where did the memory go? If your server needs to know something across several calls, it now hands out a claim ticket. The spec calls it a server-minted handle: your tool returns an opaque string, and the model hands that string back as an ordinary argument on every subsequent call.
File paths went the same way. Roots was a protocol feature whose whole job was telling a server which directories it could see. It is deprecated, and the replacement is passing paths as tool parameters.
Notice the shape. Two things the connection used to hold, both now arguments in the payload. The spec is blunt about it: dropping the protocol session does not make your application stateless. It moves the state to someone else, and that someone is the model.
The Yes/No Question That Costs You Everything
Under the old protocol a server could interrupt. Mid-request it could push a message up the open connection saying “check with the human first”, get an answer, and carry on. That needs a persistent connection, so it is gone. Now the server replies with a result meaning “I need more input”, and the client answers by sending the entire original request again with the answer attached.
For a small request that is nothing. For a tool whose arguments are a few thousand tokens of document or config, you just paid for all of it twice to ask a yes/no question. The upside is the retry can land on a different instance, which is exactly why it works on serverless. You are trading payload for portability. Same trade elsewhere: if a response stream breaks there is no resume, so the client re-issues the whole request from scratch.
Re-sending the full request on a retry is in the spec, so that part is not in doubt. Whether the duplicated payload also lands twice in the model’s context window depends on how your client is built, and I have not measured it across clients. If you own a tool with big arguments and a confirmation gate, check that yourself before assuming the retry is free.
The Half That Gets Cheaper
- Tool lists can be cached properly. Every list result now carries a freshness hint and a public/private scope, so clients and gateways stop re-fetching the same list forever.
- Tool order should be stable. The spec asks for deterministic ordering and says out loud that the reason is improving the model’s prompt cache hit rate. A protocol spec optimising for your token bill is new.
- Gateways can route without reading the body. Method and tool name travel in HTTP headers now, so a proxy can rate-limit expensive ingestion separately from cheap search without parsing a byte of JSON.
Discovery gets cheaper, stateful workflows get dearer. A plain search tool wins outright. A multi-step workflow with a confirmation gate pays.
Almost Nobody Noticed
The Hacker News thread got 125 points. The r/mcp announcement got 15 upvotes in a subreddit with 41,000 weekly visitors. X was mostly vendors posting “MCP v2 is here” graphics the same afternoon. The top r/mcp post that week was not the spec, it was a comparison of eleven MCP gateways. That is the tell, and someone running one said the quiet part:
— punkpeye, who runs the Glama MCP registry, on Hacker NewsHowever, the new protocol is wire-incompatible in both directions. This means that many of the servers/clients will need to be refactored (not enough to just update the SDK).
He would know, with 62,726 open-source servers indexed, and his read is that incompatibility is an opportunity for gateways to sit in the middle and translate. The biggest protocol change in MCP’s history lands, and the centre of gravity is already the layer that hides the protocol from you. Meanwhile a probe on July 12 reached 4,356 servers in the official registry and found exactly one passing all the required checks.
What It Doesn’t Solve
- Sampling is deprecated with no real replacement. It let your server borrow the client’s model. The suggested migration is to go get your own provider API key. Someone asked in the r/mcp thread what the workaround was and nobody answered.
- Files and images are still a mess. Three proposals have superseded each other, the current one sits in draft, and a maintainer confirmed the work slipped again. Clients are still shovelling base64 into context windows.
- An endpoint with no handshake is easier to leave wide open. The spec did not cause it, but a CVSS 10.0 in an unrelated MCP bridge last month came from binding an unauthenticated endpoint to all interfaces, exposing 233 tools including shell execution. There is no connection setup step left to hang an auth check on.
The Takeaway
- Do not panic-migrate. Nothing breaks, the twelve month window is real, and anyone telling you otherwise is selling a gateway.
- Updating the SDK is not the migration. The wire format is incompatible both ways. If you hold per-request state server-side, budget for a rewrite of that part.
- Look at your confirmation flows first, then take the caching wins. The retry cost lands on your biggest requests. Stable tool ordering and an honest freshness hint are an afternoon and pay out every turn.
The protocol got simpler by handing its memory to the model. For deployment that is unambiguously the right call. For anyone counting tokens it is not a saving, it is a transfer, and it lands in the one place that never has any room.
Related Posts
