MCP vs RAG: What's the Difference?
·
RAG (retrieval-augmented generation) retrieves text and places it in the model's context before the model answers; MCP (Model Context Protocol) gives the model tools it calls during a task to read current records and take actions, such as updating a ticket or moving a deal stage. For agents built on customers' SaaS data, use RAG to search large, slow-changing content by meaning and MCP to read a record as it is now or write back, and expect to use both. Unified.to supplies both from the same customer connections: change events and request-time reads for a RAG pipeline, and Unified MCP for agents.
How do MCP and RAG compare?
MCP and RAG differ in what they hand the model: RAG hands it text your application chose, and MCP hands it tools the model chooses to call.
| Dimension | RAG | MCP |
|---|---|---|
| What it gives the model | Retrieved passages, added to the prompt | A list of tools with names, descriptions and input schemas, plus the result of each call |
| Who decides what is read | Your retriever, before the model generates | The model, by choosing which tool to call and with which arguments |
| When data is read | From an index built ahead of time (index-time RAG), or from the source when the question arrives (real-time RAG) | When the model calls a tool, at that step of the task |
| Can it act or write | No; it supplies context only | Yes, where the server offers write tools and the caller's permissions allow them |
| What it costs in context | The retrieved passages, sized by how many you return and how long each is | Tool definitions for every tool offered, plus each tool result |
| Authorization model | Access rules copied into the index as metadata and filtered at query time | Set by each server; the spec makes authorization optional and bases it on OAuth 2.1 for HTTP |
| Sources: MCP specification, Tools (tools are model-controlled; tools/list returns names, descriptions and input schemas); Anthropic tool-use docs (tool definitions and tool results count toward input tokens); Lewis et al., 2020, Retrieval-Augmented Generation (generation conditioned on retrieved passages). |
What is RAG?
RAG is a pattern in which your application finds passages relevant to a question and adds them to the model's prompt, so the answer is grounded in your content rather than only the model's training data.
In most systems the retrieval step is a similarity search over an index of chunked, embedded content; in real-time RAG it is a read against the source systems when the question arrives. Either way the model receives text it did not ask for by name, and it can reason over that text but not change anything in the source. Answers from an index reflect the index as of its last update. What Is a RAG Pipeline? covers the stages in detail.
What is MCP?
MCP is an open protocol in which an AI client asks a server which tools it offers, and the model then calls a tool by name with structured arguments and reads the result before deciding its next step. A tool can read a record, such as one ticket, or change one, such as a deal's stage, so the same interface serves lookups and actions. For how MCP servers run locally or over HTTP, and how the stateless 2026-07-28 revision changed sessions, see CLI vs MCP.
When should an agent use RAG, MCP or both?
An agent should use RAG to find content by meaning across a large body of text, MCP to read a specific record as it is now or to change it, and both when it has to find the right record first and then read its current state or update it.
RAG can't write, and calling a tool for every passage in a corpus-wide search costs an API call per lookup; that is the boundary in practice. Index-Time RAG vs Real-Time RAG sets out which data types to index and which to read at request time, and how a hybrid system decides per data type.
How do authorization and permissions differ?
RAG enforces permissions through the index, while MCP leaves authorization to each server, so a well-scoped MCP server can apply the source system's current access rules on every call.
With RAG, every chunk needs the access rules of the record it came from, stored as metadata and filtered on each query, and those rules have to be updated when a record is reassigned or a user loses access; when they lag, the index still returns content the user should no longer see. Permissions, Security, and Compliance in RAG Pipelines covers that filtering in detail.
MCP itself doesn't decide who can see what: the MCP authorization spec makes authorization optional and bases it on OAuth 2.1 for HTTP transports, so how access is scoped is up to each server. A server that scopes every tool call to one customer's connection and reads the source at call time gets the source's current access rules for that connection on each read, so a permission change applies to the next call rather than the next index rebuild. Rules for individual users inside that connection are still your product's job.
How does Unified.to support both?
Unified.to supports both through one API per category across 37 categories: Unified MCP gives agents tools on a single customer connection, and the same connections supply change events and request-time reads for a RAG pipeline.
For agents (Unified MCP)
- Connection-scoped tokens. Unified MCP generates a connection-scoped token, sent in the Authorization header, that is good for one connection and nothing else, so the workspace API key stays on your server; deleting the connection revokes it.
- Limits on what the agent can call.
permissions(named scopes, such as read-only CRM) andtools(tool IDs or patterns) narrow the tools offered, anddefer_toolsholds definitions back until the model needs them, which keeps tool definitions out of context. - Fewer personal fields reaching the model.
hide_sensitivestrips names, emails and phone numbers from results before they reach the model. - Per-connection tool lists. The catalogue holds 22,566 tools across 1867 integrations. That total is the catalogue across all integrations; each connection sees only its own tools: one HubSpot connection carried 69 tools, 30 of them CRM, on 12 October 2026.
- Change events. A connection's MCP server supports MCP Events, a draft MCP extension, so an agent can poll for changes or subscribe a webhook URL instead of re-reading records.
- Billing. Each tool call, and each MCP Events poll, counts as one API request on your plan; each delivered event counts like a webhook delivery.
For a RAG pipeline
- Keeping an index current. Native webhooks are forwarded as the integration sends them; where an integration sends none, virtual webhooks on supported integrations and objects check at an interval you set, down to 1 minute on paid plans, and a change arrives with the next check. Events carry the changed records where supported, so a follow-up fetch is usually not needed. Support varies by integration and object; check each integration's Feature Support tab.
- Reading at request time. Each call goes to the source API on the customer's connection and is mapped onto the category's model, so the same code reads records across CRMs or ticketing systems.
- No copy at Unified.to**.** Unified.to holds no customer records at rest; connection credentials and operational metadata are encrypted at rest (privacy policy). The index you build sits in your infrastructure.
For keeping an index in step with source changes, see Keeping Your RAG Index in Sync with Live SaaS Data; for setting up the server, see the Unified MCP documentation.
→ Start your 30-day free trial
Written by Mallory Greene.
About the author: Mallory Greene is Head of Marketing at Unified.to_. She writes about integration infrastructure, unified APIs, and MCP for technical teams. Based in Toronto._