MCP vs raw API: one interface you learn once, or one you rebuild every time
MCP and a raw API both let an agent reach an external service. Only one of them scales past the second service. I get asked which to use often enough that it is worth writing the answer down once, properly.
Only one of them scales past the second service.
Every API is its own dialect
An API is the raw interaction with a third-party service. It has documentation. It has endpoints. It has a defined shape for what goes in and what comes out. That works fine when it is system talking to system, two backend services calling each other, because both sides were built, or at least configured, to expect each other.
It works less well when the caller is an agent. Agents need a consistent way to discover and invoke a service, and APIs do not offer one, because they were never designed to. Every API is nonstandard by construction: whoever built it made their own choices about routes, payloads and auth, and those choices do not line up with anyone else's. So there is no general way for an agent to call into an arbitrary API. It has to be taught that API specifically, every time.
It is the drawer of old phone chargers: one per device, all doing the same basic job, and not one of them fitting anything else.
Learn the interface once
An MCP server is a wrapper around an external service, built to a well-known protocol that agents already understand. It can run locally on your machine or as a remote server. Either way, the agent's side of the conversation never changes. The interface is standard across every MCP server you connect, so an agent that knows how to talk to one knows how to talk to all of them.
That is the load-bearing distinction. With an API, what the service can do and how you reach it are tangled together, so a new service means learning a new interface. With MCP those two things are separated. What the service can do still varies. How you reach it does not.
It is the USB-C end of the cable: what sits on the other end changes, the plug never does.
The bespoke-client tax
If you do want to wire an agent up to a raw API directly, you have two options, and neither is free. Build your own client to talk to it, or shell out to curl by hand for every call. Both work. Both also mean the agent, or you on its behalf, is now maintaining bespoke integration code per service, rather than reusing anything.
Then there is documentation. An MCP server carries its own capabilities inline; the agent can see what the server offers as part of the protocol itself. An API's documentation usually lives somewhere else entirely, a website, a PDF, a wiki page, not offered as part of the calling contract. So on top of the bespoke client you have a second moving part sitting outside the code, one that can drift out of date or go missing without anything failing loudly.
It is the boiler manual filed in a drawer at the previous owner's house: the boiler still runs, right up until you need the manual.
Someone still has to write the wrapper
The way to picture an MCP server is as the thing that sits between your agent and the real service, doing the translation. It takes whatever the service actually does, endpoints, auth, its own bespoke shape, and turns it into the one interface the agent already speaks. The agent never sees the underlying mess. It only ever sees MCP. One interpreter in the room, instead of everyone learning everyone else's language.
That is a genuine trade, not a free lunch. Someone has to write the wrapper. But it gets written once, and every agent that speaks MCP gets it for free from then on. The API path re-earns the same bespoke-client cost against the same underlying service, per agent, per project, forever.
You can wire an agent straight to a raw API. Plenty of systems do, and it works. But unless you genuinely know what you are doing with hand-built clients and curl inside an agent loop, it is a world of pain: bespoke code per service, docs living somewhere else, and none of it reusable the next time you add a service. Lean MCP.
My own agents lean on this daily through Inkie's MCP server, one interface for scheduling posts, generating images, pulling the content calendar, whatever the job is that day. If you want to see a real one rather than a hypothetical, the docs are here.
A few common questions
Is MCP a replacement for the API underneath? No. MCP wraps the API, it does not replace it. The service still has its own endpoints, auth and payload shape underneath; MCP just standardises how an agent reaches it.
Do I still have to build something new for every service? Yes, someone writes the wrapper once per service. The difference is who benefits after that: every agent speaking MCP reuses it for free, instead of everyone rebuilding their own client against the same API.
Why not just call the raw API directly? You can, and plenty of systems do exactly that. You are then carrying the bespoke-client cost per service, hand-built code or curl by hand, plus docs that live outside the calling contract rather than inside it.
Why does it matter where the documentation lives? An MCP server describes its own capabilities inline, as part of the protocol itself. An API's docs usually sit on a separate website or wiki, so they can go stale quietly, without anything breaking loudly enough to notice.
If you are wiring agents up to services either way, MCP or raw, let me know what you are hitting. And in the meantime, go out and make some cool shit.
