Why Some Think Model Context Protocol Is No Longer Needed

A recent blog post titled "MCP was always a bad idea?" questions the Model Context Protocol's entire premise. The author argues that the protocol is obsolete now that powerful AI coding agents can directly call any API they need. The critique misses a critical distinction between different types of AI systems.

The core argument from the post is straightforward. If you have an agent like Claude Code or OpenAI Codex with terminal access and unrestricted internet, you do not need MCP. The agent can write its own code to interact with any service. It can handle authentication and data parsing on the fly. From this perspective, MCP adds unnecessary abstraction.

But this view applies only to a specific, unconstrained agent architecture. The reality is most AI applications need guardrails, not total freedom.

Simon Willison, a prominent voice in the AI development space, responded directly to this critique. He points out that MCP solves a different set of problems for less "YOLO" style applications. Consider an AI assistant for a business, or a tool integrated into a collaborative software platform.

For these systems, developers need precise control. They must define which external services the agent can access. They must manage authentication without exposing raw API keys to the AI model itself. They need to provide a clean user interface for connecting third-party accounts. They require robust audit logs for every action.

MCP provides a standardized framework for these exact needs. It creates a clean separation between the AI model, the host application, and the external tools. The protocol defines a client-server model where the host application acts as a gatekeeper.

Technically, MCP works by defining a standard JSON-RPC message format. A client application, often the AI host, sends a request to a server, which is the tool provider. The server exposes specific functions, like "search documents" or "create a ticket." The model never talks directly to the external API. It sends a structured request to the MCP server, which then executes the necessary API calls with proper credentials.

This architecture enables a marketplace of reusable, secure tools. A developer builds one MCP server for a popular service, and any compatible AI application can use it. It prevents a chaotic future where every AI app has custom, fragile integrations for dozens of services.

The debate highlights a split in the AI builder community. On one side are proponents of maximum agent autonomy, where the model's reasoning and coding ability is the primary tool. On the other are builders focused on controlled, auditable, and safe integration into existing software workflows.

For the second group, MCP is not obsolete. It is foundational. It solves the "plumbing" problem in a way that scales. Instead of every application reinventing authentication and API connection logic, it uses a common protocol.

The real question might not be whether MCP is a bad idea, but whether its design is optimal for the emerging ecosystem. Some developers find the protocol complex or opinionated. Others want more flexibility in message formatting or security models.

The conversation underscores a broader shift in AI development. We are moving from single-purpose chatbots to complex agents that act within larger systems. How we build the interfaces between these agents and the outside world will define their reliability and safety. MCP is one answer, but the search for better ones continues.

Will the next generation of AI tools embrace standardized protocols like MCP, or will custom, application-specific integrations dominate the landscape?

Source: MCP was always a bad idea?