Giving an AI agent a terminal and internet access is powerful. It is also close to impossible to fully audit.

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 know the maximum damage it can do before you have even tested it. 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 security problem BuilderWithin covered two weeks earlier: researchers found the same sandbox escape (a way for an agent to break out of its restricted work area) 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, treat “give it a terminal” as the riskiest default, not the fastest one.

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 just removed the excuse that the safer path was too hard to build.

End of article