MCP stopped being a connection you hold. It became an API you call.
The MCP protocol moved from a bidirectional, session-shaped model to a request/response core. If you run MCP servers behind a load balancer, on serverless, or across a replica pool, this change is the difference between sticky routing and plain round-robin.
This piece walks the architecture in three frames: how it was, how it is, and why the shift helps you ship.
Remote MCP used to behave like a held-open relationship.
You started with initialize. The server could mint an Mcp-Session-Id. Your client stored that id and sent it on later calls. The load balancer often went sticky so every request for that session landed on the same instance. A long-lived GET SSE stream carried server-to-client traffic. Ending the session meant an explicit DELETE.
That design worked for a single process. It fought you at scale.
Why sticky? Because session state lived on Instance A. Later calls had to come back to A. Instance B and C could not serve you for that session. Kill Instance A and the whole session dies with it. The client starts over.
Connection lifecycle, in short:
If you have run sticky sessions for any HTTP API, you already know the ops cost: affinity config, session stores, expiry, garbage collection, and painful failovers. The latest update flipped the core to stateless.
There is no negotiation handshake. Every request carries its protocol version and client capabilities in _meta. The server accepts or rejects each request on its own. Protocol-level sessions are gone. Mcp-Session-Id is no longer part of the model.
HTTP shape gets simpler too. Streamable HTTP for the modern revision is POST-oriented. Standalone GET streams and DELETE session teardown are out of the protocol path. Long-lived push, when you need it, is explicit: POST subscriptions/listen and hold an SSE only for that subscription.
Now: no connection to hold. Every request stands on its own.
Here’s the Request lifecycle:
POST with _meta
App state did not disappear. It moved. Instead of hiding carts, browsers, or DB connections inside a protocol session, the server mints an explicit handle (a string in a tool result). Later tools take that handle as an argument. You own TTL and cleanup. The protocol stays sessionless.
That is the architectural bargain: protocol state is gone; application state is visible and portable across replicas.
Put the two models side by side and the production story is obvious.
Four outcomes matter most when you operate the system:
Stateless at the protocol layer does not mean zero state in your product.
You still design handles, TTLs, and auth around those handles. Broken SSE streams mean you re-issue the request; stream resumability via Last-Event-ID is gone. Dynamic “tools appear after connect” patterns are out; lists must stay session-independent. Clients that support both legacy and modern revisions need a clear probe and fallback path.
If your gateway or auth layer was keyed on Mcp-Session-Id, plan a migration. The state moved into the open: request _meta plus explicit handles you manage.
Thanks for reading! If you have any questions or feedback, please let me know on [Medium](https://medium.com/@kushalbanda) or [LinkedIn](https://www.linkedin.com/in/kushalbanda/)
MCP is Now Stateless ! was originally published in Towards AI on Medium, where people are continuing the conversation by highlighting and responding to this story.