MCP vs API vs RAG: Which One Your Problem Actually Needs

You searched MCP vs API and got three answers. One said MCP is the future and REST is legacy plumbing. The next said MCP is a wrapper with extra steps and worse latency. The third said what you actually needed was RAG.

All three can be right, because the question is malformed. MCP, APIs, and RAG answer three different questions. Once you know which question you have, the choice takes about ten seconds.

What each one actually answers

RAG answers a knowledge question. The model lacks a fact, so you fetch text at request time and put it in the context window before it answers. No plumbing changes. The model just gets more to read.

An API answers a calling question. One program needs another to do something, so it sends a request to an endpoint whose address and shape it already knows. That knowing-in-advance is the defining trait: the call list is fixed when the code is written.

MCP answers a discovery question. An agent pointed at tools nobody anticipated needs a way to ask what exists, read what each does, and call one correctly the first time. That's what the protocol standardizes.

The decision rule

Both ends are yours and the call list is fixed: plain API. Your code knows it needs POST /invoices and will still need it next quarter. Discovery buys nothing, and MCP charges for it anyway.

The model needs facts it lacks, and those facts are text you own: retrieve them. No protocol involved. Find the text, put it in the prompt, answer. Embeddings, SQL, or a regex is an implementation detail.

An agent must choose a capability at runtime: MCP. This is what the protocol exists for. It covers one more case: a single tool that has to work in Claude Code, Cursor, and your own client without three separate integrations.

You're doing two at once. Expected. A retrieval tool exposed over MCP is RAG and MCP together, and it probably calls an API underneath.

MCP vs API vs RAG: the comparison table

           RAG                   API                   MCP
---------  --------------------  --------------------  ----------------------
changes    what the model knows  what your program     what an agent can find
                                 can do
calls it   your retrieval code,  your code, against    the agent, at runtime,
           before the model      an endpoint it knows  from a list it
           answers                                     discovers
wins when  facts live in text    both ends are yours,  the caller is an
           you own and change    call list fixed       agent, or one tool
           often                                       serves many clients
costs      context space,        one integration per   a discovery step, an
           retrieval quality     consumer, manual      extra hop, description
                                 versioning            quality, auth

Is MCP just a fancy API? MCP server vs API, concretely

No. MCP sits a layer above APIs. The HTTP call still happens exactly as it did before; what the protocol standardizes is everything that has to be true before you can make it.

Tool calling is older than MCP and separate from it: the model emits a structured request to run a named function, your program runs it. MCP is how the model learns that function exists.

An MCP server hands a client three things a bare endpoint does not. A machine-readable list of its tools. A JSON Schema per tool, so arguments are valid by construction. And a plain-English description, the part everyone skims, which is exactly what the model routes on.

{
  "name": "search_issues",
  "description": "Full-text search over the issue tracker. Use to find existing work, not to create it.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "query": { "type": "string" },
      "limit": { "type": "integer", "default": 20 }
    },
    "required": ["query"]
  }
}

A REST endpoint carries all of that too, scattered across an OpenAPI file and a README. MCP's contribution: a client reads it at connect time, no human in the loop.

Underneath, MCP is JSON-RPC over a transport. So yes, MCP is basically JSON. The part that earns its keep is the discovery contract riding on top of it.

Will MCP replace APIs?

No, and the reason is structural rather than a bet on how adoption goes.

An MCP server is a translator. It advertises tools, receives a call, then does the work by calling something that already existed: an HTTP API, a database, a CLI, a filesystem. Remove the API and the server has nothing to call. It's a front door, not a building.

Our own MCP server does exactly that, wrapping the same REST endpoints our API buyers already call directly.

What MCP replaces is the adapter you'd otherwise write per client. Exposing one API to five AI clients used to mean five integrations. That work goes away. The endpoint stays.

Is MCP slower than an API?

Yes, always. An MCP call pays two costs a hardcoded call never does: discovering the tool list and schemas, then an extra hop through a server process that turns around and makes the request you'd have made yourself.

Fine inside an agent turn, where the model call already costs seconds and the protocol overhead disappears into the noise. Not fine in tight loops, per-request hot paths, or anything synchronous and user-facing where you already know the call.

Latency isn't the constraint that bites, though. Blocking is. A tool call happens inside the agent's turn, the loop described in the agent harness post, so a tool that runs two minutes holds that loop open, and many clients give up before it returns.

Stop holding the connection. Return a ticket, let the caller poll.

start_export(...)                     -> { "status": "running", "job_id": "j_8121" }
get_export(job_id="j_8121", wait=25)  -> { "status": "running" }
get_export(job_id="j_8121", wait=25)  -> { "status": "done", "url": "..." }

Our long-running consults work this way: a short inline wait, then a run ticket the caller polls, each poll bounded to tens of seconds.

MCP vs RAG: retrieval changes what the model knows

These two get compared constantly, and the comparison is a category error.

RAG is about what ends up in the context window. MCP is about how a capability is found and invoked. The interesting case is both at once: the agent discovers a search_docs tool, calls it, and the text lands in the context. That's RAG and MCP in one call. So yes, MCP can be used for RAG, and commonly is.

The misconception under most MCP vs RAG arguments: RAG doesn't mean vector database. It means retrieval into the context. Embeddings are one way to find the right text, often a good one, but the definition doesn't require them. Full-text search is retrieval. Grep is retrieval.

Our own Experts search their attached knowledge documents at runtime with a regular expression over the document text, no embedding model and no vector store anywhere in the path, and that is still retrieval-augmented generation.

Pick by whether your queries are semantic or lexical. For exact identifiers or error strings, exact matching beats embeddings and costs nothing to keep in sync.

RAG vs fine-tuning

Both change what a model can draw on, at different layers. RAG puts facts in the context at request time, so updating knowledge means editing a document. Fine-tuning changes the weights. That teaches behavior and format far better than facts, and it goes stale when your data moves.

If the right answer changes when your data changes, retrieve. If the answer is correct but sounds wrong or ignores your format, fine-tune.

What are the disadvantages of MCP?

There are four worth planning for. Every one will find you eventually, and none of them is a dealbreaker on its own.

Version skew. Client and server evolve on separate schedules with no compile step joining them. A tool that grows a required argument or tightens a schema breaks a pinned client at runtime, mid-turn. Treat tool signatures like a public API: additive changes only, deprecate loudly.

Tool descriptions decide routing. The model picks by reading prose. A vague description produces a wrong call that looks like a model failure and is a writing failure. Say what the tool does, when to reach for it, and when not to. Then read your transcripts to find which descriptions the model misreads.

A much larger auth surface once the server is remote. Big enough that it gets the next section to itself. The trust question underneath it, what you hand a third-party extension when you connect one, has its own threat model.

Surface bloat. Every tool competes for the model's attention. Thirty tools with overlapping names is how you get a model calling the wrong one confidently, with no exception to catch, because the call succeeded.

Remote MCP servers: where the auth bill comes due

Local and remote sound like a deployment detail. They're two security models wearing the same protocol.

A local stdio server inherits your machine's trust. It runs as you, reads your environment, opens your files. Nobody asks who is calling, because the answer is obviously you. Auth never came up.

Make that server remote and multi-tenant and those assumptions die at once.

local stdio    runs as you, reads your env, identity never comes up
remote HTTP    who is calling, what may they do, for how long,
               how did they get a credential, how do you revoke it

Remote MCP servers also face something ordinary APIs don't: the clients aren't things you ship. You can't issue a client id out of band when the caller is an agent somebody wired up this morning. That's what pushes a remote server toward OAuth 2.1: dynamic client registration, PKCE on the authorization code, the metadata endpoints clients probe before connecting, and a rate limit on the anonymous registration path. Ours needed all four, and a local stdio server needs none of them.

The day you decide the server goes remote, put auth on the plan as its own workstream. The tools are the easy half.

Calling one rather than running one? The question flips to which credentials the server expects. Ours are in the buyer provider docs.

MCP server examples: what people actually wire up

What people connect is duller than the discourse implies. Filesystem access. GitHub. Postgres. Browser automation. Web search. Issue trackers. Docs for whichever framework they're currently fighting.

Every one wraps something that already existed: a filesystem, a REST API, a database driver, a CLI.

What separates a good MCP server from a bad one is mostly one rule: a small, stable, well-described tool surface beats a large one. The temptation runs the other way, because each wrapper is ten lines. Resist it. Every tool is another line in a menu the model rereads on every turn, and routing degrades as the menu grows.

Our production server exposes eleven tools in total: eight for the buyer consult loop, three for authoring.

If you need an expert capability rather than another server to maintain, browse the Experts other agents are already calling.

What is behind the tool?

Once tools are discovered instead of hardcoded, the question shifts from "how do I call this" to "what's actually behind it."

Most MCP tools are thin by design: one function, one API call, a schema, done. There's another shape. A sealed Expert is an entire agent behind a single tool: many skills, private documents, its own tools, all executing server-side and reachable over the same MCP surface your client already speaks. The caller sends a question and gets an answer back. The system prompt, the documents, the retrieved snippets, and the reasoning never leave the server.

That sealing is what makes expertise rentable: knowledge somebody will sell access to but won't publish. It's agent skills scaled up and sealed.

Connect one over MCP or REST and point your agent at it the same way you'd wire any other tool.

MCP vs API vs RAG FAQ