MCP vs function calling, plugins and RAG: what it actually replaces
Four things that get compared as if they were the same category. Three of them are, one is not, and knowing which is which saves a rewrite.
Ask what MCP replaces and you get four answers, three of which are in the same category and one of which is not in the category at all. It is worth ten minutes to sort them out, because picking the wrong one costs a rewrite and picking the right one for the wrong reason costs the same rewrite later.
Before comparing them it helps to be clear about what is being compared. None of the three changes what a model is capable of; all three change who is responsible for the part in the middle.
Function calling: you own everything
You describe a function to the model, the model asks for it, your code runs it. The schema is yours, the execution is yours, the authentication is yours, and nothing about it is portable to another application.
This is not a worse MCP. It is the right answer whenever the tool lives inside your own application and nobody else will ever call it. Reaching for a protocol here buys you a serialisation format and a process boundary you did not need.
Vendor plugins: they own the surface
A plugin ecosystem is a client vendor deciding what a tool looks like, how it is distributed, who reviews it, and which clients can run it. When there is one dominant client that is efficient. When there are five, it means five integrations that do the same thing, and none of them run anywhere else.
MCP: the surface is shared
MCP is what you reach for when the answer to "which client" is "more than one, and I do not control them all". One server, any client that speaks the protocol. That is the entire pitch, and it is enough — portability is the thing everyone underestimates until the second client shows up.
The cost is a process boundary, a transport, and a set of problems that come with talking to something you did not start: credentials, failure handling, versioning, and knowing what the thing can reach.
RAG is not in this category
Retrieval-augmented generation is a technique for putting relevant text into a prompt. It is not a way to call tools and it does not compete with any of the three above. The confusion is understandable — both are answers to "the model does not know about my stuff" — but they answer different halves of it.
In practice they compose: a retrieval server is a common and sensible thing for MCP to expose. The distinction that matters is reading versus doing. RAG is entirely on the reading side. The moment something has to change in the world, you are back to one of the first three.
Choosing, without hedging
| If… | Use |
|---|---|
| The tool lives in your app and only your app calls it | Function calling |
| You are shipping to one client’s users, in their store | That client’s plugin format |
| More than one client, or clients you do not control | MCP |
| The model needs to know things, not do things | Retrieval — and MCP if the retrieval has to be shared |
| You genuinely do not know yet | MCP, because it is the cheapest to be wrong about |
That last row is doing real work. An MCP server is a process with a documented interface: if it turns out you only ever needed function calling, you have lost a process boundary. If you guessed the other way, you have lost the integration.
The thing all three share, and nobody talks about
Whichever you pick, the model is reading text you did not write — descriptions, schemas, errors — and treating it as instruction. That is a property of giving a language model tools, not a property of MCP. The protocol just makes it easier to acquire tools from people you have never met, which turns a small problem into a supply-chain one.