MCP’s Stateless Redesign: What Changed and Why Theo Is Optimistic

I have been one of MCP’s more vocal critics. Connecting agents to tools is a useful idea, but the experience of running MCP servers has often felt heavier than it should. The newest version is the first change that makes me think the protocol is moving in the direction I wanted.

In my own setup, agent workflows can create many processes and repeat setup work as new agents start. I have also seen macOS’s syspolicyd consume significant CPU and suspect the process churn contributes. That is an observation about my setup, not a benchmark or proof that this specification alone fixes it.

Anthropic is rolling out support for MCP version 2026-07-28. Its central change is a stateless protocol core, alongside authorization improvements and official extensions. My interest is less in a new version number than in whether the mechanics of calling a tool have become simpler.

Previously, a client initialized the protocol before making ordinary requests. In the new core, requests are self-describing: the relevant metadata accompanies the request, and the initialize/initialized handshake and Mcp-Session-Id are removed. A client that wants to inspect capabilities up front can still use optional discovery.

That matters because a server no longer needs a protocol session merely to understand a request. For an agent that calls a tool occasionally, there is less protocol ceremony to coordinate. It does not follow that every old implementation kept a TCP connection open, or that the new version eliminates every local process.

Stateless at the protocol layer also does not mean that a useful application cannot have state. A tool can expose an explicit handle for a resource and accept it in a later request. The important distinction is that the application makes that relationship explicit instead of depending on an implicit protocol session.

This should fit serverless and edge deployments more naturally. A request can be sent to an available instance without keeping a protocol session pinned to one backend or sharing session state between all instances. You still have to operate the service, and application-specific state may require its own storage and routing.

The release also includes work on extensions and authorization. Apps and tasks address richer interactions, while authorization changes harden the system. A stateless core does not make a tool automatically safe: what it can access, who can invoke it, and how its output is handled still matter.

The deployment diagram makes the distinction visible. The older session-oriented picture shows a client routed back to an instance or a shared session store; the new picture shows independent requests distributed across instances. That describes protocol session management, not a claim that TCP connections themselves can never be reused.

Simon Willison wrote about trying the new specification and compared the old setup exchange with the new request format. The comparison shows why I find the change appealing: a tool call can look much closer to an ordinary request instead of requiring a separate protocol setup step first.

There can still be interactions requiring more than one exchange. For example, a workflow may need further user input and then continue. Stateless protocol requests simplify how those exchanges are carried, but they do not turn every multi-step task into a single call.

Willison built mcp-explorer, a command-line tool for inspecting servers. His example queries an Agentic Mermaid server and lists operations to execute code and render diagrams as SVG, ASCII, or PNG. Being able to inspect a server from a small CLI is a practical way to understand what it offers.

He also built datasette-mcp, a plugin that exposes tools to list databases, inspect schemas, and execute read-only SQL against a Datasette instance. He says earlier attempts had been frustrating, whereas the stateless specification helped him arrive at a version he was comfortable releasing.

Those examples show the potential for agents and chat tools to discover useful capabilities without every developer designing a bespoke integration. They are examples of working approaches, not proof that every existing server will migrate without changes.

The catch is the version. A client and server must agree on the protocol they speak, and the transition will take time. Some implementations may support or bridge multiple versions, so incompatibility is not inevitable, but you cannot assume an older client will understand a newly updated server.

This is a bit like advertising support for a connector without explaining which version or capabilities are actually present. “Supports MCP” is a useful starting point, but developers still need to check what a particular client and server implement and test the combination they intend to deploy.

That migration burden is real even if the destination is better. Existing implementations have to update, and users may spend a period navigating mixed versions. I am optimistic because the redesign addresses a structural concern, not because changing a specification instantly updates the entire ecosystem.

The broader promise is a common interface for giving agents access to tools. When the protocol is simpler to use and deploy, that common interface becomes more attractive. Whether an individual integration is reliable or efficient still depends on the client, server, tool, and infrastructure around it.

My position has changed: I am much more willing to use MCP when the implementation supports this newer design. I still want to see the ecosystem actually adopt it and handle compatibility well, but the direction is encouraging.

The real test will be the tools people build and the experience of running them. For now, I am happy to see the protocol take a serious step toward the simpler model I had hoped for.