The Protocol Debate Is Really About Permission Models
In a comment published on September 20, 2026, Simon Willison responded to a Hacker News discussion asking whether MCP had always been a bad idea. The subject was MCP, a way for agents to connect with external tools and services. His central point was not that MCP is universally valuable, but that its value depends on how much operational freedom an agent is allowed to have.
For a full terminal agent such as Claude Code, Codex, Meta Muse, or OpenClaw, with unrestricted access to the internet, letting the agent call APIs directly is often simpler. The agent can already discover and reach external services, so MCP does not fill an obvious necessity in that environment. The mistake is to turn that low value in one environment into a claim that no agent needs MCP.
The Problem Changes When Agents Cannot Be Unrestricted
A different class of systems does not want to hand an agent a terminal with unrestricted access to the entire internet. A product team may allow access only to a defined set of external services, or it may want users to connect additional services deliberately rather than letting the model choose every connection. In such a system, the primary question is no longer whether the agent can call an API. It is who gets to decide which APIs it may call.
This is where Willison sees MCP retaining practical value. MCP can represent external services through a tool boundary, so service selection does not have to remain hidden inside prompts, the runtime environment, or ad hoc scripts. It does not make authorization decisions on behalf of the product team. It gives those decisions a clearer place to live, making them easier to express as product configuration rather than leaving them to model behavior.
Four Requirements Turn Connectivity into a Control-Plane Problem
The material offers four concrete tests. The first is control over which external services an agent can access. The second is authentication that does not expose API keys directly to the agent. The third is a sensible user interface for connecting and authenticating additional services. The fourth is strong audit logging for what the system is doing. Together, these requirements show that tool access in a product agent is not just a function call. It is a collection of controls that must be made into product features.
Direct API access pushes much of that responsibility into the agent runtime. Service endpoints, authentication, secret storage, and records of activity may become scattered across the runtime and scripts, while the system depends more heavily on the agent behaving as expected. A controlled tool interface can separate user authentication from model-initiated calls, keep credentials outside the model, and route activity into system-level records. The material provides no concrete deployment architecture or security test, so the precise claim is that MCP makes these capabilities easier to provide, not that it automatically delivers complete governance.
MCP’s Value Comes from Separating Responsibilities
In terms of task outcomes, an agent using MCP to call an external service may appear equivalent to an agent accessing the API directly. The important difference is where responsibility sits. Direct access places the agent closer to service endpoints and credentials, while a controlled tool interface allows the product to establish a boundary between the agent and the service. That boundary is not valuable because it makes a call faster or gives the model more capability. It is valuable because external access can be managed as a separate system concern.
For a technical lead, this separation changes the product’s default path. A user authorizing a service can be a distinct flow. A model requesting a tool can become a system action that can be inspected. Service allowlists and audit logs can become part of the integration design rather than peripheral features added later. The material supports only the claim that MCP makes these controls easier to provide. It does not support the stronger claim that every MCP deployment is secure or that every tool call is automatically subject to sufficient approval.
Decide First Whether the Agent May Reach Everything Directly
MCP should therefore not be treated as a mandatory foundation for every agent. For a personal terminal system with open permissions and direct internet access, adopting MCP may add another protocol and adaptation layer without benefits that justify the complexity. For a multi-user agent product that must support service connections, hide credentials, or track activity, the apparent simplicity of direct API calls may merely postpone the governance burden.
The practical decision sequence should start with the permission model rather than protocol preference. First determine whether the agent may directly reach any external service. Then decide whether credentials may enter the agent-visible context, and whether user authentication and auditing must be product capabilities. If none of these constraints exist, MCP may have little value. If they do exist, evaluate MCP as part of the control plane while separately examining authorization scope, credential protection, and bypass paths. MCP supplies a boundary. It is not the complete security answer within that boundary.