TL;DR
MCP is not a replacement for your APIs. It is a standard way to describe them so that an AI assistant can find and call them without anyone wiring that call in advance. Plain APIs still win wherever the caller is another system and the sequence is known. MCP wins wherever the caller is a person's assistant or an agent and the sequence is decided at runtime. Neither one answers who is allowed to call what, with which arguments, and what it cost. That is a layer above both, and it is the one IT has to sign off on.
Two different questions
"MCP vs API" is a comparison people search for, so it is worth being precise about what is actually being compared.
An API is a contract a system publishes: these endpoints, these parameters, this authentication, this response shape. It says nothing about who will call it or in what order. That is decided by whoever writes the integration.
The Model Context Protocol is a contract between an AI client and a server that exposes tools, resources and prompts. The client asks the server what it offers, receives a typed description of each tool, and calls them by name. Nothing about the sequence is fixed in advance. The model decides, per conversation, which tool to call next.
So the honest framing is not "which one should we use". Almost every MCP server in production is a thin layer over an existing API. The question is: for a given piece of work, does the caller know the steps in advance, or not?
Where plain APIs still win
If the steps are known, an API integration is the right tool and MCP adds nothing but overhead.
- System-to-system, fixed sequence. Billing calls the CRM on invoice creation. Inventory updates the shop on stock change. There is no model in the loop and no reason to introduce one.
- High volume, low latency. A tool call routed through a model costs tokens and hundreds of milliseconds. A direct API call costs neither.
- Contracts you own and test. A scripted integration can be unit-tested, versioned and rolled back. A model choosing tools at runtime cannot be tested the same way; it can only be constrained.
- Batch and scheduled work. Nightly reconciliation does not need to discover anything.
None of this changes because MCP exists. Keep those integrations.
Where MCP wins
MCP earns its place the moment the caller is an assistant or an agent and the path through your systems cannot be scripted in advance.
Take one support request. Answering it might mean reading the customer's history in the CRM, checking the order in fulfilment, looking up the product in inventory, reading a knowledge-base article and opening a ticket. Which of those, and in what order, depends on the request. With point-to-point integrations, someone has to have anticipated that combination. With MCP, the assistant sees five described tools and works it out.
Three things the protocol gives you that a pile of APIs does not:
- Discovery at runtime. The client asks what is available. Add a tool to a server and every client that connects to it can use it, with no change on the client side.
- One description format. Every tool carries a name, a plain-language description and a typed input schema. That is what lets a model choose correctly, and it is the same format whether the system behind it is SAP, Jira or a script someone wrote last week.
- One client contract for every assistant. ChatGPT, Claude, Copilot, Gemini and the coding agents all speak MCP. Expose a system once and it is reachable from all of them. This is the part that matters most at enterprise scale, and we wrote it up separately in One Connector, Every AI Client.
The arithmetic that actually changes
The usual pitch for MCP is the integration count. With N systems, full point-to-point connectivity needs N × (N − 1) ÷ 2 links; twenty systems means 190. That number is real but misleading, because nobody builds full mesh. Most systems only ever talk to two or three others.
The count that actually grows in an AI programme is different: assistants × systems. The moment you have two assistants (say Copilot for the business and Claude for engineering) and ten systems, per-client integration means twenty pieces of work, twenty places to configure credentials and twenty audit surfaces. Add a third assistant and it is thirty. That is the curve MCP flattens: ten servers, each written once, reachable from every client.
Maintenance follows the same shape. When a system changes its API, one MCP server changes. The assistants notice nothing.
What neither one does
Here is where most "MCP vs API" articles overreach, including the earlier version of this one. MCP does not come with governance. The protocol defines how a tool is described and called, and how a client authenticates to a server. It does not decide:
- Which person is allowed to use this tool at all. An authorised client sees everything the server exposes to it.
- What they may do with it. "Can read CRM records" and "can read any CRM record, including the ones under legal hold" are the same tool.
- Whether a human should look first. Issuing a refund and reading a refund policy are both just tool calls.
- What it cost, and which team should pay for it.
- Proof that any of the above was enforced, in a form an auditor will accept.
An API gateway does not answer these either. It sees a token and an endpoint, not a person, an intent and an argument. That gap is why AI pilots so often clear the technical review and stall at the security one: the protocol works, and nobody can say who is allowed to use it. We covered the gateway side of this in Why API Gateways Don't Work for Agents.
The layer above
This is the layer Palma provides, and it sits above both APIs and MCP rather than replacing either.
Each person gets one governed connector, assigned through the groups they already hold in your identity provider. That connector carries every tool and every Skill they are entitled to into whichever assistant they use. Someone in Finance sees Finance tools; someone who joins Sales has Sales tools on day one and loses them the day they leave. Policies are evaluated on the actual arguments of a call, so "read CRM" and "read this customer's CRM record" are different decisions. Calls that need a human get routed for approval before they run. Every call is logged with who, what, when and why, and cost is attributed to the team that incurred it.
Your APIs do not change. Your MCP servers do not change. What changes is that IT can say yes, because the answer to "who is allowed to do what, and can you prove it" is finally somewhere.
A short decision guide
| Situation | Use | Why |
|---|---|---|
| Two systems, fixed sequence, no model involved | Direct API | Testable, cheap, no discovery needed |
| One assistant, one system, one team | Either | MCP is cleaner; the difference is small at this size |
| An assistant that must pick its own path through several systems | MCP | Runtime discovery is the whole point |
| More than one assistant across the company | MCP | One server per system instead of one integration per client |
| Any of the above, and you need to pass a security review | MCP plus a governance layer | Neither the API nor the protocol knows who is calling |
What to do with the APIs you already have
Nothing dramatic. Existing integrations stay. When an assistant needs to reach a system, wrap that system's API in an MCP server; for most SaaS products that server already exists. Start with one team and the two or three systems they actually use, put the governance layer in front of it so IT can approve it, and let the second and third teams inherit the same servers instead of building their own.
If you want to see what that looks like for one of your teams, book thirty minutes and bring the list of systems.
