Over the past few weeks, AI tools that worked reliably for months have started failing in oddly consistent ways: connections drop without warning, tools appear in the interface but refuse to load, and the error messages, when they appear at all, explain nothing. These failures share a common origin in the protocol layer that connects AI models to external services.

The Model Context Protocol, the open standard that defines how AI models call external tools, is finalizing its largest revision since launch. The revision replaces the session-based connection model that produced these failures with a stateless architecture, and the change reshapes the relationship between AI models and every tool built on the standard.

Built for local use

Anthropic released the Model Context Protocol in November 2024 to solve a straightforward problem: AI models had no standardized way to call external tools. Every integration required custom wiring, a different adapter for each combination of model and service. MCP defined a common interface through which a model could call a tool, receive structured results, and feed them back into its reasoning, regardless of what sat on the other end.

The original protocol managed these connections through sessions. Each conversation opened with a handshake that issued a session identifier, and all subsequent requests carried that identifier in an HTTP header, routing them to the specific server instance that had started the conversation and held its state in memory.

For a developer running a single MCP server on a laptop, this architecture imposed no meaningful burden. Anthropic launched MCP inside Claude Desktop, where one user, one machine, and one server instance was the expected configuration, and sessions worked fine.

Falling over at scale

MCP adoption grew rapidly through 2025 and into 2026, expanding from local desktop setups into web-hosted services, cloud-based AI platforms, and multi-user deployments. In these environments, the session model began producing failures that neither the user nor the AI model could diagnose.

The most reported failure involved stale session identifiers. A server restart or redeployment would invalidate an existing session, but the client continued sending the old identifier with every request. The server rejected these requests, and the client had no recovery path — it did not re-initialize automatically, so the user saw tools that appeared connected but refused to function. Bug reports on Anthropic’s repositories described tools that loaded into the interface normally, only to fail on every call. Disconnecting and reconnecting, or even deleting and re-adding the tool, sometimes failed to clear the cached session.

The session model also imposed scaling constraints. Standard load balancers distribute requests freely across server instances, but MCP sessions required that each request reach the specific instance holding its state. Operators who wanted to run MCP at any meaningful scale had to configure sticky routing or build shared session stores — infrastructure complexity that the protocol’s own design demanded.

Self-contained stability

The MCP specification’s release candidate, published on May 21, eliminates sessions from the protocol entirely. The final specification ships on July 28 after a ten-week validation window for SDK maintainers and server implementers.

The handshake and the session identifier are both gone. Each request now carries its own context inline: protocol version and client capabilities travel in a metadata field on every call, and new required HTTP headers identify the operation being performed, allowing infrastructure to route requests without inspecting the payload. Any server instance can handle any request because no instance-specific state is assumed.

MCP servers can now sit behind ordinary round-robin load balancers, scale horizontally by adding instances, and restart without orphaning active connections. The entire class of stale-session failures disappears, because there are no sessions to go stale.

State on the surface

Many tools genuinely need to persist state across calls: a shopping cart accumulating items, a multi-step workflow tracking progress, a database cursor paging through results. The new specification handles these cases through what it calls the “explicit-handle pattern.” The server mints an identifier — a cart_id, a workflow_id — on the first call and returns it as part of the response. The client passes that identifier back on subsequent calls. The state still exists, but it lives in the tool’s own storage, addressed by a handle that travels as a regular parameter rather than in transport-layer metadata.

This design has a secondary benefit: the AI model can now see state. Session identifiers lived in HTTP headers that the model could not access, but explicit handles appear as ordinary tool parameters, visible to the model’s reasoning process. An agent managing a complex task can track which workflow handles are active, decide when to resume or abandon one, and log the identifiers for debugging, all as part of its visible reasoning chain.

Protocols incoming

The specification finalizes on July 28, but the migration will take longer. Server authors must remove session logic, client implementations must update, and the TypeScript SDK ships under entirely new package names rather than as a version bump to the existing package. Anyone running custom MCP tools should expect a bumpy few months as implementations catch up, and some of the tool-loading instability that users have reported in recent weeks may already reflect this transition in progress.

Every major API and cloud service on the web already operates on the principle that requests carry their own context. MCP’s original session model was an outlier in this landscape, and eliminating it brings AI tool infrastructure into alignment with patterns that engineers have refined over decades.

Subscribe now

AI Central

Growing Pains