The framing of the question is wrong. “MCP versus API” suggests one replaces the other, and that is not what is happening. Your REST endpoints are not going anywhere, and an MCP server that talks to nothing is useless.
The real question is narrower and more useful: your API was designed for a caller that already knows what it wants, and you are now handing it to a caller that has to work that out first. Here is what actually breaks in that handoff, and what MCP does and does not fix.
What breaks when a model calls your REST API
A conventional API client is code somebody wrote after reading your docs. It knows the endpoint, the parameter names, the auth scheme, and the response shape before it ever runs. The contract is settled at development time.
A model has none of that. It has whatever you put in the prompt. So teams do the obvious thing: they describe the endpoints in the system prompt. That works for three endpoints and starts failing somewhere around a dozen, in four predictable ways.
The descriptions drift. Your API changes, the prompt does not, and the model confidently calls a parameter that was renamed two sprints ago. The prompt gets long, and every call pays for those tokens whether or not any tool is used. Composition gets unreliable, because chaining three calls correctly requires the model to hold three response shapes in its head at once. And the operational detail leaks: pagination, rate limits, retry semantics, and partial failures all become the model’s problem, described in prose, handled probabilistically.
None of these are model quality problems. You cannot prompt your way out of them, and a bigger context window makes them cheaper without making them go away. They are interface design problems, which is why the fix is an interface.
MCP replaces the middleware, not the backend
This is the part most comparisons get wrong, and it is worth being precise about.
An MCP server sits beside your service and describes what it can do in a machine readable schema. The model connects, asks what is available, reads structured metadata about each tool’s inputs and outputs, and calls what it needs. Underneath, that server almost always calls the same REST or GraphQL endpoints you already have.
So MCP is not competing with your API. It is replacing the hand written glue that used to sit between your API and the model: the endpoint descriptions in the prompt, the bespoke wrapper functions, the response reshaping. That layer existed in every integration, it was different every time, and it was the part nobody wanted to maintain.
What genuinely changes is who the client is. With an API, the client is a program somebody wrote. With MCP, the client is the model. That single shift is what makes discovery worth standardizing, and it is also what makes the security story different, which we will come back to.
The wrapping trap
Here is the failure we see most often, and it happens on the first day of adoption.
Someone points a generator at their OpenAPI spec and produces an MCP server with one tool per endpoint. It works in the demo. Then the tool list hits forty entries, and the model starts picking wrong: calling GET /users when it needed GET /users/{id}, or paginating by hand through three calls when one filtered query would have done it.
The reason is structural. Your REST API is decomposed for a caller that already knows the sequence. A model chooses from descriptions, so a long list of near identical descriptions is exactly the input that makes selection unreliable. You have moved the problem rather than solved it: instead of a fragile system prompt describing forty endpoints, you now have forty tool descriptions competing for attention, and every one of them is in context on every call.
Shape the tools like the tasks a user actually asks for, not like your routes. One place_order tool that internally does the four REST calls in the right order will beat four tools every time, because you have moved the sequencing back into code where it is deterministic and testable. The rule of thumb: if two tools are only ever called together, they are one tool.
What you inherit when the client is a model
The MCP specification is direct about this, and it is the part that gets skipped in the excitement. MCP “enables powerful capabilities through arbitrary data access and code execution paths”, and it states plainly that “MCP itself cannot enforce these security principles at the protocol level”.
Read that as: the protocol standardizes the plumbing and hands you the permission model to build yourself. Your API had authentication, scopes, and rate limits. Those still apply to the server, but nothing in MCP decides whether this particular user, in this particular conversation, should be allowed to trigger this particular write.
There is a second, subtler exposure. The spec warns that “descriptions of tool behavior such as annotations should be considered untrusted, unless obtained from a trusted server”. Tool descriptions are text your model reads and acts on. If you install third party MCP servers next to your own, you have given someone else a channel to write instructions into your model’s context, sitting right beside your data.
The practical version: keep writes behind a separate, explicitly scoped tool, carry the real user’s identity through to the data layer rather than using one service credential for everything, and log every call with its arguments. None of that is new advice. It is just newly necessary, because the caller now improvises.
When to skip it
If you have one application calling your own API, and the tools are not going to be reused anywhere else, plain function calling in your framework of choice is less code, fewer moving parts, and one less spec version to track. Build the four functions. Ship.
MCP pays off at a specific threshold, and it is a distribution threshold rather than a technical one: more than one consumer needs the same tools, or the consumers are not all yours, or you want third party tools to work in your product without writing an integration for each. That last case is the strongest. It is why “install an MCP server” is becoming a realistic answer to a feature request.
The honest summary is that MCP is a good answer to an integration distribution problem and an indifferent answer to a “make my agent smarter” problem. Teams who adopt it for the second reason tend to be disappointed, and teams who adopt it for the first tend to stop writing glue. Deciding which one you have is most of the work, and it is the conversation we usually end up having first at NukyLabs.
Facing this in your own build?
NukyLabs helps founders take AI-generated apps, agents, and automations from a working demo to something that survives real users. If any of the above hit close to home, we can scope it with you.
Get a free consultation →or message us to talk through your project.