MCP Goes Stateless, and Your Session-Bound Servers Break

The Model Context Protocol's 2026-07-28 specification significantly changed the behavior of Streamable HTTP, removing protocol-level sessions, the `Mcp-Session-Id` header, and the standalone GET stream endpoint ^[1][2]. At the same time the TypeScript SDK has been split into separate packages, including `@modelcontextprotocol/server`, which means anyone already running a remote MCP server in production is looking at a code change, not just a config flag ^[3].

The reason is deployment shape. Under the old model, Streamable HTTP could maintain a protocol-level session: the client POSTed an `initialize` request, the server issued an `Mcp-Session-Id`, and subsequent requests carried that identifier so the server could associate them with the session established earlier ^[4][5][6]. That is fine on one box. Put three instances behind a load balancer and it stops being fine: if initialization lands on Server A, the session belongs to Server A, and a follow-up request routed to Server B does not necessarily know anything about it ^[7][8].

The workarounds are the familiar ones, and they are all deployment tax: sticky sessions, shared session storage, session replication, distributed coordination ^[9]. Developer Dilum Darshana, writing about migrating his own currency converter MCP server, frames the change as removing that protocol-level session dependency so that MCP servers can behave like ordinary horizontally scalable HTTP services ^[10][8]. He cites the MCP team's stated goal as allowing requests to reach any server instance without sticky routing or a shared protocol session store ^[11].

Mechanically, the new transport model is narrower. The server exposes a single MCP endpoint that accepts POST requests, each JSON-RPC request is sent as its own HTTP request, and the server responds with either `application/json` or an SSE stream associated with that request ^[12][13][14]. Requests one, two and three can land on Server A, Server C and Server B respectively with no requirement that they hit the same instance ^[15].

The part worth reading carefully before anyone rewrites a service: stateless MCP does not mean the application must be stateless ^[16]. Darshana's example is a `create_cart()` tool that returns a `cart_id`, which the next tool call then passes explicitly alongside its own arguments ^[17][18]. The state still exists; it is now represented as explicit application data rather than hidden inside a protocol session ^[19]. He says the MCP team explicitly recommends this application-level pattern when state needs to persist between calls ^[20].

That is the migration in one line: whatever your server was inferring from the session identifier, the client now has to send you. For a currency converter, which Darshana describes as intentionally simple and exposing a single `convert_currency` tool, that is close to free ^[21][22][23]. For anything that accumulated context across an initialized connection, it is a redesign of the tool signatures, because the arguments have to carry the continuity.

What to watch: whether existing clients and hosts follow the spec onto the POST-only endpoint, since a server that has dropped `Mcp-Session-Id` and the GET stream is no longer speaking the older shape ^[2][12]. Watch the package split too. `@modelcontextprotocol/server` being a distinct install means dependency pins and build steps move, and the migration is coupled to the spec change rather than sequenced after it ^[3]. If you run MCP servers behind a load balancer today, the honest read is that you were paying for sticky routing to hold up an abstraction the protocol has now dropped ^[9][11].