MCP vs an API integration — who decides what happens

Two sentences sound alike and mean different things: "we connected AI to the job system" and "we exposed the job system over MCP". In the first, somebody programmed what would happen. In the second, the model got a set of options and picks for itself.

The difference sits in the integration layer, below anything the user sees. But it decides whether you can predict the outcome, what it costs, and how long the fix takes.

Who makes the decision#

An API integration is a path drawn in advance. A developer decided: an event arrives, fetch three fields, build an instruction for the model, take the answer, write it back, send a notification. The model is one step in the middle — one job, no say in what happens before or after it.

MCP inverts the order. The server exposes tools — operations that can be called — and resources, data that can be read. Every tool has a name, a description and a parameter schema. The model gets that list and decides whether to use one tool, five in sequence, or none.

Worth fixing the vocabulary, because vendors get it wrong too. The client is the AI application; the server is the system exposing its operations. "We are connecting our system to the assistant" means our system becomes the server and the assistant the client — not that one runs inside the other. And the model never gets database access: it asks for a tool to be called, and the client calls it on behalf of the signed-in user.

The same job, two ways#

A customer emails asking about the status of an order, and you want to answer automatically.

Through an API. Code receives the message, extracts the order number, queries the database, drops the result into a template, the model writes a sentence, the code sends the reply. One run, always the same. No order number in the email and the path stops.

Through MCP. The AI application gets the email and a list of tools: find a customer by address, list their orders, show order details. A missing number stops nothing — the model finds the customer by sender address, lists the orders, takes the most recent open one. Nobody programmed that run.

That is the whole benefit and the whole problem at once: the mechanism that handled the missing number may, next time, pick the wrong order.

Four things this changes#

Predictability. In an API integration the same input produces the same run; the only variable is the wording of the model's answer. Under MCP the route itself is the variable: two similar questions can send the model to different tools.

Testing. An API path is tested like ordinary code: this input, that output, green or red. An MCP path does not close that way. You test behaviour against real questions and count how often the model picked the right tool with the right parameters. The result is a distribution, not a verdict, and a newer model shifts it either way.

Cost. An API path is a known number of calls of known size. Under MCP the model sets the count, and every question also carries the descriptions of the available tools. With a dozen tools that is nothing; at several dozen it starts to matter — what breaks then, and how to shorten the list, we cover separately.

Debugging. When an API integration returns nonsense, you find the line. When an MCP agent does, the log shows which tools it called and with what parameters, but no line, because there isn't one. The answer to "why that tool" is usually: the description looked like a match. The fix is a better description and a tighter schema, not different code — a different kind of work from programming.

When an API integration is cheaper and better#

When the run is known and does not change. An invoice arrives, the data lands in the system, someone gets a notification. No decision to make, so no reason to pay a model to make one.

When the result has to be exact. Reconciliations, payments, stock corrections — anywhere an almost-right answer is worse than no answer.

When volume is high and the task is identical. A thousand identical operations a day is a thousand decisions nobody needs to make. Paying a model for them is cost without value.

When a mistake cannot be undone. An email sent to a customer, a document issued, a job closed.

The rule: if you can draw the run on paper without constantly adding "unless", the API integration is cheaper to build, maintain and run.

When MCP genuinely changes something#

When the input is unpredictable. Questions asked in people's own words have no finite list of variants. A path fixed in advance handles the ones somebody anticipated and bounces off the rest.

When there are many operations and far more combinations of them. With thirty operations the sensible sequences run into the hundreds. Nobody will write a path for each, and most would run once.

When you want to ask from a tool you do not control. An integration written for one AI application does not work in the others. An MCP server is not written for a particular client.

When a new requirement should not mean a developer ticket. Adding one tool with a description gives the model a new capability plus every combination with the existing ones. In an API integration you add one path and get one path.

Summary#

The difference is not one of technology generations but of who decides along the way. An API path is predictable, cheap and testable as long as the world looks the way whoever wrote it assumed. MCP buys flexibility with predictability, and pays on the model bill and in harder debugging.

Most companies end up with both: fixed paths where the process is settled, tools exposed to a model where the questions are open. So the question for a vendor is not "do you have MCP" but "which operations do you expose, and whose permissions are they called with".

The wider context is in the guide on connecting AI to company data.