MCP Goes Session-less: What the 2026-07-28 Spec Change Means for Developers

The 2026-07-28 Model Context Protocol release candidate is the most consequential spec revision since MCP launched. The headline change is that the protocol drops mandatory persistent sessions and replaces them with a streamable HTTP transport where each request is self-contained. If you have shipped MCP server implementations, or you are mid-deployment of an MCP-connected agent pipeline, this matters to your architecture now — even though the candidate is not yet the final spec.

The AAIF framing is accurate: "This one is different." Most MCP spec iterations have been additive. The session-less change is subtractive. It removes an assumption that many current implementations bake into their connection management, context propagation, and error recovery code.

What "session-less" actually means in practice

In the previous MCP model, a client and server established a session, and that session carried shared state across multiple tool calls. The session had an identifier, lifetime management, and was used to correlate context across turns. Servers could rely on per-session memory without requiring clients to re-send context on every request.

The 2026-07-28 release candidate changes the fundamental contract. The new transport uses plain HTTP semantics: each request must carry everything it needs. The server is not permitted to rely on ambient session state. Context that previously lived in the session layer must now be either encoded in the request itself, derived from a deterministic handle that the client presents, or managed in an explicit external store.

The wire format reflects this shift. Requests use headers rather than session tokens to identify the protocol version and route:

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

{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"search","arguments":{...}}}

There is no Session-Id header. There is no handshake to establish a session before the first call. The server that receives this request must process it statelessly, or retrieve state through a handle embedded in the arguments.

The explicit-handle pattern: the safe migration path

SDK 1.3.0, which accompanies the release candidate, introduces the explicit-handle pattern as the recommended replacement for session state. The idea is that a tool that needs to maintain continuity across calls returns a handle on the first invocation. Subsequent calls from the client include that handle as an argument. The server stores and retrieves its state by handle.

Critically, this pattern survives the session-less upgrade without breaking. The Medium piece covering the spec change is specific: "The explicit-handle pattern works today and survives the upgrade. Nothing in SDK 1.3.0 stops you from writing tools that mint a handle and require it." This means you can migrate incrementally. Existing tools that already use handles work against both the old session-based transport and the new stateless one.

For tool implementors, the migration checklist looks like this:

• Audit session-dependent behaviour: Any server-side code that reads from a per-session store needs to move to a handle-keyed store instead.
• Return handles early: If your tool spans multiple calls, mint a handle on the first call and document it as a required argument for subsequent ones.
• Test stateless cold-start: Can your server process a well-formed request with zero prior interaction? If not, you have hidden session coupling to fix.
• Validate error behaviour without sessions: Session loss errors from the old model no longer exist. Make sure your error paths do not reference session state in their messages or retry logic.

What changes for host authors

Host applications — editors, agent runtimes, CI integrations — that manage MCP connections have the most disruptive migration if they built connection management around session lifecycle. Specifically:

Connection pools change shape. In the session model, a pool entry carried a live session with state. In the stateless model, a pool entry is just an HTTP client pointed at a server endpoint. State is out of band. This simplifies lifecycle management at the cost of making application code responsible for whatever continuity it needs.

Reconnection logic gets simpler. Session re-establishment after network interruption was a known pain point. With stateless HTTP, a request that fails due to a connection error can be retried without any session negotiation. This is a genuine operational improvement for agent pipelines that run over unreliable networks or across cloud boundaries.

Multi-tenant server deployments change.) Shared session-based state was a latent security surface: cross-tenant session leakage was a real risk. Stateless transport removes that surface. Each request must supply its own credentials and context; there is no ambient session to leak into a neighbour's call.

Production impact: where today's deployments are exposed

If your team is running production MCP integrations today, three patterns are most likely to require rework:

1) In-memory session caches

Any server that caches per-session context in memory — conversation history, file scan results, tool config — is stateful by design. Migrating this to a handle-keyed external store (Redis, Postgres, a signed JWT) is straightforward in concept but requires careful attention to TTL policy, invalidation, and handle security. Do not copy session-level access controls directly to the handle layer; review them.

2) Session-scoped credentials

If your tools store credentials or scoped tokens at the session level, those tokens need a new home. Options include short-lived per-request tokens derived from caller identity, handle-embedded tokens that the caller presents explicitly, or out-of-band auth via standard HTTP auth headers. Any approach is valid; the risk is in accidental promotion of a session-scoped secret to a longer-lived handle credential without re-evaluating its scope.

3) Streaming tool calls

The new streamable HTTP transport affects how servers push intermediate results. The session model allowed servers to push updates over a persistent connection. The stateless model uses HTTP streaming per-request. Servers that implement long-running or streaming tools — file indexers, background search jobs, watch-mode tools — need to validate that their streaming implementation fits the new per-request streaming model, not a persistent channel assumption.

Timing and spec stability

The 2026-07-28 date on the release candidate is the proposed spec version identifier, not a guarantee of ratification on that date. The MCP specification process moves in release candidates before finalising. SDK 1.3.0 implements the candidate, which means it is testable now. Teams should not wait for the final stamp to start migration work — the pattern changes in the RC represent the direction the ecosystem is committing to.

Major MCP host integrations — Anthropic's Claude Desktop, Cursor, Cline, and VS Code Copilot — are expected to ship support for the stateless transport either with the RC period or within weeks of finalisation. If your server is not ready by then, connections from updated hosts may break or degrade depending on whether those hosts maintain backward compatibility shims.

What this does not change

The tool capabilities model is unchanged. The JSON-RPC framing is unchanged. Server discovery (via well-known endpoints and capability documents) is unchanged. The resource and prompt abstractions are unchanged. This is a transport-layer and session-model change, not a capability redesign. If you are building a new MCP server today, using SDK 1.3.0 and the stateless model from day one is the cleanest path. For existing servers, the migration scope is limited to the parts of your code that explicitly read or write session state.

The bottom line for teams with MCP in production

Audit your session dependencies this week. Most production MCP servers have two or three call sites that rely on session context, and those sites are usually well-known to the team. The explicit-handle migration is a small, targeted rewrite — not an architecture overhaul. Waiting for the spec to finalise before starting that audit is a risk: host upgrades will not wait for your server.

For teams planning new MCP integrations: build stateless from the start. The direction is clear, the SDK is ready, and the operational benefits — simpler retry logic, no session leakage surface, stateless horizontal scaling — are real advantages that the old session model never delivered cleanly.

The session-less spec is not a disruption to what MCP is. It is a correction to what MCP was always trying to be: a clean, verifiable contract between models and tools that does not require either side to carry ambient state it did not explicitly negotiate.