MCP's Real Value Isn't Convenience — It's Access Control

Anthropic introduced the Model Context Protocol in November 2024 as an open standard for connecting AI models to external tools and data sources, aimed at replacing bespoke, one-off integrations with a single protocol. Nearly two years on, a Hacker News discussion around a post titled "Why MCP Was Always a Bad Idea" reopened the question of whether that standard is still earning its keep.

The case against MCP

The original argument, as summarized in the discussion, is that MCP was built for a generation of models that couldn't be trusted to improvise. Today's coding agents, it claims, can write scripts, discover a CLI's options with --help, and call APIs they've never seen before — so wrapping every service in a purpose-built MCP server adds context bloat (extra tool schemas competing for the model's attention) and token overhead for little benefit. The proposed fix is to lean on existing HTTP conventions, such as content negotiation (Accept: text/markdown), rather than a new protocol layer.

Willison's counter: it depends on how much trust you're extending

Responding on his blog, Simon Willison agreed with the premise but not the conclusion. His point: the critique only holds for a specific, high-trust case — a full-blown terminal agent (he names Claude Code and Codex as examples) running with unfettered internet access, where letting the model call APIs directly is genuinely simpler. Once you're building anything less YOLO than that, he argues you want four things MCP is actually good at providing:

• Control over exactly which external services the agent can reach — a scoping boundary, not a suggestion.
• Authentication handled without exposing API keys to the agent itself — the model never sees the credential.
• A sensible UI for end users to connect their own services — relevant for any product, not just an internal dev tool.
• Consistent logging of what the agent actually did — the audit trail security and compliance teams ask for after the fact.

Why this matters beyond the developer-tooling debate

Strip away the framing of is MCP dead and what's left is a fairly standard security architecture question: how much unmediated capability should an autonomous agent have? An agent with direct, unrestricted API access and its own credentials is fast to build and hard to constrain after the fact — every service it can theoretically reach is a service it might reach, whether through a bug, a bad prompt, or a successful prompt-injection attempt. A protocol layer that mediates access, holds the credentials, and logs the calls doesn't stop a compromised agent from trying something malicious, but it does bound the blast radius and gives you something to review afterward.

That's precisely the property that matters once an agent moves from a developer's own sandboxed terminal to a system touching customer data, internal tooling, or other people's accounts — the exact gap between Willison's two scenarios. It's also why access scoping, credential isolation, and audit logging show up as baseline controls in AI governance frameworks like ISO/IEC 42001, independent of which specific protocol implements them.

The practical takeaway

Neither side of the Hacker News thread is wrong so much as answering a different question. If you're a solo developer running a terminal agent you fully trust against your own machine, direct API calls probably are simpler than standing up MCP servers. If you're shipping an agent that other people — or other systems — will rely on, the question isn't whether MCP is convenient. It's whether you have *any* mechanism enforcing least-privilege access, keeping secrets away from the model, and recording what the agent did. MCP is one way to get that. It is not the only way, and adopting it is not a substitute for actually configuring the scopes, auth boundaries, and logging it makes possible.