What everyone gets wrong about MCP and APIs

Since MCP became popular, people have started saying it replaces APIs — that you do not need them any more. It does not, and you do.

An API is how two pieces of software talk to each other. MCP is a standard way of describing what a system can do, so that an AI application can discover those capabilities and let a model choose which to use. In almost every real deployment, MCP sits on top of your APIs rather than instead of them.

The clearest way to see why is to follow one request through both.

How an application uses APIs today

Take an ecommerce application. A customer opens the orders page, the application calls an orders API, the API returns the order, the application displays it.

The customer places a new order. The application calls a payment API. Then another to update inventory. Then an email API to send the confirmation.

The developer decided all of that. Which APIs get called, when, and in what order — written in code, in advance. That is what APIs are for, and they do it well.

Now the user asks an assistant instead

Change the scenario. Instead of clicking through pages, the customer types: find my latest order and email me the tracking details.

This is a different problem. The model understands what the user wants. It does not know which APIs exist, which to call first, or what inputs they expect — and your entire API documentation should not have to be baked into it.

That gap is what MCP addresses. Two terms make the rest of it straightforward.

A tool

An action an AI application can perform. For Gmail, the tools might be search emails, create draft, send email. For GitHub: get commit history, create issue, open pull request.

A capability the model can choose to use.

An MCP server

A program that exposes capabilities to AI applications using the protocol. It can offer tools, which perform actions, and resources, which provide information — files, documents, database records.

The model never integrates with Gmail or GitHub or your internal systems directly. The AI application connects to the MCP server and discovers what is available.

The same shop, with an MCP server

Back to the ecommerce example. You already have three APIs — customer, orders, email. You do not replace them. They carry on exactly as before.

You add an MCP server exposing three tools: get customer, get latest order, send email.

Now the request arrives. The AI application connects to the server and discovers the tools, along with descriptions of what each does and what inputs it needs. Based on what the user asked, the model selects them — get customer, then get latest order, then send email.

And behind each tool sits the API you already had. Get customer calls the customer API. Get latest order calls the orders API. Send email calls the email API.

Nothing in your existing systems is replaced. MCP exposes what you already have as tools an AI application can find and use.

Which is also the answer to the question in the title. Think of an MCP server as an adapter. Your systems know how to perform business operations. The model understands the user’s goal but not how your systems work. The server bridges the two.

What actually changes

Two things, and the second gets far less attention than it deserves.

Discovery replaces documentation. Working with an API, a developer reads the docs, finds the endpoint, works out the request format, handles authentication and writes the integration. With MCP the server publishes standardised descriptions, and the AI application discovers them. Add a cancel order tool tomorrow and the next connection finds it.

The model decides the workflow. With APIs, you wrote the sequence. With MCP, the model picks the tools based on the request. That is the capability, and it is also the risk — a probabilistic system is now choosing when to invoke your systems.

	Direct API integration	MCP
Who reads the documentation	A developer	The AI application, at runtime
Who decides the workflow	Your code	The model
Integration work	Per tool, per AI platform	Once per tool
Adding a new AI client	New integration code	Point it at the existing server
Behaviour	Deterministic	Depends on the model’s judgement
Underlying access	Direct	Still via your API or database

Rows two and five are where the interesting problems live, and they are the reason the rest of this article is about limits rather than capabilities.

Where MCP is genuinely the right answer

Many tools, many clients. The saving compounds with the number of combinations. One tool and one AI product is not a protocol problem.
Exploratory work where the sequence of calls is not known in advance — analysis, investigation, support diagnosis.
Internal developer tooling. The highest-volume early use, and the lowest-risk: a small blast radius and a technical audience who notice when something is wrong.
Making your product reachable by other people’s agents. If your customers’ assistants can reach your product and a competitor’s, you become the one their tools reach for.

That last point is the strategic one, and it is the argument a vendor should actually be weighing. It is also the one most likely to be overstated by somebody selling you an implementation.

Where a plain API is still correct

Anything that must happen the same way every time. Billing, dispatch, stock movement, payments. You want determinism, and MCP gives you judgement.
High-volume machine-to-machine traffic. A model in the path adds latency and cost to something that was a straightforward call.
Anything a regulator or an auditor will ask about. “The model decided to” is a harder sentence to write in an incident report than “the code was configured to”.
Two systems that only ever talk to each other. There is no discovery problem to solve.

The security question

This is the part most comparisons skip, and it is the part a CISO will ask about first.

The protocol inverts a familiar pattern. Instead of clients requesting data from servers, MCP frequently has servers querying — and sometimes executing actions — on behalf of connected clients. Security analysis of the protocol has noted that this inversion creates attack paths that are new and not well traced, and that MCP was released with a deliberately flexible design that left room for unsafe implementations.

Two categories of risk have moved from theoretical to documented.

Instructions hidden in tool descriptions. A tool’s manifest is read by the model. Text placed there can instruct the model, and the user never sees it. This is prompt injection moved into the protocol layer, where the usual defence — watching what the user types — does not apply.

Supply chain. A malicious package impersonating a legitimate service has already been uploaded to an MCP registry and used to exfiltrate API keys from developers who installed it. Any organisation letting developers install servers from public registries has an npm-shaped problem with a new name.

The response from the standard has been real rather than rhetorical. MCP was donated to the Agentic AI Foundation under the Linux Foundation in December 2025, so governance is no longer single-vendor. An Enterprise-Managed Authorization extension reached stable during 2026, letting organisations control access to MCP servers through their existing identity provider. And national security agencies have published formal guidance — the NSA issued a Cybersecurity Information Sheet on MCP security in June 2026, and the Australian Signals Directorate published guidance on adopting agentic AI services in the same year.

When two national cyber agencies publish guidance on a protocol, that is a signal about seriousness in both directions. It is being deployed widely enough to matter, and it has enough sharp edges to warrant the paperwork.

How much adoption is real?

Less than the widely quoted figures suggest, and the discrepancy is worth knowing about because you will be shown the larger number.

A claim that around 78% of enterprise AI teams are already in production with MCP circulates widely and does not appear to be traceable to a defensible source. The best-sourced figure we could find is Stacklok’s State of MCP in Software 2026, which reported 41% of surveyed software organisations in limited or broad production — from a sample of around 100 senior technical leaders, which is small enough to be worth stating alongside the number.

Both surveys point the same way: adoption is real and growing, security is the leading blocker, and the highest-volume use so far is AI coding tools rather than customer-facing systems.

That last detail is the most useful one for planning. The place MCP has proven itself is internal and technical. Putting it in front of customers is a different risk profile, and the evidence base is thinner.

A defensible position

Get the API right first. MCP on top of an unstable or undocumented interface inherits every one of its problems and adds a component.
Start read-only. Most of the value is in retrieval. Write access is where the incidents are.
Control what gets installed. An approved list, reviewed like any other dependency. Not a free-for-all against public registries.
Use the managed authorisation extension rather than inventing your own access control.
Log what the model called and why. If you cannot reconstruct a decision afterwards, you cannot investigate one.
Keep deterministic operations deterministic. Dispatch, billing and stock movement should not depend on a model’s judgement, whatever the protocol allows.

Common questions

Should we replace our APIs with MCP?

No. The question is whether to add an MCP layer over interfaces you already have, and the answer depends on whether AI clients need to discover and use them at runtime.

Is it still an Anthropic standard?

It was introduced by Anthropic in November 2024 and donated to the Agentic AI Foundation under the Linux Foundation in December 2025. Governance is now vendor-neutral, with major AI and cloud providers participating — which is the main reason it is worth treating as infrastructure rather than as one company’s protocol.

Does building an MCP server mean opening our data to AI companies?

Not inherently. A server can run entirely inside your own network and be reachable only by clients you control. What it does mean is that a component now decides at runtime what to retrieve, so access control and logging matter more than in a fixed integration.

Our vendor says their product is MCP-ready. What should we ask?

Whether it supports the managed authorisation extension, what scopes the server exposes, whether write operations can be disabled, and what is logged when a model invokes a tool. Vague answers on any of those are the answer.

Is this going to matter in two years?

The specific protocol might not. The underlying shift — software describing its own capabilities so that an agent can use them — almost certainly will, and the preparation for it is the same either way: documented, stable, well-scoped interfaces.

Last verified: 19 September 2026. This is a fast-moving standard. Adoption figures, extensions and security guidance all change — check current sources before relying on any of it.

More on this: when a language model is the wrong tool and should your business use AI for customer support. For integration work generally, see API integrations.