MCP vs RAG: When to Use Each

"Should we use MCP or RAG?" comes up in almost every conversation I have about agent infrastructure, and it's a trick question. It's like asking whether to use HTTP or full-text search. One is a protocol, the other is a technique. They live at different layers, and most serious setups end up using both.

But the confusion is understandable, because both exist to solve the same surface problem: the model doesn't know something, and you need to get that something in front of it. The difference is in how, when, and what guarantees you get about what arrives. The last one is the part that matters most for teams.

What RAG is

Retrieval-augmented generation is a three-step technique: retrieve documents relevant to the query, usually by embedding similarity; augment the prompt with the best matches; generate the answer from that combined context.

That's it. No protocol, no standard, no wire format. RAG is a pattern you implement inside your own pipeline. Its superpower is scale over unstructured text. Your support articles, wikis, past tickets, and policy docs won't fit in any context window, and RAG's answer is: don't try. Index everything, fetch the few passages that probably matter, and let the model work from those.

The operative word is probably. Retrieval is a relevance bet. It's the right bet for "answer this question from our docs." It gets shakier the more the answer depends on which document is authoritative rather than which is similar. More on that below.

What MCP is

The Model Context Protocol is an open standard for connecting AI applications to external systems. A developer exposes an MCP server with tools, resources, and prompts; any MCP client (Claude Code, Cursor, or anything else that speaks the protocol) can discover and call them, live, in the middle of a task.

Two things make that different in kind from RAG. First, timing: RAG runs before generation, on whatever was indexed; an MCP tool call happens on demand, against the live system, so the answer is as fresh as the source. Second, direction: RAG only reads. An agent using MCP can act: file the issue, run the query, update the record.

MCP says nothing about how a tool answers. Behind an MCP tool there can be a database query, an API call, or a RAG pipeline. That last option is where the "versus" framing dissolves.

The actual difference

	RAG	MCP
What it is	A technique (retrieve, then generate)	An open protocol (client ↔ server)
Moves	Text into the prompt	Tool calls, resources, actions
Direction	Read-only	Read and act
When it runs	Before generation	On demand, mid-task
Freshness	As fresh as the last index run	As fresh as the source system
Selection logic	Similarity ranking	Whatever the tool implements
Standardized?	No, it's a pattern	Yes: one server, many clients

The last two rows are the ones people underweight. RAG's selection logic is fixed: similarity. An MCP tool's selection logic is code. It can filter by status, sort by date, join across systems, refuse to answer. And because MCP is a standard, you build the integration once and every MCP-speaking agent gets it, instead of writing a plugin per editor.

When to use each

Reach for RAG when the job is question-answering over a large, mostly static corpus. Docs search, support deflection, "what does our policy say about X." No agent taking actions, no live state, similarity is a good proxy for relevance. RAG alone is simpler and cheaper. Don't add a protocol layer you don't need.

Reach for MCP when an agent needs live state or needs to act. Current ticket status, today's schema, the decisions approved this week: anything where a stale index gives confidently wrong answers. Or anything where knowing isn't enough and the agent has to act.

Compose them when you have both shapes of problem. The common pattern: your document search is a RAG pipeline, exposed as one MCP tool among several, so the agent can search the wiki and check the live system through one interface.

Where decisions need more than RAG

Here's the concrete case that made this distinction real for me, building Lockstep's MCP server.

Lockstep is a decision memory: it captures decisions from Slack, Notion, and Jira, and a human approves each one before it binds. The obvious v1 was RAG: embed every decision, let agents retrieve by similarity. It fails in three specific ways:

Approval. A rejected proposal and an approved decision are equally retrievable. As text they look identical, and the rejected one is often written more persuasively. Retrieval has no concept of status. In Lockstep, nothing binds without one-click human approval, and the query filters on that status; similarity ranking can't express the filter at all.

Ranking by authority, not similarity. When an agent asks "what constraints apply to the billing service," the right answer is the currently binding decisions, with superseded ones excluded, even though the superseded design doc is longer, older, and more similar to the query. That's a status-and-date sort. It's trivial in a tool and unnatural in a retriever.

Enforcement. Retrieval informs the prompt and then hopes. It has no opinion about what the agent does next. Lockstep's drift gate checks pull requests against approved decisions: warning by default, blocking on conflict only if you opt in. That's an action in the workflow, not a passage in the context. There is no RAG-shaped version of it.

So Lockstep ships as an MCP server: 16 tools, with get_product_context doing the daily work of briefing agents on the approved decisions relevant to the task. Retrieval techniques are part of how some tools find candidates internally. The guarantees (approved-only, current-only, checked-at-merge) come from the tool layer. That's the honest division of labor: RAG finds text; MCP delivers guarantees.

If your problem is "the model hasn't read our docs," RAG is probably your answer. If your problem is "our agents keep acting on stale or unapproved information," you need the properties a protocol and a workflow give you. That's the broader discipline of context engineering, and, for decisions specifically, what Lockstep does.