MCP just learned the trick your phone company never did

Every operator asks the same question

Call almost any customer service line, get transferred twice, and you already know what happens. You explain your account number again. You explain the problem again. The person on the other end has no memory of the first two calls, because the only thing that carried your context was you, saying it out loud, for the third time.

That was roughly how MCP worked until now. MCP is the protocol that lets Claude talk to the tools you already use, Slack, a database, an internal system, and every connector built on it used to start with something very close to that phone call.

The handshake behind the scenes

An MCP server used to open with a handshake. Your app said hello with an initialize request, the server handed back a session ID, and every message after that had to go back to the exact server instance that issued it. If a company ran three copies of the server behind a load balancer, every request from one client had to keep landing on the same copy, a setup engineers call a sticky session.

Sticky sessions are the detail nobody wants to deal with, and they show up the moment anything runs at real scale. You need routing rules that pin a client to one server, or a database just to remember who's mid conversation with whom. It also made serverless hosting nearly unworkable, because a serverless instance can disappear the moment it finishes a request, taking the session ID with it.

A note that carries the whole story

The protocol just dropped that entirely. There's no handshake anymore, and nothing left to keep track of afterward. Every request now carries what the server needs to answer it on its own, client info, protocol version, a header naming exactly what's being asked for. It's less like a phone call and more like a note that already has your whole story written on it, so whoever picks it up can just read it and respond. Any server instance can answer any request, because none of them need to remember you specifically.

That single change is also why MCP servers can finally run comfortably on serverless infrastructure. A function that spins up, answers one request, and vanishes works fine now, because there's nothing left for it to forget.

A lesson protocols keep relearning

Twenty years ago, REST taught the web the same thing. If you want something to scale, the context of a request has to travel with the request, not live in a connection sitting on a specific server. MCP tried a stateful model first, the same way plenty of early web protocols did, and it's now walking back to the same conclusion REST already reached. That's not a knock on the original design. Session based protocols make perfect sense right up until the moment you actually need to scale, and MCP simply hadn't hit that moment yet.

What it means for the tools you already use

Here's the part that matters if you don't build software for a living. A stateful MCP server needed someone who genuinely understood session management and load balancing before it could handle real traffic. A stateless one looks a lot more like an ordinary API endpoint, something a small team can stand up in an afternoon.

That changes who bothers to build one. The accounting software you use, the booking system, the internal tool your ops person swears by, all of them just got a cheaper path to offering a Claude connector. The honest expectation is that more of them will, not because the idea changed, but because the cost of trying it dropped.

The part that doesn't change

None of this touches the question that actually matters once Claude is connected to something, which is what it's allowed to do once it's in. Whether a request gets answered by one server or another has nothing to do with whether the action behind it is safe. A connector that lets Claude read your calendar or your inbox should still be built to read, not to write, unless someone has explicitly signed off on that. The protocol getting easier to build on is a reason to expect more of these connectors showing up. It isn't a reason to be looser about what any one of them is allowed to touch.