The reading room · Digna Legi
Stateless MCP has recaptured my interest (and inspired mcp-explorer and datasette-mcp)
/100
80–100: high value. 70–79: worth the time. Below 70: below the usual publication threshold.
Evidence-reviewed score based on available publisher text. The article is partly a project/update note, so some value depends on interest in MCP implementation details.
Scores reflect one reader’s profile, not an objective quality rating. Best is a separate personal selection.
How scoring works →This brief · about 3 min with detail
Why read this
Willison argues stateless MCP makes tool calls simpler, easier to scale, and more auditable by removing session management.
AI brief · Checked against source text
The main idea
Willison argues that the 2026-07-28 stateless Model Context Protocol specification renewed MCP’s practical value by removing session management from tool calls. A single HTTP web request can now invoke a tool, which simplifies client and server code, avoids routing sessions to the same backend machine, and makes agent capabilities easier to audit than arbitrary terminal and internet access.
Technical reading. LLM agents, web APIs/HTTP, command-line tools, JSON schemas, and SQL-backed data access.
Go a little deeper
Statelessness removes operational coupling
The key technical shift is not merely fewer lines of protocol ceremony. Legacy MCP required a session initialization request and then a later tool call tied to a session identifier. The stateless version carries the protocol version, method, tool name, arguments, and client metadata in one request, so servers no longer need to remember session IDs or route a continuing session to the same machine.
The safety claim is about bounded capability
Willison’s renewed interest comes from comparing MCP with agents that can drive a terminal and use curl to reach the internet. A shell is flexible, but it creates a large, hard-to-predict action surface and demands a strong model. MCP narrows the surface into named tools whose behavior can be inspected, controlled, and run by smaller local models more plausibly.
Building tools became a way to test the spec
The article treats implementation as investigation. mcp-explorer is a command-line interface that lists server tools, inspects their input and output JSON schemas, and calls them with arguments. That workflow exposes whether the specification is actually understandable from a client’s point of view, not just whether it looks clean in a document.
Datasette shows the useful minimum
The Datasette plugin is deliberately small: list databases, fetch a database schema, and execute read-only SQL. That limited tool set is enough for a chat agent to answer questions from a hosted Datasette instance, while keeping the interface legible. The example suggests that useful agent integration can come from exposing a few precise operations rather than a full application surface.
A case from the article
A blog mirror becomes queryable by chat
Willison connects datasette-mcp to a Datasette mirror of his blog, then asks Claude to list tables and identify recent writing about MCP. Claude runs seven SQL queries to answer. The case illustrates the article’s practical thesis: a narrow, read-only Model Context Protocol endpoint can let an agent use structured data without giving it arbitrary command execution.
How the case is made
The case is made through technical comparison, implementation experience, and three small tools built against the new specification.
Where the idea has limits
The argument supports MCP as more bounded and easier to reason about than open command execution, not as a complete solution to agent security; the author previously identified tool-mixing risks.
A question to take away · from Digna Legi
Which agent capabilities should be exposed as narrow auditable tools instead of broad shell or network access?
What the original adds
The source includes concrete request shapes for legacy and stateless MCP, command examples for mcp-explorer and llm-mcp-client, and the exact three tools exposed by the Datasette plugin.
About this brief
AI-written, then separately checked for source support, useful detail and clarity. The author’s claims and our editorial question are kept separate. The original remains the author’s work. How we select and summarise →
How was this brief?
Rate this summary, separately from the author’s article.
Optional. Saved in this browser; shared only if you allow analytics.
How was the original article?
Rate the author’s original after reading it.
Optional. Saved in this browser; shared only if you allow analytics.
Digna legi. Worth reading.