The question is not which one wins. MCP, RAG, and Agent Skills answer three different questions, and any agent doing real work usually runs all three at once. The confusion comes from the fact that all three are pitched as ways to “give the model more context”, which is true and useless, like saying a database and a config file both “store data”.
This guide separates them properly. MCP vs RAG vs Agent Skills, compared on what each one actually connects to, how each one loads into the context window, what each costs in tokens, and which one to reach for when. Every token figure below was measured on a real setup rather than estimated, including the tool schemas from four live MCP servers, seventeen real skills, and a 92,000 token document corpus, all verified in August 2026 against MCP specification revision 2026-07-28 and the Agent Skills specification at agentskills.io.
On this page
- What MCP, RAG, and Agent Skills each actually do
- MCP vs RAG vs Agent Skills at a glance
- How MCP works
- How RAG works
- How Agent Skills work
- What each one costs in context tokens
- Which one to reach for
- Where the three are converging
- Where each one breaks down
What MCP, RAG, and Agent Skills each actually do
Three sentences, then the detail.
MCP gives an agent capability. The Model Context Protocol is a wire protocol, JSON-RPC over stdio or HTTP, that lets a model call out to systems it does not control: a Kubernetes cluster, a GitHub repo, a Postgres database, a browser. Anthropic published it in November 2024 and donated it to the Agentic AI Foundation in December 2025. It answers “how does my agent do things”.
RAG gives an agent facts. Retrieval Augmented Generation, from the 2020 Lewis et al. paper, splits a document corpus into chunks, embeds them as vectors, and at query time pulls back only the handful of chunks that match the question. It answers “how does my agent know things it was never trained on”.
Agent Skills give an agent procedure. A skill is a folder with a SKILL.md file: YAML frontmatter plus Markdown instructions, optionally bundled with scripts and reference files. The agent reads the name and description at startup and pulls in the rest only when a task matches. It answers “how does my agent know the way we do things here”.
Capability, facts, procedure. Almost every argument about which one to use dissolves once you name which of those three you are short of.
Notice the bottom row. That is where the three differ most and where the trade-off actually lives, so it gets its own section further down.
MCP vs RAG vs Agent Skills at a glance
The comparison that matters is not feature lists. It is what each one attaches to, when it costs you tokens, and what breaks when it goes wrong.
| Dimension | MCP | RAG | Agent Skills |
|---|---|---|---|
| Supplies | Capability (actions) | Facts (knowledge) | Procedure (know-how) |
| Artifact | A running server | A vector index | A folder with SKILL.md |
| Interface | JSON-RPC 2.0 | Similarity search | Markdown on a filesystem |
| When it loads | At startup, always | Per query, on demand | Name at startup, body on trigger |
| Token cost model | Fixed, scales with tool count | Per query, independent of corpus size | Near zero until triggered |
| Needs infrastructure | Yes, a process to run | Yes, an embedding model and a store | No, just files |
| Freshness | Live by definition | As fresh as the last re-index | As fresh as the last commit |
| Typical failure | Tool schemas crowd the window | Retrieves the wrong chunks | Description never matches, skill never fires |
| Governance | Agentic AI Foundation | None, it is a pattern not a spec | Open spec at agentskills.io |
One line in that table explains most of the confusion in the wild: RAG is a pattern, while MCP and Agent Skills are specifications. You can implement RAG a hundred ways and all of them are RAG. MCP and SKILL.md each publish a schema you either match or you do not.
How MCP works
An MCP server exposes some mix of three things: tools (functions the model can call), resources (data the host can read), and prompts (templated workflows the user can pick). The host application connects, asks what is available, and hands the schemas to the model.
The protocol changed shape significantly in the 2026-07-28 revision, the largest breaking change in its history. The initialize and initialized handshake is gone and so is the Mcp-Session-Id header, which makes the core stateless: every request carries its own protocol version and capabilities in _meta, so any instance behind a load balancer can serve it. Roots, sampling, and logging were deprecated in the same revision under a policy that guarantees twelve months before anything can be removed.
You can watch the whole exchange without a client. An MCP server on stdio reads newline delimited JSON-RPC, so a few echoed requests are enough to make it list its tools. Note the version gap: servers published to npm today still speak a pre-2026-07-28 revision (the filesystem server negotiates up to 2025-11-25, the last handshake based revision), so the handshake the new spec retired is still exactly what you send to probe them.
printf '%s\n' \
'{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-06-18","capabilities":{},"clientInfo":{"name":"probe","version":"1.0"}}}' \
'{"jsonrpc":"2.0","method":"notifications/initialized"}' \
'{"jsonrpc":"2.0","id":2,"method":"tools/list","params":{}}' \
| npx -y @modelcontextprotocol/server-filesystem /tmpThe server answers with every tool it offers, each carrying a full JSON Schema. Here is one entry from the filesystem server, trimmed (the real response also carries title, annotations, execution, and outputSchema per tool):
{"jsonrpc":"2.0","id":2,"result":{"tools":[
{"name":"read_text_file",
"description":"Read the complete contents of a file from the file system as text...",
"inputSchema":{"type":"object",
"properties":{"path":{"type":"string"},
"head":{"type":"number"},
"tail":{"type":"number"}},
"required":["path"]}}
]}}That schema is the entire cost of MCP. It is not a pointer the model follows later, it is text sitting in the context window for the whole session. Fourteen tools from that one server measured 8,299 bytes of tool definitions. Setting up the servers themselves is a separate job, covered in the guide on how to connect Claude Code to MCP servers.
How RAG works
RAG inverts the problem. Instead of putting knowledge into the window and hoping the model finds it, you keep the knowledge outside and fetch only the fragments a specific question needs.
The ingestion side runs once, and again whenever documents change: split each document into chunks, run each chunk through an embedding model, store the resulting vectors. The query side runs every time: embed the question with the same model, find the nearest chunks by vector similarity, paste those chunks into the prompt alongside the question.
The numbers on that diagram are from a real corpus, not an illustration. Indexing 41 technical documents produced 276 chunks of up to 1,200 characters, averaging 334 tokens each. The full corpus measures 92,072 tokens. A top-5 retrieval for one question costs 1,778 tokens, which is 1.9% of the corpus.
That ratio is the whole argument for RAG, and it holds no matter how large the corpus grows. Double the documents and the retrieval payload stays at 1,778 tokens; only the index grows. It is also why “large context windows killed RAG” was always wrong for corpora of any size: a 500 million token knowledge base does not fit in any window that exists, and the context rot research Chroma published in July 2025, covering 18 models, showed performance degrading with input length even on trivial tasks. Filling the window is not free even when it fits.
Where RAG hurts is precision. The retrieval step is a guess, and when the top-5 chunks miss the relevant passage the model answers confidently from the wrong material. Chunk size, overlap, hybrid keyword plus vector search, and a reranking pass all exist to fight that. If you want a working pipeline rather than the theory, we have built one two ways: a self-hosted RAG with Ollama and pgvector and a Qdrant based RAG with LangChain.
How Agent Skills work
A skill is the least technically impressive of the three and, for a lot of teams, the highest return. There is no protocol and no infrastructure. There is a directory and a Markdown file.
Create the directory and open the file, without sudo, because a root owned file under your own home directory is a skill your agent cannot manage later:
mkdir -p ~/.claude/skills/incident-triage
vim ~/.claude/skills/incident-triage/SKILL.mdTwo frontmatter fields are required and everything after them is free-form Markdown:
---
name: incident-triage
description: Triage a production alert by pulling recent deploys, error rates, and
the on-call runbook. Use when an alert fires or when someone asks why a service
is degraded.
license: Apache-2.0
---
# Incident triage
## Step 1: establish the blast radius
Check the error rate per endpoint before touching anything...
Full escalation matrix: [references/ESCALATION.md](references/ESCALATION.md)
Run the collector: scripts/collect_metrics.shThe published specification caps name at 64 characters (lowercase, digits, and single hyphens, matching the directory name) and description at 1,024. Optional fields are license, compatibility, metadata, and the experimental allowed-tools. That is the whole schema.
The design work goes into the description, because the description is the only part the agent sees until it decides to act. It has to state what the skill does and when to use it. A description reading “helps with incidents” never fires; the one above fires on the right prompts because it names the triggers.
Level 3 is the part worth internalising. A bundled script never enters the context window at all: the agent runs it and reads the output. A 400 line Python collector costs whatever its output costs, which might be four lines. That makes scripts strictly cheaper than asking the model to write equivalent code, and deterministic on top.
Skills started as an Anthropic feature in October 2025 and became an open specification that December. Adoption moved fast: Cursor, VS Code, GitHub Copilot, Gemini CLI, Codex, Goose, JetBrains Junie and a long tail of other agents now read the same format, which means a skill written once is portable in a way an MCP server config is not.
What each one costs in context tokens
This is the section that decides architectures, and it is the one nobody publishes numbers for. So here are measurements taken with Anthropic’s /v1/messages/count_tokens endpoint against claude-sonnet-4-5, using real servers and real files rather than synthetic examples.
Four MCP servers, connected over stdio, asked for their tool lists. The schemas were converted to Anthropic tool format and priced:
| MCP server | Tools | Tokens | Tokens per tool |
|---|---|---|---|
| Playwright | 22 | 3,866 | 176 |
| Filesystem | 14 | 2,614 | 187 |
| Memory | 9 | 1,710 | 190 |
| Sequential thinking | 1 | 1,532 | 1,532 |
| All four connected | 46 | 9,722 | 211 |
Sequential thinking is the outlier worth staring at: one tool, 1,532 tokens, because its description is an essay explaining when to use it. Tool count is a bad proxy for cost. A single verbose tool can outweigh nine terse ones.
Every figure in that table is version specific, which matters more than it sounds. They were measured against @playwright/[email protected] and server-filesystem 2026.7.10. The current Playwright release exposes 24 tools rather than 22, so the same four servers today come to roughly 10,800 tokens. Pin your versions before quoting anyone’s numbers, including these.
Those 9,722 tokens are spent before the user types anything, on every request, whether or not a browser is ever opened. On a 200K window that is 4.9%. The same four servers on a 32K local model would eat 30% of it.
Skills were measured the same way, across all 17 skills in one repository:
| Stage | What loads | Tokens |
|---|---|---|
| Discovery (all 17 skills) | name plus description only | 2,636 |
| Discovery, per skill | median, range 34 to 282 | 147 |
| Activation, per skill | median SKILL.md body | 2,206 |
| All 17 bodies, if they all fired | every SKILL.md in full | 40,143 |
The measured median of 147 tokens per skill runs about 47% above the roughly 100 tokens the specification suggests, which is worth knowing if you are planning for fifty skills rather than five. The important figure is the ratio: 2,636 tokens buys visibility into 40,143 tokens of instructions, and all 40,143 stay on disk until a task actually calls for them.
Putting all three side by side on the same corpus and the same machine:
| Approach | Always in the window | Loaded on demand | What stays out of the window |
|---|---|---|---|
| MCP, 4 servers | 9,722 tokens | Tool results, unbounded | Nothing, the interface is all up front |
| Agent Skills, 17 skills | 2,636 tokens | 2,206 per activation | 40,143 tokens of instructions |
| RAG, 41 documents | 0 tokens | 1,778 per query | 92,072 tokens of corpus |
Read that table as a spectrum of laziness rather than a ranking. RAG defers the most because a document has no reason to be present until asked for. MCP defers the least because a model cannot call a tool it has not been told exists. Skills sit in between deliberately: enough to be discoverable, nothing more. None of these is better; they are priced according to what they have to guarantee.
The same discipline applies to everything else in the window, which is the subject of our guide to context engineering for AI agents, and to the practical side of cutting token usage in Claude Code.
Which one to reach for
Match the shortfall to the mechanism.
Reach for MCP when the agent needs to act on a system it cannot reach. Querying a production database, opening pull requests, driving a browser, calling an internal API. If the answer requires doing something outside the model, no amount of retrieved documentation substitutes. Keep the loadout tight: connect the servers this task needs, not every server you own.
Reach for RAG when the answer lives in a body of text too large to paste and too volatile to bake in. Product documentation, ticket history, legal archives, a wiki that changes hourly. The tell is scale plus churn. If your corpus is small and stable, skip the vector store and put the text in a file the agent can read.
Reach for Agent Skills when the model already knows the domain but not your version of it. Claude knows what a changelog is. It does not know your release checklist, your naming conventions, or that deploys are frozen on Fridays. That is procedural knowledge, it is small, it belongs in Markdown, and it is the cheapest of the three to write and to run.
The pattern that shows up most in practice combines all three: a skill encodes the procedure, MCP provides the tools that procedure calls, and RAG supplies the reference material the procedure cites. A release skill says “check the changelog format, query the CI status through the GitHub server, cite the relevant policy from the docs index”. Three mechanisms, one workflow, each doing the job it is priced for.
Sub-agents are the fourth lever people reach for here, and they are orthogonal: they buy you a separate context window rather than a cheaper one. When the concern is isolation rather than cost, that is covered in the guide to configuring specialized subagents.
Where the three are converging
Treating these as three permanent, separate categories is already slightly out of date.
MCP has a Skills over MCP working group, formed as an interest group in February 2026 and promoted to a working group that April, co-led by maintainers from Nordstrom and Anthropic. Its current direction is SEP-2640, a Skills Extension built on MCP’s existing Resources primitive, which would let a server distribute skills the same way it distributes tools. If that lands, “MCP or Skills” stops being a question: a server will serve both, and a skill will be something you can install from a registry rather than copy into a folder.
The 2026-07-28 extensions framework is what makes that possible. Rather than every new idea becoming core protocol, capabilities now ship as opt-in extensions negotiated per request, with Tasks already moved out of the core into io.modelcontextprotocol/tasks.
RAG is drifting toward the same place from the other direction. The moment retrieval is exposed as an MCP tool the model can call with its own query, rather than a pipeline stage that fires before the model sees anything, it stops being a preprocessing step and becomes just another capability. That is agentic retrieval, and it is mostly a repackaging of RAG as MCP.
Where each one breaks down
Each of the three has a characteristic failure that is invisible until it has been running a while.
MCP fails by accumulation. Servers get added and never removed, and because the cost is fixed and silent nobody notices until the agent starts forgetting instructions from earlier in the session. Four servers at 9,722 tokens is fine. Twelve, extrapolating from that same average, is roughly 29,000 tokens of schema competing with the actual work. Audit the connected list the way you would audit a firewall’s rule set: what is here, what still earns its place.
RAG fails by confident retrieval of the wrong thing. The pipeline always returns its top-k, and it returns them with no signal that they are irrelevant. A query with no good match still gets five chunks and the model still writes a fluent answer from them. The mitigations are a similarity floor below which you return nothing, and answers that cite the chunk they came from so a human can spot the mismatch.
Skills fail by never firing. A skill with a vague description sits in the context window costing its share of that discovery budget forever and never activates, because the agent never matched a task to it. This failure is completely silent: nothing errors, the agent simply does the task the generic way and the carefully written procedure is ignored. The fix is to write descriptions as trigger conditions, name the words a user would actually say, and then test by prompting for the task and checking whether the skill loads.
All three failures share one root: the context window is a budget, and every mechanism here is a different strategy for spending it. Knowing which one you are short of, capability, facts, or procedure, is most of the decision.
