Explain the difference between MCP and RAG. At what level of abstraction does each operate, and give an example of when you would choose one over the other?
RAG is a retrieval pattern that injects documents into the prompt before generation; MCP is a connection protocol exposing tools, resources, and prompts at runtime. Different layers, not rivals.
Picture a chef cooking dinner. RAG is the prep cook who, before service, reads the order and lays the right ingredients on the counter so the chef can grab them. MCP is the standardized kitchen wiring: the gas line, the power sockets, the fridge handle, that let the chef reach for any appliance mid-cook without rebuilding the kitchen for each brand. RAG happens up front, fetching the right notes into the prompt. MCP happens live, letting the model phone out to tools while it works. A retrieval step can even be one of the appliances MCP plugs in. So they are not competing recipes. One is about staging the right context early. The other is about how the kitchen connects to everything it can touch during the cook.
Concept explanation~2 min read
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Concept explanation~2 min read
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
The MCP versus RAG question is a category error waiting to happen. Both showed up in the same agentic-AI wave, both touch external data, and both end up putting useful information in front of a model. So candidates line them up as rivals and try to pick a winner. That is the trap, and an interviewer asking this question is usually probing whether you can name the trap before stepping in it.
They are not the same kind of thing. RAG is a pattern, a recipe for grounding a model in retrieved text. MCP is a protocol, a standardized way for an application to connect to external capability servers. One describes a data-flow technique; the other describes a wire contract. Asking which is better is like asking whether a recipe beats a power outlet. The recipe tells you what to cook; the outlet tells you how appliances connect to power. They answer different questions, and a good answer to a duplicate-charge support ticket might use both.
This deep dive separates the two cleanly. It pins down what each one is, when each one acts in the request lifecycle, how one can literally contain the other, and how to reason about the choice out loud in an interview without falling into the false-rivalry framing.
What RAG actually is
RAG, Retrieval-Augmented Generation, is a pattern for grounding a model in external knowledge. The shape is fixed and simple. Take the user query, embed it into a dense vector, and search a vector store or hybrid index for the nearest neighbors. Pull the top matching chunks. Concatenate those chunks into the prompt as context, usually under a heading like 'Relevant documents.' Then let the model generate an answer that leans on the injected text rather than on parametric memory alone.
The defining property is timing. Retrieval happens before generation, as a discrete pre-processing step. The pipeline decides to retrieve; the model does not. There is exactly one retrieval round per turn in the classic design, and it is read-only. No state changes, no external side effects, just facts flowing into the context window. Because the retrieval is fixed, you can swap the embedder, tune the chunk size, or add a reranker without touching the model at all.
That predictability is why RAG dominates grounded question answering. You know the cost, you know the shape, and you can evaluate retrieval quality independently of generation using metrics like recall at k or mean reciprocal rank. The cost is rigidity. If the first retrieval misses, the model is stuck with bad context, because nothing in the classic loop lets it reformulate the query and search again. The model cannot say 'these chunks are irrelevant, let me try different search terms.' It answers with whatever the single pre-fetch handed it, which is why retrieval quality is so often the bottleneck in production RAG.
Situations where this technique stops working.
2–4 min · Everything important, quickly.
| Concern | RAG | MCP |
|---|---|---|
| What it is | Retrieval pattern | Connection protocol |
| When it acts | Before generation, one shot | During generation, runtime |
| Who triggers it | The pipeline, pre-prompt | The model, via tool calls |
| Scope | Fetch documents into context | Tools, resources, and prompts |
| Side effects | None, read-only lookup | Allowed, tools can mutate state |
| Containment | Can be wrapped as one MCP tool | Can host many tools, including RAG |
Real products, models, and research that use this idea.
- Claude Code discovers MCP servers at session start, then the model invokes their tools mid-task over JSON-RPC.
- A vector-search MCP server wrapping a Pinecone or pgvector retriever turns classic RAG into an on-demand tool call.
What an interviewer would ask next. Try answering before peeking at the approach.
QWhen you wrap a retriever as an MCP tool, what changes about how and when retrieval happens?
Contrast one-shot pre-prompt injection with model-driven on-demand calls; discuss latency, multiple retrieval rounds, and the model choosing when to fetch.
Red flags & common mistakes
The phrases that signal junior thinking. Click to expand.
Red flags & common mistakes
The phrases that signal junior thinking. Click to expand.
Treating MCP and RAG as alternatives. RAG is a retrieval pattern; MCP is a connection protocol, and an MCP tool can run RAG internally.
60 second bullets to scan on the way to the call.
Define RAG as a pre-generation retrieval pattern
Define MCP as a runtime connection protocol
Primary sources. Browse if you want the original framing.
Same topic, related formats. Practice these next.