Stop Treating MCP Like API 2.0

As LLMs improve their ability to execute code and parse CLI outputs, developers are questioning the need for the Model Context Protocol (MCP). Modern agents already possess the skills to discover OpenAPI specs, construct HTTP requests, handle headers, and extract JSON payloads on their own. Using MCP as a heavy, redundant wrapper over existing tools seems unnecessary. The problem lies not with the MCP protocol itself, but with how we design it. Treating MCP like an API 2.0 misses its true purpose.

To truly grasp MCP, we must stop seeing it as a backend data wrapper and start treating it as a UI frontend specifically designed for language models. Modern backends cater to two main consumers: human users through visual interfaces like React apps and CLI dashboards, and programmatic systems through web APIs such as REST, gRPC, and GraphQL. However, language models don't fit neatly into either category. They are neither deterministic software pipelines nor human users viewing pixels.

When we force a model to interact directly with raw REST APIs, we waste valuable context. The model must manage HTTP status codes, construct complex JSON bodies, inject authentication headers, and handle pagination. While advanced models can accomplish this, making them navigate low-level network details for each step is inefficient, burns tokens, increases latency, and increases the risk of execution errors.

An MCP server serves as an agent-facing frontend. It hides backend complexities behind intent-focused abstractions, providing the model with precisely what it needs to complete a task without forcing it to manage the underlying mechanics.

To illustrate the difference in practice, consider a simple task like searching for top community discussions. The raw REST approach (low abstraction) requires the agent to process the entire API specification, construct a detailed payload, and manage header formats, authentication tokens, URL encoding rules, and response parsing logic. This forces the model to track all these elements on every execution turn, wasting tokens and increasing the likelihood of formatting errors.

On the other hand, the MCP frontend approach (high abstraction) simplifies this entire pipeline into a clean, single-purpose tool. The MCP server abstracts the complex process into a single request, such as { name: "search_top_discussions", description: "Searches top weekly discussions on a given topic.", parameters: { query: "ai_agents" } }.

The model provides its intent (query: "ai_agents"), while the MCP server handles authentication tokens, header injection, parameter transformation, and network transport behind the scenes.

MCP proves beneficial when we need to tackle specific integration challenges where raw APIs struggle. These include custom hardware and out-of-runtime state, OAuth and client ecosystem consensus, and protecting context windows. For instance, an MCP server can bridge an LLM to external hardware, local runtime environments, or desktop interfaces without exposing raw system calls to the model.

It can also manage OAuth tokens, enforce security boundaries, and strip unnecessary data from large JSON payloads, returning only relevant information for the model's next decision step.

Building a basic MCP server that simply wraps existing REST/CRUD endpoints is a naive approach. A more purpose-built MCP, tailored to the agent's needs, offers higher abstraction and better context management. MCP isn't an "API killer" nor intended to replace standard REST endpoints. It shines in complex workflows, multi-step actions, and scenarios requiring hardware interaction. When your workflow only involves straightforward API calls, exposing those endpoints directly to the agent may be sufficient.