Is MCP Already Obsolete? Four Real Values Being Overlooked

A recent Hacker News thread titled MCP was always a bad idea? sparked considerable discussion. Prominent developer Simon Willison fired back with a pointed response, arguing that the criticism "completely ignores the real value MCP (Model Context Protocol) delivers today." The debate cuts to a critical question: in an era of increasingly capable all-in-one coding agents, is a protocol like MCP even necessary anymore?

Where the Debate Starts: Omnipotent Agents Really Don't Need MCP Much

The logic behind the original MCP criticism isn't without merit. Willison himself partially agrees: if you're running a fully capable, unrestricted terminal agent — something like Claude Code, Codex, Meta Muse, or OpenClaw^Ad — then there is indeed "almost no reason to use MCP."

The reason is straightforward: these agents can call APIs directly. When an agent has unrestricted network access, adding a protocol layer in the middle is redundant. Letting it hit endpoints and parse responses directly is more efficient and reduces the number of moving parts.

This is the core argument behind the "MCP is obsolete" narrative — if the most cutting-edge coding agents don't rely on it, has MCP become a relic? But Willison points out that this reasoning has a significant blind spot.

What is MCP? Model Context Protocol is a standardized protocol open-sourced by Anthropic in late 2024. It provides a unified "tool-calling" interface specification for large language models. The core idea: by defining a standard interaction pattern between MCP Servers and MCP Clients, different AI applications can access external data sources, execute operations, and call APIs in a consistent way — without building a custom adapter for every tool. Think of it as the "USB port" of the AI world. Any tool that follows the spec can be plug-and-play with any MCP-compatible AI client. Claude Code, Cursor, Windsurf, and other leading AI coding tools already support MCP, and the ecosystem is expanding rapidly.

The Overlooked Value: Not Every Scenario Can Go "YOLO"

Willison's central counterargument is this: not everyone wants to run a "YOLO" (unrestricted, consequence-be-damned) agent with full permissions. In production environments, enterprise applications, or consumer-facing products, you typically need a more controlled and secure way to operate. And it's precisely in these scenarios that MCP's value becomes apparent.

He outlines four genuine needs that exist in "non-YOLO" environments:

1. Precise Control Over Access to External Services

You need to clearly define which external services the agent can actually reach — not hand it a blank check to access the entire internet. This kind of whitelist-based boundary control is foundational to secure deployment.

2. Authentication Without Exposing API Keys

Directly handing API keys to an agent is dangerous. The ideal approach is to handle authentication at the protocol layer, so the agent can make calls without ever needing to touch — or even see — the underlying credentials. MCP makes this kind of key isolation straightforward to implement.

3. A Sensible UI for Connecting and Authorizing Services

For user-facing products, you need a clean interface that lets users easily connect and authorize third-party services. This is a product-layer need that can't be solved simply by having an agent call APIs on its own.

4. Robust Audit Logs

Production systems need to know "exactly what happened." Strong audit logging captures every external call made by the agent — which is critical for compliance, debugging, and security traceability.

Willison emphasizes that MCP "makes providing all of the above capabilities much easier."

A Structural View: MCP Solves a "Governance" Problem

Taken together, these four points converge on a single theme: governance. Controlling access scope, isolating credentials, providing authorization entry points, and retaining audit records — all of these are about building a manageable, accountable framework for agent behavior.

Calling APIs directly is flexible enough for personal projects or experiments, but once you enter a production product where you're accountable to users and responsible for data, the absence of a governance layer becomes a serious liability. MCP fills exactly this role — acting as a governance and abstraction layer that clearly separates "what the agent wants to do" from "what the system allows it to do."

A note on governance in AI systems: In AI systems engineering, "governance" is a concept borrowed from enterprise IT and data management. It encompasses policy-making, permission management, compliance auditing, and risk control over system behavior. For autonomous agents, governance is especially critical — an agent that can execute code, call external APIs, and read/write data can cause far more damage than a typical software bug if it goes off the rails. The industry generally breaks governance down into several dimensions: identity (what identity is the agent acting under), authorization (what is the agent permitted to do), observability (what did the agent actually do), and reversibility (can mistakes be rolled back). MCP's standardized server-side implementation naturally provides a centralized control point across all four dimensions — which is fundamentally what distinguishes it from "just calling the API directly."

Conclusion: Sweeping Generalizations Miss the Point

Willison concludes: the idea that "MCP is obsolete because omnipotent coding agents don't need it" is a view that "misses all the other things we might want to build."

In other words, evaluating whether a technology has value by looking only at the most extreme, least-constrained use case is a mistake. Fully capable coding agents represent one category of users with one set of choices. Developers building products around security, control, and auditability represent an entirely different — and very real — constituency. For the latter group, MCP is far from a bad idea. It's actually a pretty solid piece of infrastructure.

This debate also serves as a reminder to the tech community: whether a protocol or standard is "obsolete" often depends entirely on which vantage point you're looking from.