MCP is going stateless — and it changes how you write your next server
The session is dead. Your next server runs behind a round-robin load balancer or it doesn’t scale.
The MCP spec’s release candidate makes the protocol stateless by default, driven by six SEPs (anchored by SEP-1442, "Make MCP Stateless"). The <code>Mcp-Session-Id</code> header and the protocol session are gone; the <code>initialize</code> handshake is removed, with version, client info, and capabilities now riding in <code>_meta</code> on every request. A formal lifecycle policy lands too (min 12 months between deprecation and removal), and Roots, Sampling, and Logging enter deprecation.
This is the difference between "my server needs sticky sessions and a shared session store" and "my server is a stateless HTTP handler behind any load balancer." Clients cache <code>tools/list</code>; gateways route on a header instead of tracking connections. If you’ve been deploying remote MCP servers, your scaling story just got dramatically simpler — but only if you stop using the session to stash state.
I’ve been bitten by exactly this: an MCP server working on one worker, then returning half-initialized garbage the moment a second process picked up a request, because the handshake state lived in one process’s memory. For a Laravel MCP server, stateless-by-default is liberating: treat every request as a fresh authenticated call and make state explicit — a handle the client passes back (a record id, a Redis key with a TTL), never an implicit session. The spec just made it mandatory.
EC TV is written by Eduardo Cruz — a senior Laravel engineer who ships production AI agents and MCP servers.
Work with me → Read the deep-dives