Short version: Three extension mechanisms, three different jobs. A skill changes behavior. A subagent protects context. An MCP server adds a live connection. Reach for a skill first — it's the cheapest to build and most problems are really skill problems. Build an MCP server only when Claude needs live external data ("query," "fetch," "current state"). Spin up a subagent when a task would flood your main context or should run on a cheaper model. And in 2026 the real answer for a production workflow is usually all three, layered.
The one-sentence rule#
Founders keep asking "should this be a skill, a subagent, or an MCP server?" as if it's one question with three answers. It's three questions:
- **Do I want Claude to behave a certain way — follow my procedure, my format, my checklist? → Skill.**
- **Do I want to run a chunk of work without cluttering the main thread, or on a different model? → Subagent.**
- **Does Claude need to reach an external system for live data it can't get from the shell? → MCP server.**
Match the mechanism to the verb — teach, delegate, connect — and the choice stops being ambiguous.
The fast disambiguator#
The single most useful tell, when you're stuck: if your need contains the words "query," "fetch," or "current state," you need an MCP server, not a skill.
Skills carry static knowledge and procedures. They cannot, on their own, read a live database, hit your internal API, or pull today's ticket queue. The most common failed skill is one that says "go check the sales numbers and summarize them" with no way to actually reach the numbers. That's an MCP job wearing a skill's clothes. If you catch yourself writing "the current…" or "fetch the latest…" into a skill body, stop — you want a server.
Conversely, if the need is "always format commits this way" or "here's our release checklist," there's nothing live about it. That's a skill, and building an MCP server for it is over-engineering.
Start with a skill#
Reach for a skill first — it's a directory with a SKILL.md file, the fastest thing to write and the easiest to reason about. No server to host, no auth to wire, no second context window to pay for. A large fraction of "I need to build an agent for this" turns out to be "I need to write down a procedure," and a procedure is a skill.
Skills are also the cheapest at rest: a skill's name and description cost roughly 100 tokens at startup, and the body only loads when the request matches — that's progressive disclosure, and it's why you can install many skills without a context penalty. (If yours won't fire, the fix is almost always the description — see How to Write a Claude Skill That Actually Triggers.)
Escalate off a skill only when it hits a wall: it needs live data (→ MCP) or it needs isolation (→ subagent).
When it's really a subagent#
Spin up a subagent when the work would otherwise flood your main context window, or when you want it run in isolation: a long research pass, a big file audit, a parallelizable batch of edits. The subagent does the focused work in its own context window and hands back a summary — the main thread stays clean.
The second reason to reach for one is model choice. A subagent can run on a cheaper, faster model — Haiku for a mechanical scan or a bulk classification — while your main thread stays on a stronger model for the reasoning. You're buying two things: a protected context and a cost lever. The price is a whole second context window, which is exactly what you're spending it on.
When it's really an MCP server#
Build an MCP server when Claude needs a live link to something outside itself — a database, GitHub, a browser, an internal API, a SaaS tool. MCP is the connection layer: it exposes tools and resources over a standard protocol so Claude can actually do the query or the fetch.
It's the highest-effort of the three — you write or host a server and handle auth — so don't reach for it unless the "query / fetch / current state" test actually trips. And mind the runtime cost: an MCP server's tool schemas ride in your context every turn, so a bloated server is a recurring tax. The same trim-your-tool-descriptions discipline applies — keep the exposed surface tight.
The 2026 answer: compose all three#
Here's the shift. A year ago the question was "which one?" In 2026 the default answer for a real workflow is all three, layered, because they're not rivals — they're different parts of the stack:
A subagent running on a cheap model, preloaded with a skill that carries your conventions, calling a scoped MCP server for live data.
Each does its own job:
- The skill supplies the how — your procedure, your format, the right way to use the tools.
- The subagent supplies the isolation and the model choice — focused work, off the main thread, at the right price.
- The MCP server supplies the connection — the live data the skill's procedure operates on.
An MCP server doesn't replace a skill; a skill points at the server. The skill says "when the user asks for the weekly report, call the reporting tool like this and format it like that" — and the MCP server is what makes that tool exist. That composition is the pattern that actually pays for itself.
The decision, in one table#
| If you need to… | Reach for | Because |
|---|---|---|
| Apply a convention, checklist, or workflow consistently | Skill | It changes behavior; cheapest to build, ~100 tokens at rest |
| Run focused work off the main thread, or on a cheaper model | Subagent | It protects context and gives you a model lever |
| Reach a live database, API, or "current state" | MCP server | It adds a real connection Claude can't get from the shell |
| Ship a production workflow | All three, layered | Skill = how, subagent = isolation, MCP = connection |
Pick by the job, not the buzzword. Start with the skill. Add the subagent when context or cost demands it. Add the MCP server when — and only when — Claude has to reach outside itself.
Related, same stack: One SKILL.md, Five Coding Agents on how far a single skill travels, and Muse Code vs Claude Code vs Codex vs Antigravity on picking the terminal agent underneath all of this.
