model context protocol vs api vs rag
MCP is not an alternative to an API. It is usually a thin layer on top of the API you already have, aimed at a model instead of at a developer. So the real question is never which to use; it is whether the layer is worth its price, and the price is a number almost nobody publishes.
This page answers that first, with ours measured. RAG comes after, because it is the other comparison people pair with this one and it is a category error in a different direction: RAG does something MCP does not do at all.
An API is how two programs talk. MCP is how a model is told what it can do and then does it.
In practice an MCP server is very often a thin wrapper over an API you already have. The server declares each capability as a tool with a JSON Schema for its inputs, the model reads those declarations and chooses when to call one, and the server turns that call into the API request it was always going to make.
What MCP adds on top of the API, and why the wrapper is not pointless:
-
Discovery the model can read.
tools/listreturns the capabilities with their schemas. Your API's OpenAPI document is for developers; this is for a model at runtime. - One connection shape across every capability. Files, databases, browsers and issue trackers arrive through the same client, so the assistant does not need bespoke integration per service.
- A place for oversight. Approval prompts, permission settings and activity logs sit at this layer rather than in each API client.
Every comparison of these two skips the price, so here is ours. A tool is not free to declare: its name, its description and the JSON schema for its arguments are sent to the model on every turn, for the life of every session. Not once at registration. Every turn.
Enumerated from this project's own browser server on 2026-09-13 and counted with a tokenizer rather than a characters-per-token rule of thumb: 16 tools, 8,040 characters of description, 3,141 tokens on every single turn. A forty-turn session spends around 128,000 tokens restating what the tools are, before a page has been read.
Call the same API from your own code and that number is zero. Call it through provider-native function calling, where you send the schemas yourself, and you pay the same per-turn bill but keep control of exactly which ones and when. How many MCP tools is too many is that arithmetic in full.
Does a model need to choose whether to call this? If your own code decides, you want the API and nothing else. A protocol whose product is discoverability is pure overhead when nothing is discovering.
Does somebody else's assistant need to find it? This is the one MCP answers and function calling does not. An MCP server can be registered by a client you did not write, in an application you have never seen. If both ends are yours, you are paying a per-turn bill for a registry with one entry in it, and MCP alternatives works through what to use instead.
Two yeses and the wrapper is worth writing. One yes and it is usually a function call with extra steps.
These solve different halves of the same sentence. RAG gets information in front of a model. MCP lets the model act, and also lets an application attach information.
The overlap is real but partial, and the protocol itself draws the line: its three primitives are tools, resources and prompts, and it is resources that look like retrieval - read-only data behind a URI, pulled in by the application as context. MCP tools, resources and prompts has the full split.
The differences that decide it:
| RAG | MCP resources | |
|---|---|---|
| Selection | embeddings or search over a corpus | the application picks a URI |
| Freshness | as fresh as the last index build | read at request time |
| Scale | designed for large corpora | designed for specific known things |
| Can it act? | no | tools can, resources cannot |
Use RAG when the question is "which of these ten thousand documents is relevant". Use MCP resources when the answer is a specific known thing: this file, this calendar, this schema. Use both when the model needs to find something and then do something about it, which is the common real case.
- MCP vs an API: not competitors. MCP is usually a model-facing layer over an API, and it bills you per turn for the discovery it adds - 3,141 tokens on ours, every turn, forever.
- MCP vs RAG: not competitors. RAG retrieves at scale; MCP acts, and attaches known context.
- If nothing in your system is a model choosing what to do next, you probably need neither.
Does MCP replace REST APIs? No. It typically wraps one so a model can discover and call it.
Is MCP better than RAG? They answer different questions. RAG finds relevant text in a large corpus; MCP lets a model take actions and lets an app attach specific context.
Can MCP do retrieval? Resources are read-only data by URI, which covers "fetch this known thing". It is not a substitute for search over a large corpus.
Do I need an MCP server for my own API? Only if a model, rather than your code, should decide when to call it.
Is MCP just function calling with extra steps? Function calling is the model-side mechanism; MCP is the transport and discovery standard that lets any client talk to any server without bespoke wiring. When both ends are yours, that discovery is a registry with one entry in it, which is the case MCP alternatives makes with the measured cost attached.
See also: how to choose among MCP servers, and MCP tools, resources and prompts.
-
Understanding MCP servers, the protocol's own documentation, retrieved 2026-09-11: the three primitives,
tools/listand its schemas, resources as read-only URIs retrieved by the application, and the oversight mechanisms described above.
Written while maintaining an MCP server. The section that says you do not need MCP when your own code calls your own API is the one to check us on, and it is in the middle of the page rather than the footnotes.