MCP vs. API: what changes when the caller is an agent

Somewhere in every team building with AI agents, this question comes up: we already have APIs for everything, so what exactly does MCP add? It is a fair question, and most answers to it are either too abstract (“MCP is USB-C for AI”) or too promotional. This is the answer we give our own customers.

The short version: an API is a contract between two programs, written for the developer who will wire them together. MCP is a contract between a program and a model, written so the model can wire itself. MCP does not replace the API. Underneath every useful MCP server there is an API doing the actual work. What MCP replaces is the human integration step in the middle.

What an API is, and what it quietly assumes

An API exposes a system's capabilities through a defined interface: endpoints, payloads, status codes. It is the foundation of the modern internet economy, and nothing in this post argues against it. When you call a Pix payout endpoint or query an ERP, an API is doing the work.

But every API carries a set of assumptions that are so universal we stopped noticing them. It assumes a developer will read the documentation. It assumes that developer will write client code by hand: authentication, retries, pagination, error handling. It assumes the workflow is known at build time, so the sequence of calls can be hardcoded, tested, and deployed. And it assumes all of this happens once, before any real usage, by a person.

In Brazil there is a profession built entirely on interfaces being hostile to outsiders: the despachante, the fixer who knows every counter, every form, and every stamp at the government office, and gets paid because you do not. Developers are the despachantes of the API economy. Each service speaks its own dialect, and someone has to learn it before anything connects.

That model breaks the moment the caller is not a developer but a model deciding what to do at runtime. An agent asked to “charge this customer and send the invoice” cannot pause, read three documentation portals, and write a client library. It needs the counters to publish their own forms, in a format it can read on the spot.

What MCP is, and what it inverts

The Model Context Protocol is an open standard, created by Anthropic in late 2024 and now governed by the Linux Foundation, that defines how AI applications connect to external tools and data. It runs on JSON-RPC 2.0. A server exposes tools (functions the model can call), resources (data it can read), and prompts (templates it can use).

The mechanical detail that matters is discovery. When an agent connects to an MCP server, it asks for the tool list and receives, at runtime, every capability with a typed schema and a natural-language description. The model reads those descriptions the way a developer reads docs, decides which tool fits the task, and calls it. Nobody wrote glue code for that specific combination of agent and service. The contract was discovered, not integrated.

This also collapses the oldest scaling problem in integrations. Connecting N clients to M services the traditional way costs N times M bespoke integrations. With a shared protocol, each side implements it once: N plus M. It is the same economics that made USB win over a drawer full of proprietary cables, which is why the USB-C analogy stuck, even if it undersells what discovery changes.

The differences that actually matter

Two of these rows deserve expansion, because they are where teams get surprised in practice.

Errors are part of the interface now

A raw 422 with a provider-specific error body is fine when a developer will read it during integration. It is useless to an agent mid-task. When we wrap SEFAZ, the Brazilian fiscal authority, a rejection code like 539 does not get passed through. It gets translated into what it means (duplicate invoice number) and what the agent should do about it (fetch the last issued number and retry). The error message became part of the product.

Descriptions are load-bearing

In an API, the docs can be mediocre and the integration still works, because a human puzzles it out once. In MCP, the description is what the model reasons over on every call. A vague description produces an agent that picks the wrong tool, or the right tool with the wrong arguments, forever. Writing tool descriptions turns out to be closer to prompt engineering than to technical writing.

An MCP server is an opinionated API client

Here is the part most comparisons skip: MCP is not magic middleware. An MCP server is a piece of software someone wrote, and its quality is the ceiling on how well any agent behaves through it. The protocol standardizes the plug. It does not standardize the judgment inside the server.

We learned this by doing it at volume. Our catalog wraps commercial APIs across Latin America, and the work was never the protocol. The work was everything the protocol does not see:

Seven different authentication schemes, from OAuth flows to credentials embedded in URL paths, all normalized so the agent never handles a secret. Pagination quirks. Sandbox environments that behave differently from production. Provider errors rewritten into agent-legible instructions. None of that is specified by MCP. All of it determines whether the agent actually completes the task.

When a plain API is still the right choice

If the workflow is known at build time, hardcode it. A checkout that always charges, then issues the invoice, then books shipping, in that order, at thousands of requests per minute, should be a deterministic pipeline calling APIs directly. It will be faster, cheaper, and easier to audit than putting a model in the loop to rediscover the same three steps every time.

The same goes for anything latency-critical, anything with hard compliance sequencing, and anything where you would be alarmed if the execution path varied between runs. Determinism is a feature. Do not pay the reasoning tax where you do not want reasoning.

When MCP is the right choice

Reach for MCP when the caller is a model and the workflow is decided at runtime. The customer support agent that sometimes needs to refund, sometimes needs to re-ship, and sometimes needs to escalate. The back-office agent that reconciles whatever showed up in the account overnight. The coding agent that needs to pay for an external service mid-task. In all of these, you cannot enumerate the call sequences in advance, which means you cannot hardcode them, which means the integration has to be discoverable.

MCP also buys you portability. A server you write once works from Claude, from OpenAI-based agents, from open-source frameworks, from IDEs. For anyone selling capabilities to agents, that is the difference between building one integration and building twelve.

Where the comparison stops being academic

Most MCP content is about reading things: query a database, fetch a document, list calendar events. The stakes change when the tool on the other end moves money. An agent that misreads a calendar wastes a meeting slot. An agent that misfires a Pix payout moved someone's R$50,000.

At that point the interesting question is no longer “MCP or API.” It is: what sits between the agent and the rail? A raw API with the key in an environment variable gives an agent unlimited authority with zero accountability, and swapping the plug to MCP does not change that. What changes it is governance in the layer between:

Identity. Which agent, acting for which human or business, made this call. Mandates. A signed, verifiable spending authorization: this agent may spend up to this amount, on these categories, in this period. Not a prompt instruction. A cryptographic limit the infrastructure enforces even if the model is confused or compromised. Audit. Every call, allowed or denied, written to a trail a finance team can reconcile against.

// The agent sees one tool. The governance is under it.
await session.send(
  "Pay the R$1,850 supplier invoice due today via Pix"
);

// Between the tool call and the rail:
// 1. mandate check   -> within the signed monthly cap?
// 2. policy check    -> is this payee category allowed?
// 3. execution       -> Pix, with the provider quirks handled
// 4. audit           -> receipt bound to the mandate that authorized it
// A denial is a governed outcome, not an error.

This is the layer we build. The MCP servers are open source and the protocol is a commodity, in the sense that anyone can implement it. The part that makes an agent safe to hand a wallet to is not the plug. It is everything behind it.

Try both sides of this post

The fastest way to feel the difference is to use it. Our MCP catalog is MIT-licensed and self-hostable, and npx @codespar/mcp connects any MCP-capable agent to real commerce tools in one command. When the same agent needs to hold credentials it should never see, rotate OAuth tokens, respect spending mandates, and leave an audit trail, that is the managed platform, and it is exactly the layer this post argues an API alone cannot give you. Start at codespar.dev/mcp.

MCP vs. API: FAQ