The Responsibilities MCP Separates, Part 1 — Moving Protocol State Out of the Session

MCP is the protocol between an agent such as Claude (which contains an MCP client) and an MCP server that exposes tools between that agent and business systems. The way that communication is handled changes substantially in the MCP v2026-07-28 release candidate.

An agent selects a tool exposed by an MCP server and calls the operation it needs. The MCP server accesses a database or an existing business system and returns the result. For example, after a create_basket tool returns a basket, the agent names that basket in a later add_item call.

In a cloud deployment, several MCP server instances behind a load balancer process those calls. Previously, the router had to use the session ID carried by the next request to find the instance holding that session’s state. MCP v2026-07-28 removes that constraint so that any instance can process the same call. Business data remains on the server side, while the agent passes the IDs needed for its next call.

Earlier MCP kept a session after the handshake

Until the 2025-11-25 Streamable HTTP specification, an agent and an MCP server began with an initialize / notifications/initialized handshake. They negotiated the agent’s information and capabilities and the protocol version to use; the server then returned Mcp-Session-Id.

The agent attached that Mcp-Session-Id to every subsequent request, including tools/call. The receiving MCP server used the ID to look up the agent information, negotiated capabilities, and selected protocol version for that session. Earlier MCP therefore kept the session created during the first handshake alive for later calls. The rationale for revisiting this design is collected in the proposal to make MCP stateless.

That model is straightforward when an MCP server runs as one local process. But business data—customer records, inventory, internal documents, or analytical systems—often calls for several MCP server instances behind a load balancer. When the next request arrived at a different instance, that instance did not have the matching session state. The router had to locate the instance from Mcp-Session-Id, or make the session information readable from a shared store.

That state is not business data such as a basket or job. It is state used to process MCP communication. Business data remains in a database or business service, and the agent can refer to it in a later tool call with a returned basket_id or task_id.

The animation keeps the two designs side by side and repeats only the path a request takes. The pink request on the left carries a session ID, so the router identifies Instance A as the instance holding its state. The pink request reaches only A as the result of that selection. The cyan request on the right can go to A, B, or C. Whether the router must choose a destination from session state is what separates the two scaling models.

In MCP v2026-07-28, the request carries what it needs

The new design removes initialize / initialized and Mcp-Session-Id from the protocol. In MCP v2026-07-28, the request itself carries the information needed to process it. The HTTP MCP-Protocol-Version header identifies the specification version; Mcp-Method and Mcp-Name identify the operation and target. The JSON-RPC body’s _meta contains agent information and agent capabilities.

Business data such as a basket or job is separate from those fields. basket_id and task_id are supplied as tool arguments, and the MCP server retrieves the target data from a database or cache. The receiving instance can process the call from that one request and the business data, without looking up an earlier exchange.

When a server needs to return its supported version and capabilities first, it uses the new server/discover operation. This is an entry point for discovery when the agent needs it, not a connection ceremony that must start every exchange. The release candidate’s migration guidance also provides a path for an upgraded agent to fall back to the earlier initialize flow when it reaches an older server.

For example, a tools/call that adds an item to basket bsk_42 looks like this:

POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: add_item
Content-Type: application/json

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "add_item",
    "arguments": {
      "basket_id": "bsk_42",
      "item_id": "sku_9"
    },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "my-app",
        "version": "1.0"
      },
      "io.modelcontextprotocol/clientCapabilities": {}
    }
  }
}

A load balancer can send that request to any instance. A gateway or rate limiter can also route and measure it from Mcp-Method and Mcp-Name without parsing deeply into the JSON-RPC body.

State has not disappeared; it has become explicit

Once the protocol session goes away, a natural question is how a process that spans several tool calls continues. The new specification does not hide that state in connection information. It puts it in the inputs and outputs of tools.

For example, create_basket returns a basket_id, and later add_item and checkout calls take that basket_id as an argument. The model passes the returned ID into its next tool call. The state can live in a database or cache, but every request must be able to refer to it.

This has a practical benefit. A session ID was a header the model could not see; an explicit handle appears in the tool schema and return value. Logs, tests, and retry logic can more readily trace which call depends on what. The application still needs to design the handle’s lifetime, per-user authorization, deletion, and idempotency.

Three checks that make the migration work

On a path that no longer uses Mcp-Session-Id, the same business operation must run regardless of which instance receives a request, while existing agents must remain connected. These three checks establish that condition in implementation and operations.

1. The tool handlers do not hold state tied to a session. Check that they do not read or write Mcp-Session-Id, connection context, or an in-memory map keyed by a session ID.
2. A follow-up tool call succeeds on another instance. In an integration test, run create_basket on Instance A and force add_item, using the returned basket_id, to Instance B. Re-running the test after restarting A verifies where the business state lives.
3. Connecting agents and SDKs handle the new specification. Connect real clients in a test environment and record which use v2026-07-28 and which still use the earlier initialize flow. Keep only the paths needed during the migration period.

Not a Claude update, but an update that separates protocol state

MCP is not a Claude-only feature. It is the protocol shared by hosts including Claude, SDKs, and MCP servers. This change is not simply an addition to the list of tools or a new way to call them; it changes the foundation for carrying MCP across cloud infrastructure.

So it is more accurate to say that protocol state previously closed inside a connection has been separated than that state has disappeared. Information needed by the protocol goes into each request; information needed by the business goes into explicit application state. With that separation, MCP servers can be operated like ordinary HTTP services, with autoscaling and restarts as normal conditions.

When a request can arrive at any instance, how does that instance establish whose request it is and which business data that agent may operate on? Part 2 follows the authentication and authorization layers along that path.

References

• Model Context Protocol Blog — MCP v2026-07-28 release candidate
• Model Context Protocol — MCP v2026-07-28
• SEP-2575 — Make MCP Stateless
• SEP-2567 — Sessionless MCP via Explicit State Handles