The server stops remembering

For a remote MCP server, remembering an ongoing protocol session shaped the deployment around it. Later requests needed to find the same running instance, or the session needed to be managed elsewhere.

Claude Developers says MCP is now stateless at that protocol layer. That does not erase application state; it removes the need for the server to remember the protocol session between requests.

That distinction is easy to flatten and important to keep. A product may still need databases, accounts, job records and other application state. The release changes the protocol-session burden, not every stateful part of the system.

Claude Developers says that shift makes remote servers easier to deploy and scale. The practical consequence is more freedom to choose infrastructure without treating the same server instance as the keeper of a client session.

Claude Developers calls MCP 2026-07-28 its largest update since launch. That is its release claim, not an independently established comparison.

The more concrete announcement is the deployment change: serverless and edge infrastructure, plus horizontal scaling behind a load balancer, are now options Claude Developers explicitly names for remote servers. The thread does not establish measured gains in cost, latency or scale.

“Now that MCP is stateless, you can deploy on serverless and edge infrastructure, or scale horizontally behind any load balancer.”

Claude Developers on X, post 2082164250496348268

The source is one official Claude Developers thread. It is direct evidence of what Claude Developers announced, rather than an independent test of every implementation.

Its language supports a narrower conclusion: the protocol-session constraint has changed, and Claude Developers names several deployment routes that may now fit remote MCP servers. It does not guarantee a migration path, universal compatibility or a production outcome.

The release thread’s wording is useful because it describes the change at the protocol level. It does not demonstrate performance in a particular environment, or establish that every MCP client and server behaves identically after the update.

A supplier video poster is available as visual provenance, but the video itself was not reviewed. The bounded evidence remains the verified release wording and the approved source assets.

Previously, a remote server had to remember the protocol conversation with a client. That memory made continuity part of the deployment problem: the next request had to reach the right place, or the session had to be preserved.

With a stateless protocol request, the next request does not depend on that remembered server-side session. Claude Developers says that is why remote servers can fit serverless, edge and horizontally scaled deployment patterns.

The release is not an instruction to remove state from an application. It is an opportunity to decide which state belongs to the application and which was only there because the remote protocol session required it.

Claude Developers also points to MCP Apps, Tasks and Enterprise Managed Auth as extension examples. Their presence signals a formal route for richer capabilities, not a claim that each one is available in every environment or ready for every use case.

The useful change is not that state disappears. It is that protocol-session memory stops dictating where a remote MCP server must live.

Altior AI News analysis based on the Claude Developers release thread

Claude Developers’ announcement points to a cleaner split: a stable, stateless protocol core for requests, with extensions providing a formal lane for capabilities that do not belong in that core.

That split is promising because it makes the deployment question more honest. We can choose an infrastructure shape for the service in front of us, preserve the application state it genuinely needs, and keep stronger claims about outcomes until evidence supports them.