Giving an AI agent a terminal and internet access is powerful. Its open-ended capabilities are harder to audit than a small set of narrowly scoped actions.
That is the tradeoff independent developer Simon Willison returns to in his post on the new “stateless” version of the Model Context Protocol, released July 28, 2026. MCP, short for Model Context Protocol, is a standard way to give an AI agent a specific, limited set of tools, like “search this database” or “read this file,” instead of a general-purpose command line. Willison writes:
“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.”
What changed
Anthropic introduced MCP in November 2024. It had a wave of interest through 2025, then lost ground to “Skills,” another Anthropic idea: give an agent a terminal and let it write and run its own code to reach the internet or your files directly. A terminal is more flexible than a fixed list of MCP tools, so many builders picked the terminal instead.
Willison’s shift back toward MCP is a reaction to that flexibility. MCP tools are narrow on purpose. A tool that only searches a specific database cannot also rewrite your deployment settings or delete a file, because that action was never built into the tool. A terminal can do all of it, which means the agent’s real capabilities are whatever the underlying computer allows, not what you intended to allow.
The new spec, informally called “stateless MCP,” also removes a technical excuse for skipping the protocol. The earlier version required two separate network requests: one to open a session and get an ID, then a second to actually call a tool. That extra step made MCP harder to build and to run at scale, because a server had to remember which open session belonged to which client. The new version folds this into one request, carrying the needed information in the request’s own data instead of a remembered session. Willison calls it “much cleaner from both a client and server-side implementation perspective,” and says it fits ordinary, scalable web applications better because there is no session state to track.
Who Willison is
Willison is an independent open source developer, the creator of the data-analysis tool Datasette, and a longtime writer about AI and software development. He also spends one day a week working for Prime Radiant, an applied AI research lab.
What he gets right, and where the case is incomplete
Willison is right that a fixed menu of tools is easier to reason about than an agent with a shell. If an agent can only call “search_orders” and “read_invoice,” you have a smaller set of actions to assess. You still need to inspect their permissions, behavior, and data exposure. An agent with a terminal can, in principle, do anything the machine’s permissions allow, and testing every possible path is much harder.
That safety only holds if the tools themselves are built narrowly. An MCP tool called “run_sql” that accepts any query is not meaningfully safer than a terminal. The protocol makes narrow tools easier to build and audit. It does not force anyone to actually build narrow tools. The security benefit is a design choice MCP enables, not a guarantee it provides.
The spec was also only days old at the time of Willison’s post. He built three small projects with it in a week, which shows how much simpler it is to implement, but real adoption by the client and server code libraries builders actually use will take longer to confirm.
Why it’s notable
This lands soon after a cross-agent sandbox escape: researchers found several routes around sandbox restrictions across Cursor, Codex CLI, Gemini CLI, and Antigravity, all built around giving an agent broad file and shell access. Willison’s MCP argument is the design-level answer to that same problem: the less an agent’s tools can do beyond their stated purpose, the smaller that kind of escape becomes.
What it means for builders
If you are wiring an agent into anything that touches real data, a database, a deployment pipeline, a customer record, compare broad terminal access with the narrower actions the task actually needs.
Before choosing between a terminal-based agent and MCP-style tools, ask:
- Does this agent need to touch production data, or can it work against a copy?
- Can each action it takes be described as one narrow tool, like “read this table,” instead of an open-ended one like “run this query”?
- If the agent is compromised or confused, what is the worst single action it could still take?
A narrow tool takes longer to build than opening a terminal. For anything touching money, customer data, or your live product, that extra setup is usually worth it. Willison’s point is not that MCP is finished or perfect. It is that the industry’s shortcut, just give the agent a shell, trades a real security cost for convenience, and the newest MCP spec makes the narrower-tool approach easier to implement.
End of article