You can't scale what you have to remember

MCP is dropping the session. When the spec finalizes on July 28, the initialize handshake goes, the Mcp-Session-Id header goes, and with them the whole idea that a client and server share a conversation the protocol keeps track of. It’s a breaking change and they know it. The reason is the one that catches up with every stateful protocol eventually: a server that needs sticky sessions and a shared session store can’t sit behind a plain round-robin load balancer, and someone finally decided the scale was worth the break.

If you’ve ever had to scale anything, that trade reads as relief, not loss. The session was always the part that hurt.

Here’s the whole problem in a line: state is the thing you can’t round-robin. A session pins a client to one instance, because that instance is the only one that remembers the conversation. Add a second instance and you need sticky routing to keep the client glued to the first, or a shared store so both can see the same memory — and now the store is the bottleneck, the single point of failure, the thing you spend the next year designing around. What felt like a convenience on one machine becomes a tax on ten.

None of this is new, and it isn’t really about MCP. HTTP was born stateless; we bolted sessions back on almost immediately, then spent twenty years prying them off again — server-side sessions gave way to stateless tokens, pet servers to cattle, and twelve-factor made it a rule that a process should hold nothing between requests. The lesson never changed: statelessness is what lets you treat your servers as interchangeable, and interchangeable is the only thing that scales. MCP shipped stateful-by-default, hit the wall everyone hits, and is now doing what everyone does next — pushing state back out to the client, carried along on each request instead of remembered between them.

The honest part is that this costs something, and it’s worth being specific about what. Sampling is going away, along with Roots and Logging. Sampling was the nice one — it let a server hand a prompt back to the client and borrow its model, and if you built on that inversion you’ll feel the absence. Then there’s the running tax: everything the handshake used to settle once — the protocol version, what the client can do — now rides along on every request instead. Small each time, real at volume. And the deepest cost isn’t in the changelog at all: going stateless is a discipline, not a header. A tool that genuinely needs memory — a game mid-play, a job half-finished — still has to keep that state somewhere. Dropping the session doesn’t solve that; it hands the problem back to you, to hold in a database or a token where you can actually scale it. The protocol got simpler. Your hard part didn’t move. It just stopped hiding inside the handshake.

Which is exactly why I think it’s the right call, breakage and all. A protocol that remembers things for you is doing you a favor right up until you have more than one server, and then it’s making your architecture decisions for you. Handing the memory back is the protocol admitting it was never the right place to keep it.

So my bet is a plain one. The servers that come through July 28 in good shape are the ones that were already stateless by discipline, holding no more than they had to. The ones that hurt will be the ones that let the handshake talk them into keeping state it made so easy to keep. That’s less a prediction about MCP than the same rule the web has enforced for thirty years, wearing a new coat: you can’t scale what you have to remember.