.png)
Simon Willison wrote that Stateless MCP has recaptured his interest and helped inspire mcp-explorer and datasette-mcp. The trigger is the 2026-07-28 MCP 2.0 specification, which turns the protocol into a stateless request/response interface and removes a lot of the friction that made the original design feel heavier than it needed to be.
Legacy MCP required an initialize round trip, a Mcp-Session-Id, and then follow-up calls pinned to that session. That model made sense for a bidirectional protocol, but it also created coupling between client and server state, which showed up immediately in implementation complexity and operational behavior.
The new spec drops the session handshake from the core path. For simple tool calls, the protocol now looks much closer to ordinary HTTP API usage: send a request, get a response, repeat. That is a much easier mental model for both sides of the wire, and it removes one of the main reasons MCP felt awkward to build around at scale.
The practical effect is not just “fewer lines of code.” Statelessness makes proxies, load balancers, retries, and horizontal scaling simpler because the server no longer needs to preserve conversational protocol state across requests. It also makes client libraries smaller and easier to audit, which matters when MCP is embedded in agent runtimes, desktop apps, and local tooling.
Willison’s renewed interest is less about protocol aesthetics and more about deployment reality. Giving an agent a shell with internet access is powerful, but it is also hard to constrain safely. MCP tools sit in a narrower lane: explicit interfaces, defined inputs, defined outputs, and far less ambient capability than a terminal.
That narrower surface area is important for smaller models too. If the model is running locally or is otherwise not strong enough to reliably operate an unconstrained environment, a set of well-scoped MCP tools is often a better fit than “just give it curl and a shell.” The protocol becomes a control plane for capabilities, not a general-purpose execution escape hatch.
Stateless MCP also improves the case for third-party tooling around inspection and debugging. Willison used the shift as motivation to build mcp-explorer and datasette-mcp, which is a useful signal: once the protocol becomes simpler to implement, the ecosystem can spend more time on observability and less time on transport ceremony.
The biggest engineering win here is that server authors no longer need to maintain per-session protocol state for the common case. That simplifies request routing and makes the implementation feel more like a normal web service than a bespoke session protocol.
For clients, the removal of session pinning means fewer edge cases around session creation, recovery, and reuse. It also reduces the likelihood that a client implementation accidentally couples tool invocation semantics to transport lifecycle. In the old model, a server restart or client reconnect could turn into protocol bookkeeping; in the new model, the failure mode is much closer to standard request failure and retry behavior.
That simplicity is probably why the release has already started to show up in SDK updates. Microsoft’s official MCP C# SDK v2.0, for example, targets the 2026-07-28 spec with a stateless-first protocol, standardized HTTP headers, and multi-round-trip requests for interactive tools while staying backward compatible. That is the right shape for adoption: keep the common path minimal, but leave room for richer interactions when the tool really needs them.
The part I would watch closely is whether statelessness becomes the default expectation across hosts and servers, or whether a long tail of legacy-session compatibility remains necessary for too long. If the ecosystem keeps treating the new design as the primary path, adoption should accelerate quickly. If not, the protocol may retain the same conceptual baggage in practice even after the spec has moved on.
