Developer defends MCP as a control layer, not just plumbing

A Hacker News thread titled "MCP was always a bad idea?" drew a public rebuttal on 20 September 2026 from developer Simon Willison, who argued that critics of the Model Context Protocol are judging it against the wrong use case. MCP, the Model Context Protocol, is a standard way for AI agents to connect to external tools and services. Willison published his comment on his own site alongside the Hacker News discussion.

Willison conceded part of the criticism. He wrote that there is "almost no reason to use MCPs" if you are running what he called a full-blown terminal agent with unfettered internet access. In that setup, he said, the agent can simply call APIs directly. He named Claude Code, Codex, Meta Muse and OpenClaw as examples of that class of tool.

His argument is that this is not the only way people want to run agents. For anyone who wants to operate something "less YOLO than that", Willison listed four things they will find themselves wanting. The first is control over exactly which external services the agent can access. The second is a way to handle authentication that does not allow the agent to directly access API keys. The third is a sensible user interface that lets people connect and authenticate further services. The fourth is strong audit logging for what is going on.

MCP, he said, makes all of that much easier to provide. His conclusion was that treating the protocol as obsolete because full coding agents do not need it "misses out on all of the other things we might want to build".

The four items on Willison's list map closely onto standard security controls. Restricting which services an agent can reach is a form of least privilege. Keeping API keys out of the agent's own context means a compromised or manipulated model cannot read and exfiltrate the credential itself, only use the connection it has been granted. Audit logging is what makes an incident reviewable after the fact. Willison's framing is that a protocol layer between the agent and the outside world is where those controls can sit.

The distinction he draws is essentially between agents run by a developer on their own machine and agents run on behalf of other people. A developer with a terminal agent has already accepted the risk and holds the credentials anyway. A product that connects a user's accounts to an agent has a different problem: the operator needs to prove what the agent could touch and what it actually did.

Willison's post is a comment on a debate rather than a piece of research, and he does not present measurements or an evaluation of how well existing MCP implementations deliver the four properties he lists. He does not claim that MCP is secure by default, only that it makes the relevant controls easier to build. Neither the original Hacker News article nor its author is named in his post.

The exchange reflects a live disagreement in the agent tooling community about whether standardised connectors are worth their complexity as models get better at calling ordinary web APIs unaided.