Anthropic, Simon Willison, and the Stateless MCP Reversal

Anthropic introduced MCP in 2024, but Simon Willison later found terminal tools more flexible. The July 28, 2026 specification has now reversed part of that verdict. It removes protocol sessions and turns remote MCP calls into self-contained requests.

That change has renewed Willison's interest and inspired two projects, mcp-explorer and datasette-mcp. More importantly, it attacks the architectural weakness that made remote MCP servers harder to deploy than ordinary HTTP services.

The Anthropic Simon Willison story is therefore not another protocol update. It is a test of whether MCP can stop competing with command-line tools and settle into a more defensible role. Skills remain attractive for teaching agents how to use existing software, while stateless MCP offers structured remote tools, discovery, authorization, and shared infrastructure.

Stateless MCP removes the session from every request path

The new specification changes MCP from a connection-centered protocol into a request-centered one.

The Model Context Protocol defines a standard interface through which AI agents can discover and call external tools. Anthropic introduced it in November 2024, and developers quickly produced servers for databases, browsers, communication platforms, and business applications.

Earlier versions imposed an initialization process before regular tool calls. The client and server exchanged their protocol versions, capabilities, and identifying information. That negotiation established context that subsequent messages were expected to preserve.

HTTP servers could also issue an Mcp-Session-Id. Clients then returned that identifier with later requests. The arrangement made a sequence of calls behave like one continuing conversation between a specific client and server instance.

That design created infrastructure consequences. A load balancer needed to route related calls toward the correct instance or place session data in shared storage. Operators also needed policies for expiration, reconnection, recovery, and cleanup.

The final 2026-07-28 revision removes the mandatory initialize handshake. It also removes the protocol-level session and its associated header. Each request now includes the information needed to interpret it independently.

The official MCP release describes the revision as the largest change since the protocol launched. Its stateless core is joined by extensions, revised Tasks support, authorization changes, and a formal feature lifecycle.

A client can now send a tool call directly. The request carries its protocol version, method, tool name, client information, and relevant capabilities. Any compatible server instance can process it without relying on a previous exchange.

The change also adds server/discover, which lets clients request server capabilities when needed. Discovery no longer forces every caller to create and maintain a protocol session.

This is different from claiming that every application must discard state. A browser automation service, shopping cart, database transaction, or research workflow can still retain information across calls.

The difference is where that information lives and how it is addressed. Instead of hiding it behind a session, the server can return an explicit identifier. The model supplies that identifier during later calls.

A browser server might return a browser_id after starting an instance. Later tools can accept that value when navigating, capturing a page, or closing the browser. A database tool can apply the same pattern to a transaction identifier.

The accepted sessionless proposal describes these values as explicit state handles. They are not a new MCP data type. They are ordinary tool inputs and outputs that make application state visible.

That visibility matters for agents. An orchestrator can share one handle with a subagent while keeping another handle isolated. It can also record the identifier for later work or hand it to another authorized process.

List operations gain a separate advantage. When tools and resources are no longer allowed to change according to an ambiguous session, clients can cache discovery results more safely. That reduces repeated calls across short-lived agents.

Stateless MCP also maps more cleanly onto familiar HTTP operations. Remote servers can use standard round-robin balancing, ordinary gateway routing, per-request authentication, and established observability systems.

This combination is what renewed Willison's attention. The update does not merely shorten the handshake. It removes an architectural commitment that previously leaked into every deployment and every client implementation.

Why the Anthropic Simon Willison reversal matters

Willison's renewed interest matters because his earlier criticism captured a real shift away from MCP among coding-agent users.

MCP attracted intense attention through much of 2025. Its value proposition was easy to understand: implement one server interface, then expose the same tools to several compatible AI clients.

Yet coding agents were improving at the same time. They gained reliable terminal access, better shell use, and stronger abilities to inspect documentation. Many could install a library or call a conventional API with curl.

That created a direct challenge. A well-documented command-line program already provides a composable tool interface. The agent can combine commands, redirect output, write small scripts, and inspect errors without a protocol adapter.

Skills strengthened that route. A skill is a package of instructions, scripts, and references that teaches an agent how to perform a task. It can explain an existing API without requiring its owner to operate an MCP server.

Willison summarized his skepticism in his review of 2025. For coding agents, he preferred command-line utilities and libraries over MCP. Those options gave the model more freedom while avoiding another service layer.

The criticism was never that structured tool calls had no value. The harder question concerned whether MCP provided enough additional value to justify sessions, transport management, client compatibility work, and context overhead.

Stateless MCP narrows that gap. A small remote tool can now behave more like a conventional web endpoint, while preserving a machine-readable contract for agent clients.

Willison's stateless MCP analysis links that change to two experiments. The first is mcp-explorer, intended to make MCP servers easier to inspect and understand. The second is datasette-mcp, which applies the new approach to Datasette.

Datasette is Willison's open-source system for exploring and publishing structured data. It already exposes databases through web interfaces and APIs. MCP offers another surface designed specifically for tool-using language models.

The pairing is instructive. A Datasette deployment is naturally remote, structured, and shared across users. It does not fit the local command-line model as neatly as a developer utility installed beside an agent.

An MCP server can advertise database tools using schemas that clients understand. Agents can inspect available operations before submitting queries. Server operators retain control over authentication, permissions, limits, and implementation details.

That makes the Anthropic Simon comparison more nuanced than MCP versus Skills. A skill can teach an agent how to query an API. MCP can give many clients a shared contract for discovering and invoking that API.

The two approaches can also work together. A skill can describe when to use an MCP server, explain its domain concepts, or provide a workflow spanning several tools. MCP can handle the remote execution boundary.

This division reduces pressure on MCP to become the universal answer for every agent action. Local commands can remain local. Libraries can serve flexible coding tasks. Skills can package operating knowledge.

MCP gains a clearer role where the server controls execution and multiple clients need the same discoverable interface. Enterprise data, hosted search, shared services, and authenticated business systems fit that pattern.

Protocol simplicity therefore changes the competitive question. Developers no longer need to ask whether every tool deserves an MCP wrapper. They can ask whether a remote capability benefits from standardized discovery and invocation.

That is a smaller promise than MCP's broadest early interpretations. It is also more credible. Standards often become useful after their boundaries become clearer.

Stateless requests make MCP fit ordinary cloud infrastructure

MCP 2.0 matters because it removes specialized coordination from the common deployment path.

The accepted stateless proposal identifies three problems with the old initialization model. Sessions complicated scaling, weakened failure recovery, and increased implementation work on both sides.

Consider a remote search tool running across three server instances. Under a session-oriented design, later calls might need the same instance that processed initialization. A basic round-robin load balancer cannot guarantee that outcome.

Operators can solve the problem with sticky routing. They can also store session data in a shared service. Both approaches introduce operational state, additional failure modes, and new monitoring requirements.

Sticky sessions can distribute work unevenly. Shared stores create another dependency. Server restarts can invalidate local state, while clients must detect failures and repeat initialization.

With the new request model, any healthy instance can process a compatible tool call. The gateway can route by method and tool metadata rather than by connection history.

This change also makes serverless deployment more plausible. Platforms that start and stop instances according to demand work best when requests do not depend on memory left by an earlier request.

The server still needs durable storage for genuinely durable application state. Stateless MCP does not eliminate databases, object stores, browser workers, or job queues. It removes the assumption that protocol state must accompany them.

Long-running operations now sit within an extension-based model. A server can return a task handle, while the client later checks, updates, or cancels that task through explicit operations.

The distinction is important. Hidden session state couples a workflow to a transport relationship. A task handle turns the workflow into an addressable resource that other authorized components can manage.

Multi Round-Trip Requests address another difficult case. Some tools need more information from a user or client before completing. Earlier implementations associated that exchange with an established session.

The new design permits a server-initiated request only while it is processing a client request. Correlation data travels through the request and response cycle, avoiding a permanent protocol session.

This restricts certain behaviors. A server cannot unexpectedly contact a client long after the initiating call. That limit reduces flexibility, but it gives user prompts a clearer origin and lifecycle.

Tool discovery becomes easier to route and cache as well. The specification adds method and tool metadata to HTTP headers. Gateways can inspect that metadata without parsing every request body.

Servers can attach a time-to-live value to list responses. Clients can then reuse tool information within the permitted period rather than requesting the same list for every short-lived subagent.

The sessionless proposal warns that earlier behavior could produce repeated discovery traffic proportional to subagents multiplied by servers. Stateless lists give orchestrators a better basis for avoiding that cost.

This matters as agent systems become more distributed. One user request can trigger a planner, several specialized workers, and a verifier. Repeating initialization and discovery for every branch adds latency and traffic.

The revised protocol also adopts full JSON Schema 2020-12 for tool definitions. JSON Schema is a standard vocabulary for describing structured data, including required fields, types, and validation rules.

Richer schemas can describe more precise inputs and outputs. That gives clients better information for validating calls and constructing interfaces. It also reduces reliance on loosely written tool descriptions.

Extensions provide another form of architectural separation. MCP Apps can supply server-rendered interfaces, while Tasks handle longer operations. These features can evolve without forcing every capability into the protocol core.

A formal lifecycle adds at least 12 months between feature deprecation and the earliest removal. That does not eliminate migration work, but it gives implementers a clearer planning window after this clean break.

Official TypeScript guidance shows that migration still requires deliberate work. The SDK migration guide says the new wire format requires explicit adoption rather than silently changing every existing application.

That caution is appropriate. A new specification cannot create interoperability by publication alone. Clients, servers, gateways, and SDKs must implement the same details and test them against real workloads.

Even so, the mechanism addresses a concrete weakness. It replaces MCP-specific session machinery with patterns that cloud teams already use for ordinary HTTP services.

Explicit state creates new security and reliability questions

Stateless MCP removes infrastructure friction, but it transfers more responsibility to tool design, authorization, and agent memory.

Explicit handles make state visible and portable. Those benefits also expand where sensitive identifiers can appear. A handle can enter chat histories, prompts, logs, traces, clipboard contents, or subagent messages.

A server must not treat knowledge of an identifier as sufficient authorization. It should validate both the handle and the authenticated identity on every call.

This resembles the design used by many document and project services. A resource ID identifies an object, while the current authorization context determines whether a caller can read or change it.

Unauthenticated services face a harder problem. In that setting, an unpredictable handle can operate like a bearer token. Anyone who obtains it can access the underlying state until the handle expires.

The sessionless specification recommends high-entropy identifiers and bounded lifetimes for such cases. That recommendation remains implementation guidance because MCP does not define a wire-level handle type.

This creates an enforcement gap. Clients cannot automatically recognize which returned strings represent live state. A browser_id looks like any other value unless tool names and descriptions communicate its role.

An orchestrator therefore cannot always know which identifiers must survive context compression. It may also struggle to determine which values require cleanup or should never pass to another subagent.

Models routinely carry file paths, commit hashes, URLs, and transaction identifiers. They can still copy a handle incorrectly, omit it, or lose it when a long conversation is summarized.

Session state had related weaknesses. Clients used inconsistent lifetimes, and many did not restore sessions after disconnects. Removing sessions makes those problems explicit, but it does not make state management automatic.

Cleanup presents another unresolved detail. A session ending once offered a theoretical signal for releasing resources. Actual clients often ended sessions too frequently, too rarely, or after an unrelated page reload.

Explicit workflows need their own expiration and destruction policies. A browser service might offer close_browser, while also enforcing an idle timeout. A task service might retain completed results for a defined period.

Backward compatibility adds operational complexity during adoption. Existing servers that depend on session IDs cannot simply accept the new protocol revision without changing their state model.

Clients and SDKs can negotiate an older revision when necessary. That allows gradual migration, but it also creates two behavior paths that developers must test.

Some capabilities become less direct under stateless HTTP. Unsolicited notifications and long-lived, server-driven interactions do not fit independent requests as naturally. Extensions and listening mechanisms must carry that work.

There is also no guarantee that every MCP integration becomes efficient merely because sessions disappear. Poorly designed schemas can consume context. Large tool catalogs can confuse models. Unclear descriptions can still trigger incorrect calls.

Skills and command-line tools preserve their advantages here. A coding agent can often inspect a program's help output and write a short script without loading a large remote tool catalog.

Local tools can also keep sensitive data on the user's machine. A remote MCP deployment introduces authentication, network exposure, logging, and service availability concerns that local execution avoids.

MCP does not solve prompt injection either. A tool-enabled agent can combine private information, untrusted input, and external communication regardless of whether the transport is stateful.

Server operators must constrain permissions and outputs. Agent builders must control which tools appear together. Users need clear approval boundaries for consequential actions.

These constraints challenge the strongest interpretation of the Anthropic Simon reversal. Willison's renewed interest validates the architecture change, not every MCP implementation or every proposed server.

mcp-explorer and datasette-mcp are useful early experiments because they expose practical questions. Can clients discover tools consistently? Are schemas understandable? Do authentication and state handles survive real workflows?

The strongest case for stateless MCP will come from interoperability evidence. Independent clients should connect to independent servers without custom patches, while operators should deploy them using ordinary infrastructure.

Until that evidence grows, MCP 2.0 remains a better foundation rather than a completed victory. The protocol has removed one major source of friction. Implementers still determine whether the resulting systems remain secure and understandable.

What developers should watch after MCP 2.0

The next test is adoption across SDKs, real servers, and clients, not another surge of repository counts.

The first signal is implementation coverage for the 2026-07-28 revision. Official SDKs need consistent support for discovery, per-request metadata, explicit capabilities, Tasks, and authorization behavior.

Version labels alone will not be enough. Developers should watch conformance results and cross-language tests. A Python server, TypeScript client, and managed gateway should agree on the same requests and errors.

Strong cross-SDK compatibility would reinforce the case that MCP now offers a stable remote-tool boundary. Persistent mismatches would weaken it by returning developers to client-specific adapters.

The second signal is how production servers migrate stateful workflows. Browser automation, transactions, shopping carts, and long-running research jobs provide demanding tests for explicit handles.

Successful migrations should show reliable cleanup, per-request authorization, handle handoff, and context compaction. They should also document what happens when an agent loses or repeats an identifier.

If those patterns become reusable, explicit state will look like a better abstraction than ambiguous sessions. If every server invents incompatible lifecycle rules, the protocol will have moved complexity rather than reduced it.

The third signal is the relationship between MCP and Skills. Agent platforms should demonstrate when they choose a local command, a skill-guided API call, or a remote MCP server.

Clear selection rules would strengthen the narrower thesis. MCP would serve shared remote capabilities, while Skills would package instructions and local workflows.

Continued overlap could create duplicated maintenance. Tool owners might need an API, CLI, skill package, MCP server, and client-specific integration for the same capability.

Developers should resist treating that duplication as inevitable. A skill can reference an MCP server, and an MCP server can wrap an existing API. The useful question is which interface owns the durable contract.

For data tools, Willison's experiments provide a concrete place to watch. Datasette already serves structured information through web APIs. datasette-mcp can test whether an agent-focused contract improves discovery and safe querying.

Teams building knowledge workflows face a similar choice. Local documents and notes often belong in a private, searchable engineering knowledge base. Shared business systems may fit authenticated remote tools better.

The key is to avoid granting one agent an unrestricted collection of tools merely because a common protocol makes connection easy. Standardization reduces integration work, but it does not replace permission design.

The Anthropic Simon Willison reversal is valuable because it follows a period of genuine skepticism. MCP did not regain attention through branding. Its maintainers removed a structural burden that critics could point to in deployed systems.

That is how a protocol should evolve. It should absorb evidence from failed assumptions, narrow its responsibilities, and make common operations easier to reason about.

Over the next three months, inspect the clients and servers you actually use. Check whether they support the final revision, how they represent application state, and whether their authorization follows each handle.

Then compare the result with the simplest alternative. If a local command remains clearer, keep it. If many agents need one governed remote capability, test stateless MCP and record where interoperability still fails.