MCP Goes Stateless, and Any Server Can Answer Any Request

The Model Context Protocol is the plumbing between AI agents and the tools they call. When I wrote about MCP in January, it was already the default way to plug tools into Claude and friends. On Tuesday it got its biggest change yet.

The 2026-07-28 specification makes the protocol stateless. No handshake, no session ID. The maintainers' headline line is the one that made my distributed-systems brain sit up: "Any request can now land on any server instance behind a plain round-robin load balancer without needing shared storage."

What changed

Until now, an MCP conversation started with a handshake. The client sent initialize, the server replied with its capabilities, the client confirmed, and over HTTP the server handed back an Mcp-Session-Id. Every later request carried that ID, so the server could remember who it was talking to.

The new spec removes all of that. From the changelog:

• No more initialize handshake. Every request carries its protocol version and client capabilities in its _meta field. Clients should identify themselves on each request, and servers in each result.
• No more Mcp-Session-Id. List endpoints such as tools/list no longer vary per connection.
• A new server/discover call. Servers must implement it to advertise their versions and capabilities. Clients can call it first, but don't have to.
• Server-initiated requests become retries. If a tool needs more input mid-call (say, asking the user to confirm something), the server no longer holds a stream open and calls back. It returns a result marked input_required, and the client retries the original request with the answers. The spec calls this Multi Round-Trip Requests.
• No more stream resumption. If a response stream breaks, the in-flight request is lost and the client must send it again as a new request.

Here's a simplified shape of a request under the new spec (headers plus JSON-RPC body; the tool name is made up):

POST /mcp
Mcp-Method: tools/call
Mcp-Name: search_orders
MCP-Protocol-Version: 2026-07-28

{
  "jsonrpc": "2.0",
  "id": 7,
  "method": "tools/call",
  "params": {
    "name": "search_orders",
    "arguments": { "customer": "c_123" },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientCapabilities": {},
      "io.modelcontextprotocol/clientInfo": { "name": "my-agent", "version": "1.0" }
    }
  }
}

Everything the server needs to answer is in that one request. That's the whole idea.

Why sessions were the problem

If you've scaled a web app, you've met this. A session that lives in one server's memory means the next request has to reach that same server. So you add sticky routing at the load balancer, or you move session state into shared storage like Redis. Both work. Both add moving parts, and both make serverless and edge hosting awkward, because those platforms want any instance to handle any request.

The new spec takes the same exit the web took years ago: make each request self-describing. The release also adds a few things infrastructure people will appreciate:

• Routing headers. Mcp-Method and Mcp-Name are now required on HTTP requests, so a gateway can route or rate-limit without parsing the JSON body.
• Cache hints. List results now carry ttlMs and a cacheScope of public or private, and servers should return tools in a deterministic order. The changelog says that's partly to improve LLM prompt cache hit rates, which matters if your tool list sits at the top of every prompt.
• A deprecation policy. Features now get at least twelve months between deprecation and removal.

Where the state goes now

Dropping protocol sessions doesn't make your app stateless. The maintainers say so directly: "Dropping the protocol-level session doesn't force your application to be stateless."

Their recommendation is to mint an explicit handle from a tool and have the model pass it back as an argument. A shopping-cart tool returns cart_8f2a; the next tool call includes it. The blog argues this is actually better than hidden session state, because the model can see the handle and pass it between tools.

If you come from REST, this is a resource ID. If you come from distributed systems, it's moving state out of the connection and into the data, where it can be stored, logged and retried.

Which brings up the catch. Without stream resumption, retries become normal, so tool calls with side effects need to be safe to repeat. A "place order" tool should accept an idempotency key. That's not new advice, but MCP servers that leaned on sessions could get away without it.

The migration cost

This release has breaking changes. Per the spec's compatibility matrix:

• A new client talking to an old server fails, unless the client is "dual-era" and falls back to initialize.
• An old client talking to a new-only server fails. Old clients have no way to move forward.
• A server can support both eras on the same endpoint.

The Tier 1 SDKs (TypeScript, Python, Go and C#) support the new version as of release day, and Rust has it in beta. Roots, Sampling and Logging are deprecated but keep working for at least a year. OAuth Dynamic Client Registration is deprecated in favor of Client ID Metadata Documents.

What I want to try

Nothing I've built depends on this yet, so here's my try-list:

1. Run a small MCP server on a serverless platform with two instances and no shared storage, and confirm the round-robin claim end to end.
2. Build one stateful flow with handles, like a multi-step form, and see how well the model carries the handle between calls.
3. Test the retry path: kill a response stream mid-call and check that a side-effecting tool doesn't run twice.
4. Check the fallback: point a new client at an old server and see what error a user would actually get.

Quick hits

• Anthropic says its models breached three organizations during cyber evaluations (Jul 30). Prompts told Claude it was in a sealed simulation, but a misconfiguration with evaluation partner Irregular left live internet access. Anthropic reviewed 141,006 runs, found three incidents involving Claude Opus 4.7, Claude Mythos 5 and an internal research model, paused all cyber evaluations on July 23, and notified the affected organizations on July 27. It lands a week after OpenAI's admission, which I covered in The Decode #003.
• OpenAI cuts GPT-5.6 Luna's price by 80% (Jul 30). Luna drops to $0.20 per million input tokens and $1.20 per million output, and Terra is 20% cheaper. That's about three weeks after the GPT-5.6 family launched.
• Shared Claude chats and Artifacts showed up in Google results (Jul 27). Searches for shared Claude links surfaced conversations, some with sensitive personal and company data. Anthropic says it doesn't give chat directories or sitemaps to search engines, and that links become searchable once shared somewhere public. If you've shared a chat link, check whether it should still be live.

What I'm watching

How fast the major MCP clients ship support for the new spec, since a new server is only useful once the clients can talk to it.

Sources

MCP 2026-07-28

• Model Context Protocol, 2026-07-28 specification changelog (Jul 28, 2026)
• Model Context Protocol blog, release post for the 2026-07-28 specification (Jul 28, 2026)
• Model Context Protocol, versioning and compatibility
• The Register, MCP gets an enterprise makeover (Jul 29, 2026)

Quick hits

• Anthropic, investigating three incidents in its cybersecurity evaluations (Jul 30, 2026)
• OpenAI, API changelog entry on the GPT-5.6 Luna and Terra price cuts (Jul 30, 2026)
• eWeek, coverage of the GPT-5.6 price cuts (Jul 31, 2026)
• TechCrunch, PSA on Claude shared chats and Artifacts in Google results (Jul 27, 2026)
• Axios, Google search indexing public Claude artifacts (Jul 27, 2026)