MCP went stateless in July. Why your MCP server just got cheaper to run, and what to change

On 28 July the Model Context Protocol maintainers published the 2026-07-28 specification, and the headline change is the one server operators have been asking for since the protocol appeared: MCP is now a stateless request-and-response protocol rather than a stateful bidirectional one.

The initialize handshake is gone. So is the Mcp-Session-Id header. Each request carries its protocol version, client identity and capabilities in its own metadata, which means any request can land on any server instance behind a plain round-robin load balancer with no shared storage behind it. Method and tool names travel in HTTP headers, Mcp-Method and Mcp-Name, so a gateway or a rate limiter can route and meter without parsing the body. Tool, prompt and resource lists carry cache hints and a deterministic order. Server-to-client requests such as asking the user for a confirmation now work through Multi Round-Trip Requests, where the server returns input_required and the client retries with the answer attached, instead of holding a stream open.

The TypeScript, Python, Go and C# SDKs shipped the same day. Amazon Bedrock AgentCore and Cloudflare Workers supported the spec from launch. And the maintainers committed to a twelve-month minimum deprecation window from here on, so this is the last time an upgrade should arrive as a surprise.

For a SaaS company that shipped an MCP server in the last year, this release changes three things: what the server costs to run, how it is deployed, and what needs rewriting.

Why it was expensive before

Under the previous spec, an MCP server had to remember each client across a conversation. That sounds harmless until you try to run more than one instance. Sessions had to be pinned to an instance or shared through a store, long-lived streams had to be kept open for the server to talk back, and every scaling event, deploy or restart risked dropping conversations mid-call.

Teams solved this in three ways, all of them expensive. Some ran a single large instance and accepted the risk. Others added a shared session store and a sticky load balancer, which worked and doubled the moving parts. A few put a stateful proxy in front of a stateless backend and got both problems. Every one of those is an infrastructure cost that had nothing to do with what the server actually did for the model.

The new spec makes the server a first-class HTTP workload. It scales horizontally on whatever you already run web services on, it survives deploys, and the serverless platforms can host it without workarounds. For most companies that is the difference between an MCP server that needs its own operations story and one that ships like any other endpoint.

What actually gets cheaper

Compute. You can run the server on the same autoscaled, spot or serverless footprint as the rest of your API rather than on pinned instances sized for peak.

Tokens, on the client side. Cacheable tool lists mean a model's upstream prompt cache stays stable across reconnects instead of being invalidated every time the catalogue is re-fetched. If you have wondered why your agent's cache hit rate was lower than the prompt structure suggested, the tool list was often the reason.

Engineering time. The session store, the sticky routing and the reconnection logic come out of the codebase.

Observability. Header-based routing means your existing gateway can meter tool calls by name, per customer, without a custom parser. Several hosting providers said as much in the launch post: the stateless model is what lets them show customers which tools are used and which are missing.

What you have to change

Remove the session. If your server stored anything against the session ID, that state needs a new home. The maintainers' guidance is to mint an explicit handle from a tool and have the model pass it back as an argument. In practice this is better than hidden transport state anyway, because the model can see the handle and thread it between calls, and because a handle in an argument is visible in the logs.

Send the headers. Streamable HTTP requests must now include Mcp-Method and Mcp-Name. Clients built on the updated SDKs do this. Anything hand-rolled does not.

Rewrite elicitation and sampling. If your tools ask the user for confirmation mid-call, such as before creating a billable resource or running a destructive query, that flow moves to Multi Round-Trip Requests. Supabase's team noted this is what finally lets a stateless server confirm cost with the user before acting. It is the same pattern our commerce and finance clients need for approvals, and it now works without a persistent connection.

Move long-running work to the Tasks extension. Tasks have left the experimental core and live in io.modelcontextprotocol/tasks, with polling through tasks/get and a single subscriptions/listen stream for change notifications. Anything that took longer than a request timeout should be a task.

Tighten authorisation. Clients must validate the issuer parameter before redeeming an authorisation code, credentials are bound to the issuer that minted them, and Dynamic Client Registration is deprecated in favour of Client ID Metadata Documents. DCR still works for now. Plan its removal.

Add cache hints. Return ttlMs and cacheScope on list responses so clients can stop re-fetching your catalogue.

For a well-structured server on an official SDK this is a few days of work. For a server that leaned on session state for multi-step flows it is a couple of weeks, most of it spent designing the handles.

The strategic point

Every argument for building an MCP server rested on it being a cheap adapter over a clean product surface. The stateful protocol undermined that, because the adapter needed its own infrastructure. The July spec restores it. An MCP server is now roughly as hard to run as a REST endpoint, which removes the last operational excuse for a SaaS company not to have one.

It also raises the bar. When the server is easy to run, the differentiator is what it exposes: whether the tool surface is complete, whether permissions are scoped per customer, whether approvals are in the loop, whether the audit trail exists. That is the agent-native SaaS work, and the protocol change means more of the budget goes there and less to keeping the lights on.

Frequently asked

What changed in the MCP 2026-07-28 specification? MCP became a stateless request-and-response protocol. The initialize handshake and Mcp-Session-Id header were removed, requests carry their own version and client metadata, method and tool names travel in Mcp-Method and Mcp-Name HTTP headers, list responses include cache hints, server-initiated requests such as elicitation use Multi Round-Trip Requests, Tasks moved into a formal extension, and authorisation was hardened with issuer validation and a move from Dynamic Client Registration to Client ID Metadata Documents.

Do existing MCP servers need to be rewritten? Servers on the official TypeScript, Python, Go or C# SDKs can upgrade with the published migration notes. The work is removing session state (replacing it with explicit handles passed as tool arguments), sending the required headers, moving elicitation and sampling to MRTR, moving long-running work to the Tasks extension, and updating authorisation. The maintainers have committed to a twelve-month minimum deprecation window.

Why does a stateless MCP make servers cheaper to run? Any request can be served by any instance behind an ordinary load balancer, so the server runs on the same autoscaled or serverless infrastructure as the rest of an API, with no session store, sticky routing or held-open streams. Cacheable tool lists also keep the model's prompt cache stable across reconnects, which reduces token cost on the client side.

Related reading

• How Shopify rebuilt for headless commerce, and won the agent era
• Running Meta ads from Claude: a one-week test of the Meta Ads MCP
• Agent-native SaaS service

The protocol has stopped being the hard part. What your product exposes through it is the whole game now.