Three of Claude Code’s features get mixed up constantly: skills, MCP servers, and subagents. People build a skill when they needed a server, or stand up a server for something a skill does better, or never reach for a subagent when their context is drowning. The features look similar from a distance — they all “extend Claude Code” — but they solve genuinely different problems.
This is the decision guide. Three short definitions, a comparison table, the context-cost trade-off, and a flowchart-in-prose for picking the right one. If you want the full tour of every feature, the power-user guide is the hub; this article is just about telling these three apart.
The one-line version
- MCP servers connect. They give Claude a live link to an external system — a database, GitHub, a browser, an internal API.
- Skills teach. They package a procedure or body of knowledge Claude pulls in when relevant — a review checklist, your commit format, a release process.
- Subagents delegate. They run a focused task in an isolated context window, optionally on a different model, and hand back a summary.
Connection, know-how, delegation. Hold those three words and most of the confusion clears.
Side by side
Skills vs MCP vs subagents
| Skills | |
| Job | Encode a procedure or knowledge |
| Lives in | .claude/skills/ |
| Loaded | On demand when relevant |
| Context cost | Near-zero at rest |
| Reaches outside the repo? | No |
| Best at | Conventions, repeatable steps |
The row that matters most is “loaded.” It’s the difference that drives the cost trade-off, and it’s the one people overlook when they default to MCP for everything.
The context-cost trade-off
Here’s the practical consequence that should shape your choices. A connected MCP server loads its tool definitions into the context window when the session starts — names, descriptions, parameter schemas — whether or not you use it. That’s a standing cost, paid every session, for every connected server.
A skill costs almost nothing until it’s relevant. Claude reads only the short description; the body loads on demand. So a dozen skills are cheap to keep around, while a dozen MCP servers quietly shrink the window you have to work in.
Subagents take a third approach: they isolate context. The subagent’s own reading and reasoning stay in its context window, and only the summary returns to the main thread, which keeps the primary conversation lean even for heavy work.
When to use each
A decision path you can run in your head.
Use a skill when…
The thing you want is knowledge or a procedure. You keep pasting the same instructions. You want Claude to follow your conventions — commit format, review checklist, the way your team writes tests. There’s no external system involved; it’s all “here’s how we do this.” Skills are the default for anything that’s really just repeated instructions. Start with skills explained.
Use an MCP server when…
Claude needs to reach something outside the codebase, live. Query a database, read GitHub issues, drive a browser, hit an internal API. The defining test: is there an external system it has to talk to in real time? If yes, that’s MCP. If you’re just encoding how to do something, it isn’t. Start with MCP explained and the best servers.
Use a subagent when…
You want to delegate a focused chunk of work without cluttering the main thread, or you want to run that work on a different model. Exploring a large codebase, reviewing a diff, writing tests — all good subagent jobs because the messy intermediate work stays isolated. The defining test: would this task generate a lot of context you don’t want in the main conversation? Then delegate it. Start with the subagents guide.
They compose
This isn’t a contest with one winner. The three layer together, and a real setup uses all of them:
- A subagent for code review that uses an MCP server to read the GitHub PR and follows a skill that encodes your review standards.
- A context-gatherer subagent on a cheap model that reads the codebase, while the main thread follows a skill for your architecture conventions.
So the question is rarely “which one” in the abstract — it’s “which one for this specific need,” and then they work side by side.
A worked example
Say you want Claude to review pull requests against your team’s standards. Walk it through:
- Does it need live external data? Yes — it has to read the PR from GitHub. So you need the GitHub MCP server.
- Is there a procedure to encode? Yes — your review checklist, the things your seniors always flag. That’s a skill.
- Do you want it isolated from the main thread? Yes — a review generates a lot of reading you don’t want cluttering your working session, and it suits a mid-tier model. So wrap it in a code-reviewer subagent.
The result uses all three: a subagent (delegation), pulling PR data through MCP (connection), applying a skill (know-how). Each does the part it’s best at.
Picking the right tool
- Reaches a live external system? → MCP server
- Knowledge or a repeatable procedure? → Skill
- Focused work you want isolated or on another model? → Subagent
- Watch context: MCP costs up front, skills are cheap, subagents isolate
- Combine them — they're designed to work together
Wrapping up
Skills, MCP servers, and subagents aren’t competing tools; they’re answers to different questions. MCP is for connecting to systems, skills are for encoding procedures and knowledge, and subagents are for delegating isolated work. The mistakes come from blurring them — usually building an MCP server for something that’s really a skill, and paying context for it every session.
Match each to its job, watch the context cost, and let them compose. For where these sit among hooks, plugins, and the rest, head back to the power-user guide; for the plugin-specific version of this comparison, see MCP vs plugins.
