MCP, Model Context Protocol, is often presented as the obvious way to connect AI agents to your systems. But if you already have a REST API, it is an unnecessary detour.
AI agents can already talk to REST APIs
An AI agent with terminal access, such as Claude Code, can call a REST API directly. By using tools like curl or various HTTP libraries, the agent can send requests just as it would any other terminal command. This means a well-defined REST API with an OpenAPI specification offers the same functionality as an MCP call.
AI agents typically have a solid understanding of how to construct a correct curl command, since curl is a well-established tool available on all operating systems. If an agent makes a mistake, it can run curl --help to get guidance on the command structure.
REST APIs also have the advantage of having existed for several decades, and have therefore accumulated a rich ecosystem of tools and utilities. Additional benefits include HTTP caching, load balancing, authentication, scaling, and more. None of this is impossible to achieve with MCP, but why spend time building new infrastructure when it already exists for your API?
A common misconception
A common misconception is that an MCP server replaces backend logic. It does not. You still have to write all the logic that handles the requests. MCP simply adds an extra layer on top of what you already have, which means more dependencies to maintain, more code to debug, and a larger attack surface, without getting anything back that the REST API does not already provide. Maintaining both a REST API and an MCP server means maintaining two separate server architectures and processes.
MCP servers offer tool discovery, which makes it easy for an MCP client to find relevant tools. An example of a tool in a financial MCP server might be “fetch today’s invoices”. This tool returns the invoices to the client, which can then perform its AI analysis. But if you already have a well-defined REST API available, your HTTP endpoints are your tools, and your API documentation acts as tool discovery.
API documentation can be distributed as an AI skill (a prompt describing the API), or you can expose an HTTP endpoint that returns concise documentation, making it easy for an AI agent to dynamically understand how to use the API.
Tool exposure is an argument often raised in MCP’s favor, but in practice MCP has had notable problems with tool discovery and name collisions when many tools are exposed simultaneously. REST has no such built-in limitations.
The sandbox
An AI agent with access to the operating system should always run in a sandbox, regardless of whether it communicates via MCP or directly against a REST API with curl. This is to avoid serious consequences where an agent accidentally — or as a result of a malicious instruction — deletes important files or performs unwanted actions. A sandbox is typically a virtual environment that only has access to specific directories on the host system. If the agent makes a serious mistake inside the sandbox, a new one can easily be created.
There are additional security measures to consider, such as strict network filtering and permission restrictions, but that is a topic for a separate article.
The attack surface grows
Installing popular MCP servers increases the total attack surface through third-party dependencies and exposed functionality.
Several vulnerability classes have emerged in MCP servers, such as tool poisoning, where an MCP server hides malicious instructions in a tool’s metadata.
These attack methods can technically be carried out via a REST API as well, depending on how it is structured. The difference with a REST API is that a user can save the API documentation locally, inspect it, and then point the AI agent to that documentation. If the REST API changes, the AI agent will most likely fail its requests, at which point the change can be inspected. An MCP server can silently alter tool definitions or metadata without the user noticing, and include malicious instructions to the AI agent. It is this dynamic and invisible change that, among other things, increases the total attack surface.
An MCP server can use sampling to request that the client send your agent’s context window to an external LLM. This means sensitive information — such as internal instructions, prior conversations, or business data — can leave your environment without you noticing.
That said, it is possible to reduce the risk that a malicious MCP server poses. But if you already offer a REST API, why introduce new risks that need to be managed?
Token cost
Every extra exchange of information costs money. MCP tool manifests, metadata, session negotiation, and especially sampling consume tokens on every interaction. By making direct calls with curl, for example, you avoid the extra overhead and can filter directly for the information you need. In an organization where AI agents run around the clock, these small additional costs add up to significant sums.
When an MCP server exposes a large number of tools, the client receives the full list at startup, which burdens the context window and further increases token cost. The agent may also struggle to pick the right tool when many of them look similar.
MCP users have long complained about the cost and difficulty of MCP clients finding the right tool when a server exposes a large number of tools. This has resulted in several proposals and changes to the MCP protocol, for example:
These will optimize token usage in the MCP protocol and reduce costs for users.
When is MCP actually justified?
MCP is justified when your users are non-technical, already use a GUI-based agent client, and have no other way to connect to your service. If your users are technical, or are agents running in a terminal, a REST API is sufficient.
Three things to keep in mind when choosing an MCP server and client:
Use a client that detects when tool definitions change and alerts you. If your client accepts changes silently, you should not trust it.
Always require human-in-the-loop for sampling. Sampling means the MCP server can trigger LLM calls at your expense, without you necessarily noticing.
Be aware of token costs. If the MCP server does not optimize tool discovery, you are paying for metadata you do not need, on every single call.