MCP servers - what do they really do and why not just use an API?

What an API actually is

Think about what happens when you eat in a restaurant: you sit at a table, and a waiter comes over, takes your order, carries it through to the kitchen, and comes back with a plate. You want something from the kitchen; the waiter is how you get it without having to go in there yourself.

That is an API. Your invoices, your customers, your calendar all sit in a company's systems, and you are not allowed to wander in and rummage through them. The API is the waiter: it takes a precise request, carries it to where the data lives, and brings back exactly what was asked for. Your banking app never touches the bank's databases. It asks the waiter for your balance, and the waiter brings it.

Two things follow from that, and they explain everything else in this piece. The first is that a waiter will not improvise. Ask for the invoices from last month and you get the invoices from last month, not a summary, not an opinion about which customers are a problem. What you do with the plate once it lands is entirely your business.

The second is that somebody had to read the menu. A waiter only accepts orders for things the kitchen actually makes, phrased the way the kitchen expects, so a developer sat down in advance with a long technical document, worked out which dish answers which question, and wrote code to order that exact dish, every time, forever. That works beautifully when the order never changes. It falls apart the moment somebody wants to ask something nobody anticipated.

The problem AI assistants ran into

An AI assistant on its own is a smart tool, but it cannot see your invoices, your calendar or your files. It only becomes useful when you let it reach the tools where your work actually lives.

The obvious way to do that is to wire it up: teach the assistant how to talk to your accounting system, then your email, then your calendar. And that works of course, but involves using standardised API calls for every single thing the assistant might want to do. Five assistants and eight tools is not thirteen jobs, it is forty, and each one of them has to be built, tested and maintained by somebody who could be doing something better.

Drag the sliders and watch how quickly it gets out of hand.

Left: every assistant wired to every tool by hand, so the work multiplies. Right: each one connects once to a shared standard, so the work merely adds up.

That is the whole problem MCP was built to solve, and it is a problem about plumbing rather than intelligence.

What MCP changes

MCP is an open standard, published by Anthropic at the end of 2024 and adopted with unusual speed by almost everyone: OpenAI signed up within months, Google and Microsoft followed, and at the end of 2025 Anthropic handed the standard over to a foundation under the Linux Foundation's umbrella, so that nobody owns it. The idea is unglamorous and, for that reason, quite powerful: instead of every assistant being taught every tool by hand, each tool describes itself once, in a language every assistant already reads.

Going back to our kitchen analogy, the kitchen has not changed and neither has the waiter. What changes is that the menu, which used to be a technical manual with a list of API endpoints, is now handed to your assistant at the table and basically tells the AI assistant: here is what this kitchen can make. Here is what each dish needs from you. Here is what you are allowed to order, and here is what you are not.

Say you ask which of your biggest customers are falling behind on payments, and who at your company is meant to be chasing them. It is highly unlikely that there is a single API endpoint for that question, because it is not one question. It is three: who the biggest customers are, which invoices are overdue, and who owns each account. In the old arrangement, answering it meant someone going away, reading the manual again, and writing fresh code to stitch the three together.

The assistant reads the menu which describes what's available to it, and then requests everything that it needs. It orders the customer list, sees which names come back, uses those names to ask the waiter for their unpaid invoices, notices which are worst, and then goes back a third time to find out who is responsible for each one. Finally, it provides that info to you in whatever format you've asked for it in.

The same kitchen, the same waiter, the same rules about what you may order. What moves is who reads the menu and works out what to ask for.

The part people get wrong

It is tempting to assume the MCP server is where the cleverness lives but it isn't. A menu does not decide what you eat but it lists what is possible, in a form somebody can read, and then it waits for the order to come in. Every decision — what the question actually means, which dish answers it, what the numbers on the plate add up to — is made by the AI assistant.

What the enthusiasm leaves out

Standardising the menu is a genuinely good idea, and it has a cost that the announcements tend not to mention. Handing an assistant a menu, a waiter and the run of the kitchen is a great deal more power than handing it a chat box, and power is the thing attackers are interested in.

Security researchers went at MCP within months of its release and found what you would expect of anything young and useful. A malicious server can list a tool that looks exactly like a trusted one and quietly take its place. Instructions can be smuggled into data the assistant reads, so that the thing it fetched tells it what to do next — the equivalent of a note slipped onto the plate. And tools that are harmless apart can be dangerous in combination: one that reads your files and one that sends messages are fine on their own, and together they are a way out of the building. Most of these have fixes, and the fixes are landing. But an assistant that can act on your systems is a different risk from one that can only talk, and connecting things is exactly what MCP makes easy.

There is a plainer limitation too. The assistant has to choose the right dish from the menu, and sometimes it doesn't. It picks a near-miss tool, or asks for the wrong thing, or stops one call short of the answer. A hard-coded API call is dull precisely because it cannot make that mistake. Handing over the deciding is the whole point of MCP, and it is also the thing you are giving up.

Does this kill the API?

No, and it was never meant to. Most MCP servers are a thin layer sitting on top of the very API they seem to replace, and when the assistant asks for your invoices, it is the old API that fetches them. (Some skip the API altogether and read a database or a folder of files directly, but the principle holds: the server is a way in, not the thing itself.) The data, the rules and the permissions all still live where they always did.

The two are for different situations. If the same report has to be pulled every Monday morning, write code against the API: the route never changes, and you want the same results each time. MCP earns its place when a single question runs across several systems at once, and you don't know in advance which ones, or in what order, because it depends on what the first one turned up. That is the work MCP hands over — not the fetching, which the API always did well, but the working out of what to fetch next.

The kitchen is still where the food is, and the waiter is still the only one allowed through the door. MCP is just the menu, finally written in a language your assistant can read for itself.