Article · 2026-07-31 · 6 moments

Stateless MCP has recaptured my interest (and inspired mcp-explorer and datasette-mcp)

Tuesday was Stateless MCP day - the rollout of MCP 2.0, or the 2026-07-28 Model Context Protocol specification to use the more formal but less memorable name. This is the most significant change to the MCP spec since it first launched, and has also served to reignite my personal interest in the protocol. For background: MCP is the Model Context Protocol, which describes a standard way to expose new tools to LLM-powered agent frameworks. It was introduced by Anthropic back in November 2024, had ✦ AI generated

Read original ↗

HOST Simon Willison

Example

datasette-mcp adds a /-/mcp endpoint to any Datasette instance exposing three tools — list_databases(), get_database_schema(), and read-only execute_sql() — giving agents the ability to run SQL queries against a hosted Datasette instance, and it is a fourth attempt that finally felt releasable thanks to the stateless spec.

The second project, datasette-mcp, is a Datasette plugin exposing three MCP tools (including read-only execute_sql) that let agents query a hosted Datasette instance — the fourth attempt at the plugin, which finally felt good enough to release because of the new stateless specification.

transcript

Simon Willison: The second project is datasette-mcp, a Datasette plugin which adds a /-/mcp endpoint to any Datasette instance. This is probably the fourth time I've tried building this plugin, but thanks to the new stateless MCP specification I finally have a version that feels good to release. It provides just three tools: list_databases(), get_database_schema(database_name), and execute_sql(database_name, sql). They do exactly what you would expect them to do - though execute_sql() is read-only for the moment. Wire these into an agent, or a chat tool like ChatGPT or Claude, and they'll gain the ability to run SQL queries against your hosted Datasette instance. So far I'm running it on the Datasette mirror of my blog, at datasette.simonwillison.net/-/mcp. It took a bit of fiddling to figure out how to attach that to ChatGPT and Claude, but I got there in the end.

Claim◆

Even though MCP has its own prompt injection security problems, arbitrary shell and curl access in an open network environment is much harder to keep secure, and MCP makes it easier to reason about agent capabilities and failure modes — which is why I plan to lean into MCP when building sensitive LLM applications.

In the closing argument, Simon acknowledges MCP's prompt-injection problems (the Lethal Trifecta in disguise) but argues that general agents with arbitrary shell and curl access are far harder to secure, so MCP is easier to reason about — and he plans to lean into it for sensitive LLM applications.

transcript

Simon Willison: A few months after MCP was first released, I wrote Model Context Protocol has prompt injection security problems, where I noted that the pattern of having end users mix and match tools pushed responsibility for avoiding data exfiltration attacks out to the users themselves. I hadn't coined the Lethal Trifecta yet, but that was absolutely what I had in mind. Then general agents with arbitrary shell and curl access came along, and that's so much harder to keep secure! Something I've come to appreciate about MCP is that it's much easier to reason about agent capabilities and what might go wrong than with arbitrary command execution in an open network environment - the default for most of today's general and coding agent tools. I plan to lean into MCP a whole lot more when I'm building sensitive applications on top of LLMs.

supports · 1

Claim◆

Giving an agent a shell environment with internet access is fraught with risk and requires a strong driving model, whereas MCP tools are easier to audit and control and are simple enough that smaller laptop models can drive them, and the stateless spec greatly cuts client and server implementation complexity.

The reason Simon is coming back to MCP: arbitrary shell-and-internet access is risky and demands a strong model, while MCP tools are easier to audit, control, and drive from smaller laptop models — and the stateless spec slashed implementation complexity, which he proved by building three implementations in a week.

transcript

Simon Willison: I'm coming back around to MCP now. Giving an agent a shell environment with the ability to access the internet is fraught with risk, and requires a strong model that is capable of effectively driving such an environment. MCP tools are easier to audit and control, and simple enough that smaller models that run on a laptop can still drive them reasonably well. The new stateless MCP specification also greatly decreases the complexity of implementing both clients and servers for the protocol. I built three of those this week!

explains mechanism · 1gives example · 2

Example

I couldn't find a great CLI tool for interactively probing an MCP server, so I had Codex help build mcp-explorer — a stateless Python CLI that needs no installation and runs via uvx against any MCP endpoint.

Because no good CLI existed for interactively probing MCP servers, Simon had Codex help him build mcp-explorer, a stateless Python CLI that works via uvx without installation — demonstrated against Ade Oshineye's agentic-mermaid.dev demo MCP server.

transcript

Simon Willison: I couldn't find a great CLI tool for interactively probing an MCP server, so I had Codex help build my own. mcp-explorer is the result. It's a stateless Python CLI tool, so you don't even need to install it to try it out - it works with uvx like this: uvx mcp-explorer list https://agentic-mermaid.dev/mcp

Mechanism

Legacy stateful MCP required two HTTP requests — an initialize handshake to obtain a Mcp-Session-Id followed by the actual tool call — while stateless MCP collapses this to a single request, which is much cleaner to implement from both client and server sides and a better fit for scalable web applications that need no server-side session state.

Using the before-and-after example from the spec's RC announcement, Simon shows that legacy MCP needed two HTTP requests (initialize to get a session ID, then the call), while stateless MCP needs just one — cleaner to implement and better for scalable web apps, since there's no server-side session state to maintain or route.

transcript

Simon Willison: The older stateful MCP (I'm going to call it "legacy MCP") required two HTTP requests - the first to initialize a session and obtain a Mcp-Session-Id, and the second to actually call the tool: POST /mcp HTTP/1.1 Content-Type: application/json { "jsonrpc": "2.0", "id": 1, "method": "initialize", "params": { "protocolVersion": "2025-11-25", "capabilities": { }, "clientInfo": { "name": "my-app", "version": "1.0" } } } POST /mcp HTTP/1.1 Mcp-Session-Id: 1868a90c-3a3f-4f5b Content-Type: application/json { "jsonrpc": "2.0", "id": 2, "method": "tools/call", "params": { "name": "search", "arguments": { "q": "otters" } } } The new stateless way uses a single HTTP request which looks like this: POST /mcp HTTP/1.1 MCP-Protocol-Version: 2026-07-28 Mcp-Method: tools/call Mcp-Name: search Content-Type: application/json { "jsonrpc": "2.0", "id": 1, "method": "tools/call", "params": { "name": "search", "arguments": { "q": "otters" }, "_meta": { "io.modelcontextprotocol/clientInfo": { "name": "my-app", "version": "1.0" } } } } This is so much cleaner from both a client- and server-side implementation perspective. It's also a better fit for building scalable web applications, since now you don't need to maintain server-side state to keep track of those session IDs, or worry about routing the same session to the same backend machine.

gives example · 1

Context

The 2026-07-28 stateless MCP specification (MCP 2.0) is the most significant change to the Model Context Protocol since it first launched, and it has reignited my interest in a protocol that had been eclipsed by Skills and by agent harnesses with terminal and curl access.

Simon Willison frames the stateless MCP spec (MCP 2.0) as the biggest change to the protocol since launch, and recounts how MCP — introduced by Anthropic in November 2024 and surging through 2025 — was later eclipsed by Skills and terminal-and-curl agent harnesses that did most of the same work more flexibly.

transcript

Simon Willison: Tuesday was Stateless MCP day - the rollout of MCP 2.0, or the 2026-07-28 Model Context Protocol specification to use the more formal but less memorable name. This is the most significant change to the MCP spec since it first launched, and has also served to reignite my personal interest in the protocol. For background: MCP is the Model Context Protocol, which describes a standard way to expose new tools to LLM-powered agent frameworks. It was introduced by Anthropic back in November 2024, had a huge spike of interest through much of 2025, and then became somewhat eclipsed by Skills (another Anthropic invention) when it became apparent that an agent harness with access to a terminal and curl could do most of what MCP did in a more flexible way.

explains mechanism · 1gives example · 2supports · 2

Highlight slides

Why Simon came back to MCP✦ from: Giving an agent a shell environment with internet access is fraught with risk and requires a strong driving model, whereas MCP tools are easier to audit and control and are simple enough that smaller laptop models can drive them, and the stateless spec greatly cuts client and server implementation complexity.MCP's Security Tradeoff✦ from: Even though MCP has its own prompt injection security problems, arbitrary shell and curl access in an open network environment is much harder to keep secure, and MCP makes it easier to reason about agent capabilities and failure modes — which is why I plan to lean into MCP when building sensitive LLM applications.The stateless spec wins✦ from: Giving an agent a shell environment with internet access is fraught with risk and requires a strong driving model, whereas MCP tools are easier to audit and control and are simple enough that smaller laptop models can drive them, and the stateless spec greatly cuts client and server implementation complexity.Why Simon Leans Into MCP✦ from: Even though MCP has its own prompt injection security problems, arbitrary shell and curl access in an open network environment is much harder to keep secure, and MCP makes it easier to reason about agent capabilities and failure modes — which is why I plan to lean into MCP when building sensitive LLM applications.

Related episodes

Video · Syntax

Do You Read The Code? ⟡ HTTP Gets a NEW Method ⟡ Codex Gets Sol Ultra ⌁ Syntax Weekly ⌁

→

Video · a16z Podcast

Software in the Age of Agents | The a16z Show

→

Video · Syntax

I Built an LLM From Scratch

→