RAG or MCP: what is the difference and which to choose for giving a model data

"RAG or MCP" sounds like a choice between two competing technologies, but the comparison is between different levels. RAG is a scheme: before the question, the system itself finds the needed pieces of data and puts them into the request. MCP is a protocol for connecting tools to models: the model itself decides which tool to call and with what arguments. Below we look at how these approaches to giving a model data differ, what each costs and when they work together.

What RAG does

Retrieval-Augmented Generation has three steps:

1. The application receives the user's question.
2. The application itself searches your base for fragments (full-text or vector search; see the article on a RAG pipeline on your own data↗).
3. What it found goes into the request, and the model answers in one call.

The decision about what to search for is made by the application code, not the model. One call, predictable behaviour.

What MCP does

MCP (Model Context Protocol) standardizes connecting external capabilities: an MCP server offers a set of tools (and other entities such as resources), and a client, such as Claude Code or your application, passes their descriptions to the model. During the dialogue the model itself asks for a tool to be called, the client calls it and returns the result, and the model continues. It is a loop of several requests. The overall picture is in the article what an MCP server is↗.

Importantly, MCP is not a search method. It is a way to attach a function. The function may search a knowledge base, run SQL, read tickets in a tracker or create a file.

The main differences

What each option costs

Let us count one question. Assumptions: tool descriptions and the system prompt take 1,500 tokens, the question 500, each tool call result 1,200 tokens, a tool call with arguments 150 output tokens, the final answer 500.

RAG. One call: input 3,000 tokens (five fragments of 500 and a 500-token question), output 500.

MCP, a loop of four calls. History grows: after every step a tool call (150 tokens) and its result (1,200) are added.

Zukko prices as of October 18, 2026 per 1M tokens, no cache.

• claude-sonnet-5-5 (input 0.4, output 2). RAG: 0.003 × 0.4 + 0.0005 × 2 = 0.0012 + 0.001 = $0.0022. MCP: 0.0161 × 0.4 + 0.00095 × 2 = 0.00644 + 0.0019 = $0.00834.
• deepseek-v4.1-flash (input 0.013, output 0.038). RAG: 0.003 × 0.013 + 0.0005 × 0.038 = 0.000039 + 0.000019 = $0.000058. MCP: 0.0161 × 0.013 + 0.00095 × 0.038 = 0.000209 + 0.000036 = $0.000245.

For 10,000 questions a month with claude-sonnet-5-5: RAG 10,000 × 0.0022 = $22, MCP 10,000 × 0.00834 = $83.4. The loop costs more because the same prefix is sent again at every step. For Claude in the Anthropic format (/v1/messages) the repeating start of the dialogue is read from cache at a lower price and the gap narrows; in the OpenAI format Claude is billed entirely at the input price. A step-by-step calculation with cache is in the article on the cost of an agent↗. The assumptions are illustrative: the number of MCP steps depends on the model and the tools, and descriptions of 30 tools easily take more than 1,500 tokens.

One code base for both approaches

You can write the search function once and use it two ways. Here is a RAG skeleton:

from openai import OpenAI

client = OpenAI(base_url="https://api.zukko.pro/v1", api_key="fetch_your_key")


def search_docs(query: str, k: int = 5) -> list[str]:
    ...  # your search: SQLite FTS5, pgvector, anything


def answer_with_rag(question: str) -> str:
    chunks = search_docs(question)
    context = "\n\n".join(chunks)
    resp = client.chat.completions.create(
        model="claude-sonnet-5-5",
        messages=[
            {"role": "system", "content": "Answer only from the fragments. If there is no answer, say so."},
            {"role": "user", "content": f"Fragments:\n{context}\n\nQuestion: {question}"},
        ],
    )
    return resp.choices[0].message.content

And the same function as an MCP tool. An example on the official Python SDK for MCP (check imports and startup against the SDK documentation for your version):

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("docs")


@mcp.tool()
def search_docs(query: str) -> str:
    """Search the company document base. Returns up to 5 fragments."""
    return "\n\n".join(search_docs_impl(query))


if __name__ == "__main__":
    mcp.run()

Here search_docs_impl is your search implementation. The server is attached to Claude Code or another MCP-capable client following that client's instructions.

If you build an agent not through MCP but directly through the API, the same function can be described as a tool in the tool-use format: see the full tool-calling cycle↗.

When to choose which

RAG fits when:

• the data is a relatively stable set of documents: policies, help, a knowledge base;
• each question needs one search, not a chain of actions;
• predictable price and latency matter;
• you must show the user the source.

MCP fits when:

• the data is live: orders, tickets, stock, metrics, and cannot be cut into fragments in advance;
• a question needs several steps: find a customer, get their orders, add up the total;
• the model must do something, not just read: create a task, send a request;
• there are many tools and it is unknown in advance which will be needed.

Combination. A scheme that often works: search over the knowledge base is wrapped as one MCP tool, and the model calls it itself when it sees fit. The data stays in RAG, and MCP is the way it is attached. If the answer must always come from the knowledge base, it is more reliable to always run the search in code rather than leave it to the model.

MCP pitfalls

• Tool descriptions consume context. Each connected server adds descriptions to every request; disable what you do not need.
• Trust in tool results. Text returned by a tool (a web page, a ticket, an email) may contain instructions you did not write. Do not give the agent rights you are not ready to lose, and restrict write actions.
• Spend. A loop without a step limit can spend a lot: set a daily limit on the key in the dashboard and cap the number of steps in code.

FAQ

Are RAG and MCP the same thing?

No. RAG is the scheme "find and insert into the prompt", MCP is a protocol for attaching tools. Search for RAG can be offered through MCP, but you can do without it.

Which is cheaper?

For one question usually RAG: one call and a small input. The MCP loop sends history at every step, so it costs more, although cache softens this. In the calculation above, $0.0022 versus $0.00834 on claude-sonnet-5-5.

Can MCP replace RAG?

For live data yes; for a large static knowledge base usually no: the model will spend steps on searching. It is more practical to keep the search in code or wrap it in a single tool.

Which Zukko models suit MCP?

Any that support tool calls in your client. Test the chosen model on several real questions: price, context and the strength index in the catalogue help pick candidates, and testing on your own tasks decides.

To try it, create a key in the Zukko dashboard↗ and run the RAG example; then add a tool.