Sunil Kumar.

Essay · Architecture

MCP vs API: why the third AI agent costs more than the first

MCP vs API in plain English for department heads and CXOs. One remote per device against one USB-C port, and the sum that decides what your agents cost.

Architecture

11 min read

By

On the left, one AI agent holding a different remote control for each of six business systems. On the right, the same agent and systems joined through a single USB-C style port labelled MCP.
Contents
  1. Start with what an agent actually does all day
  2. An API is a remote control, and you own a drawer full of them
  3. MCP is the USB-C port
  4. The sum that decides your budget
  5. Why it is safe to bet on now
  6. What it looks like in three departments
  7. The part the vendor deck leaves out
  8. Three questions to ask before any agent project
  9. If you are doing this in your company
  10. Sources

In the last two weeks I have had the same conversation with a head of marketing, two programme managers, a finance director and a founder. Each of them had a vendor in the room saying “our agent connects through MCP”, an IT lead saying “we already have APIs for that”, and no idea whether those two sentences were in agreement or in conflict. One of them asked me, quietly, after the meeting: do I actually need to understand this, or can I leave it to the technical people?

The honest answer is that you need to understand exactly one thing about it, and it is a sum you can do in your head. The rest really is for your technical people. This piece is the one thing, told with a drawer full of remote controls.

AI agent
Software that is given a goal rather than a script, works out the steps itself, and carries them out by using other systems: reading from them, writing to them, and asking people when it should. The standard an agent has to meet before it runs a real process is what I call Agentic in Production.

Start with what an agent actually does all day

Say you ask an agent: “Book a thirty-minute call with Priya next week.” That sounds like one task. It is at least five. Read your calendar. Read hers, or ask her. Work out the time zones. Create the invite. Send her a note saying it is done. Each of those touches a different system: a calendar, an email account, a chat tool, a contacts list.

Now think about what an agent is without those systems. It is a very well-read intern locked in a room with no phone, no laptop and no door. It can tell you a great deal about how meetings ought to be booked. It cannot book one.

So the whole question of “agents in the enterprise” is really a question about plumbing: how does the agent get to press the buttons on the systems you already own? That is where APIs and MCP both live, and it is the only reason a non-technical leader should care about either of them. An agent is only as useful as the systems it is allowed to touch, and only as safe as the ones it is not.

An API is a remote control, and you own a drawer full of them

An API is the way one piece of software asks another to do something. Your CRM has one. Your accounting system has one. Your HR tool, your ticketing tool, your calendar, your ad platform, your bank, your warehouse system all have one. Almost everything you have bought in the last fifteen years has one, and that is a good thing. It is how anything connects to anything.

The trouble is that every API is different. Different buttons, different names for the same idea, a different manual, a different way of proving you are allowed in. It is the drawer in the living room with nine remote controls in it. The television has one, the sound bar has one, the set-top box has one, the fan has one. Each does its job perfectly. None of them works on anything else.

When your team builds an agent that needs to use the CRM, an engineer has to sit down and teach that agent that particular remote: which button does what, what the error messages mean, what to do when the batteries are flat. That is real work, usually a week or two per system, and it has to be done again whenever the system changes. It also has to be done again for the next agent, because the second agent does not inherit what the first one learned. The remote is learned per agent, per system.

This is not a criticism of APIs. It is what APIs are for. The point is only that an agent is a new kind of guest in the house, and it needs to work every remote in the drawer, and you are going to have more than one guest.

MCP is the USB-C port

MCP stands for Model Context Protocol. It is an open standard, published by Anthropic in November 2024, and its own documentation describes it with the analogy I would have reached for anyway: it is the USB-C port for AI applications. One plug shape, on every device.

Here is what that means in practice. A system, say your CRM, gets an MCP server: a small piece of software that stands in front of the CRM’s existing API and describes it in a standard way. It says, in a format every agent understands: here is what I can do (look up a customer, log a call, update a deal), here is what I know (the customer records, the pipeline), and here are the standard requests I accept. Any agent that speaks MCP, and now nearly all of them do, can plug in and start working without an engineer teaching it that particular remote.

The important word in that paragraph is “existing”. MCP does not replace your APIs. Nothing is thrown away. The MCP server is the universal remote that has read the manual on your behalf. The original remote is still in the drawer, still doing the actual work, and your IT team still owns it. You wrap what you have; you do not rebuild it. If a vendor tells you that you need to “move to MCP”, ask them what they think happens to the API. The right answer is “nothing”.

The sum that decides your budget

Here is the one thing.

Without a standard, every agent needs its own connection to every system it uses. Five agents and ten systems is fifty connections to build, test, secure and maintain. With a standard, each agent is taught the plug once and each system is given the plug once. Five agents and ten systems is fifteen.

Two grids of dots. Left, without MCP: five agents in a row and ten systems in a column, joined by fifty crossing lines, one for every pair. Right, with MCP: the same five agents and ten systems each joined by a single line to one bar in the middle labelled MCP, fifteen lines in all.

Five agents and ten systems. Left: every agent learns every remote, fifty connections. Right: every agent and every system learns the one plug, fifteen. The gap gets wider with every agent you add. The figure is free to share: download it as a PNG (1600px wide, CC BY 4.0).

Multiply on one side, add on the other. That is the entire commercial argument for MCP and you do not need to know anything else about it to make a good decision.

Notice what the sum does as you grow. Three agents and six systems is eighteen against nine, which is annoying but survivable. Ten agents and twenty systems is two hundred against thirty. The first number is a team. The second is a person. And the fifty connections are not just a build cost: every one of them breaks a little every time a system updates, and somebody has to notice.

This is why the first agent in a company always looks cheap and the third always looks expensive. Nobody did anything wrong. The plumbing was multiplied and nobody was counting. When a leader asks me why the second and third agents took longer than the first, this sum is nearly always the answer.

Why it is safe to bet on now

A standard is only useful if everyone uses it, so it is fair to ask whether MCP is one company’s idea or the industry’s. In November 2024 it was Anthropic’s. In March 2025 OpenAI added it to its products, with Sam Altman posting that “people love MCP”. Google, Microsoft and Amazon followed. In December 2025 Anthropic handed the protocol to the Linux Foundation, where it now sits inside a new Agentic AI Foundation co-founded by Anthropic, Block and OpenAI, with Google, Microsoft, AWS, Cloudflare and Bloomberg as supporters. At that point it had around ten thousand active servers and ninety-seven million SDK downloads a month, and it is built into ChatGPT, Claude, Gemini, Microsoft Copilot, Cursor and Visual Studio Code.

For a leader, the significance is simple. The plug is not owned by the company selling you the agent. If you change the agent, or the model behind it, or the vendor, the plugs on your systems stay. That is the difference between an integration and an asset. An MCP server on your ERP is something you own; a connection built into one vendor’s agent is something you rent.

What it looks like in three departments

Marketing. A campaign agent reads last quarter’s numbers from the analytics tool, pulls the brand guidelines from the document store, checks the calendar for launches, and drafts the month’s content plan. It sends the plan to a person for approval and, once approved, loads it into the scheduling tool. Four systems, four plugs. When the team later adds a second agent to answer inbound enquiries, it reuses three of them on day one.

Delivery and programme management. A status agent reads the ticketing tool, the timesheets and the risk register every Friday, writes the weekly report in the house format, and flags any workstream where the burn rate and the progress have come apart. The programme manager reads a report she did not write and spends her Friday afternoon on the two flags instead of on the report.

Finance. An invoice agent reads the ERP, the bank feed and the vendor master, matches what it can, and routes everything it cannot match to a person with its reasoning attached. It does not approve anything. It is not allowed to. That restriction is not a limitation of MCP; it is a decision the finance director made, and it is the right one.

In each case the vendors of some of those systems already ship an MCP server, and the rest get wrapped once by your team. The agent on top can be swapped, upgraded or replaced without touching the plumbing.

The part the vendor deck leaves out

MCP solves the plug. It does not solve permission, judgement or cost, and those are where agents actually fail.

A plug gives access; it does not give permission. An MCP server for your ERP exposes what the ERP can do, including the things you would never want an agent doing on its own. Which agent may press which button, and what it must refuse, is a list your people write, with a name against it, before the agent is switched on. I have written about what production-grade means for an agent; the refusal list and the named approver are two of the five tests, and MCP does not provide either.

More plugs is not better. An agent handed forty tools gets worse at choosing between them, not better. The good teams give each agent the six or eight it needs for its job and no more, which is exactly how you would treat a new hire.

And every press of a button costs money and takes time. A plug that makes it easy to call a system ten thousand times a day makes it easy to run up a bill, which is a lesson we learned the expensive way. A budget per run is part of the design, not an afterthought.

None of this is an argument against MCP. It is the reason most enterprise agents never leave the demo: the plumbing gets solved and the organisational questions do not. MCP makes the plumbing cheap, which means the organisational questions arrive sooner. That is a good thing, if you are ready for them.

Three questions to ask before any agent project

You do not need to say “MCP” in the meeting. You need to ask three questions and listen for the sum.

First: which of our systems will this agent touch, and for each one, is there a plug already or are we building one? A good vendor answers system by system. A weak one says “we integrate with everything”.

Second: when we add the second agent, what do we reuse? If the answer is “the same connections”, you are adding. If the answer is a pause, you are multiplying.

Third: who in our company decides what this agent may do, and what does it do when it should not? If the room looks at the vendor, stop. That answer has to come from your side of the table.

If you are doing this in your company

Make a list of the ten systems your agents will touch most, and find out for each whether the vendor ships an MCP server. Most of the big ones now do, and the list changes monthly.

Ask your IT lead to wrap one system that does not have a server, as a two-week piece of work, and to write down what it took. That number is your unit cost for the “add” side of the sum.

Insist that every agent project names its systems, its plugs and the person who owns the refusal list before a line of code is written. The reference architecture has a checklist for this.

Treat MCP servers as assets on your side of the line. They should be in your repositories, under your security review, and they should survive a change of vendor. Write that into the contract.

Do the sum out loud in every steering meeting, with the real numbers. It is the fastest way I know to turn a room of non-technical leaders into a room that can make a good decision about agents.

If you would like help doing this in your company, this is the work Ailoitte’s pods do: the plugs, the refusal lists and the agent on top, on a fixed price. If not, the sum is yours to keep.

Sources