MCP vs RAG: how retrieval fits behind the protocol
Retrieval-augmented generation and the Model Context Protocol are not two answers to the same question. RAG is an architectural pattern: you index a corpus, retrieve the passages relevant to a query, and place them in the model’s context before it generates. MCP is a wire protocol: a standard way for an AI application to discover and call tools, and to read resources, on external servers at run time. A pattern and a protocol occupy different layers of a system, and the cleanest proof that they are not rivals is that a retrieval pipeline can sit behind an MCP server, with the protocol carrying the query in and the passages back out.
The search query “rag vs mcp” is usually standing in for a real decision, though: who fetches context for your model, when does it arrive, and who controls what counts as relevant. That decision is worth making deliberately, and it has a security consequence that almost every comparison skips. Both are below.
MCP vs RAG at a glance
| RAG | MCP | |
|---|---|---|
| What it is | An architectural pattern for retrieval | An open protocol (a wire format and message set) |
| Standardised by | Nothing; every framework builds its own pipeline | The MCP specification, current revision 2026-07-28 |
| What moves | Text chunks from an index into the prompt | JSON-RPC messages: tools/call, resources/read |
| Who decides relevance | Your application’s retriever | The model (tools) or the host application (resources) |
| When context arrives | At query time, before generation starts | At run time, whenever the model or host asks |
| Typical job | Ground answers in a body of documents | Let a model read and act on external systems |
| Relationship | Can run behind an MCP server | Can front a RAG pipeline |
The last row is the one that matters. These compose; they do not compete.
What does RAG actually do?
A RAG system splits documents into chunks, embeds each chunk as a vector, and stores the vectors in an index. At query time it embeds the user’s question, pulls the top-k nearest chunks (often reranking them), and prepends the winners to the prompt. The model then generates with that text in view. The pattern was named in Lewis et al., 2020, which paired a retriever with a generator so a model could draw on a corpus it was never trained on, and the industry shorthand has since drifted to mean almost any pre-fetch of context.
Two properties define the pattern. First, your application code decides relevance. The model never sees the corpus, only the selection your retriever made, which makes retrieval quality something you can measure and regression-test offline. Second, the characteristic failure is quiet: a bad top-k produces a confident answer grounded in the wrong text, and nothing in the transcript looks unusual.
RAG is not a standard. There is no RAG specification, no conformance test, and no interoperability between one team’s pipeline and another’s. That absence is exactly the gap a protocol fills.
What does MCP actually standardise?
MCP defines how an AI application (the host) talks to servers that extend a model’s reach. Two of its primitives are the ones this comparison turns on, and the spec assigns them different owners:
- Tools are model-controlled. The spec’s words: “the language model can discover and invoke tools automatically based on its contextual understanding and the user’s prompts”. A tool has a name, a JSON Schema for its inputs, and is invoked with
tools/call. - Resources are application-driven. Each is identified by a URI, read with
resources/read, and it is the host application (or the user through its UI) that decides which resources enter the model’s context.
That split is a division of control, written into the protocol: tools put the fetch decision with the model, resources put it with the application. Notice that this is the same axis RAG lives on. A classic RAG pipeline is application-driven context, done ad hoc; MCP gives both ends of the axis a standard shape. (We cover the protocol itself in more depth in our MCP overview.)
Why is “MCP server vs RAG” a category error?
A retrieval system needs a front door, and MCP is a standard front door. Wrap your vector search in a tool called search_docs that takes a query string and returns matching passages, and you have a RAG pipeline behind an MCP server. The model decides when to search; your retriever still decides what comes back. Alternatively, expose the documents as URI-addressed resources and let the host preselect them, and you have build-your-own context loading with a standard read path. The spec even lets a tool result carry embedded resources or resource links, so a search tool can return pointers the client fetches on its own terms.
So “MCP server vs RAG” compares a delivery mechanism with the thing being delivered. The honest questions are narrower:
- What MCP adds to retrieval: any MCP client can use your corpus without bespoke integration code, the same server works across hosts, and the model can search iteratively instead of receiving one fixed pre-fetch.
- What MCP does not add: better retrieval. A weak top-k served over JSON-RPC is still a weak top-k. Chunking, embeddings and reranking remain your problem.
The decision you are actually trying to make
Strip the acronyms and the choice is two questions.
When should context arrive? Pre-fetching at query time (the classic RAG shape) is deterministic and cheap to evaluate: same question, same chunks, one retrieval per request. Fetching at run time through a tool lets the model reformulate queries, follow leads across multiple searches, and pull only what the conversation turns out to need, at the cost of latency per call and a transcript that is different every run.
Who should control relevance? If your retriever picks the context, you can eval it, tune it, and audit why an answer said what it said. If the model picks the context through tool calls, you inherit its judgement about what to search for, which is adaptive on hard questions and erratic on ambiguous ones.
Rules of thumb that follow:
- A fixed corpus, one application, question answering: a plain RAG pipeline inside your app. Putting MCP in the middle adds a network hop and a protocol dependency for no new capability.
- One corpus, many clients or agents: retrieval behind an MCP server, so the integration is written once.
- Agents doing open-ended research: run-time retrieval tools, because no single pre-fetch anticipates step four of an investigation.
- Anything that acts (sending, writing, updating): MCP territory outright. RAG only ever adds text to a prompt; it cannot send an email.
What changes for security when retrieval moves behind an MCP server?
Here is the part the “which is better” posts miss. The moment retrieval sits behind an MCP server feeding an agent, every retrieved passage becomes untrusted input that a model may act on. OWASP’s LLM01: Prompt Injection names the mechanism: indirect prompt injection happens when a model accepts input from external sources and content within that input “alters the behavior of the model in unintended or unexpected ways”. A document in your corpus that contains instructions is, from the model’s point of view, instructions. In a chat app that grounds answers, the damage is a wrong or manipulated answer. In an agent that also holds write-capable tools, a poisoned document can steer real actions, including exfiltrating whatever else is in context through any tool that can send data outward.
The spec anticipates this. Its security guidance says clients should validate tool results before passing them to the model, keep a human in the loop with the power to deny tool invocations, and treat tool annotations as untrusted unless the server itself is trusted. Resource-serving servers must validate URIs and sanitise file paths. Those are obligations on implementers, not properties you can assume; whether a given server meets them is precisely what is worth checking before you connect an agent to it.
Authentication is the other habit worth keeping. Scanning the official MCP registry, we find that as of 29 July 2026 only 1,201 of 9,797 remote components require authentication. An unauthenticated remote retrieval server means you do not control who queries your corpus, and it often signals that nobody has thought hard about who can write to it either, and corpus write access is exactly where indirect injection starts. Our MCP threat model walks through these failure modes in detail, and how we score explains what we probe: we connect to each server, read its tool schemas, and check transport, TLS and auth. Scores are independent estimates, not guarantees, and signals we cannot verify are marked inconclusive rather than guessed.
When should you use RAG, MCP, or both?
Use a plain RAG pipeline when one application needs grounded answers over a corpus you control and nothing needs to act. Use MCP when a model needs to reach systems at run time, whether to act or to fetch, and especially when more than one client needs the same reach. Use both, retrieval behind an MCP server, when you want one corpus available to every agent and client you run. And treat that last configuration as the security-relevant one: the server’s tool and resource surface, its authentication, and the provenance of its corpus all become part of your agent’s attack surface.
If the server you are weighing up already exists, look it up in the registry before you connect it: the score breaks down transport, auth and tool-surface signals per component, which answers most of the questions above for you.