![Cover image for [MCP·Skill #3] MCP vs Skill vs Subagent: What to Use and When](/assets/images/posts/1bb00db5-c156-4575-854c-7218ac263b2c/1.jpg)
There are more ways than ever to extend AI coding tools: connect tools with MCP, register procedures with Skills, and delegate work to subagents.
The confusing part is that all three are described as extending the model’s capabilities, making it hard to know which one to use.
In one sentence: MCP is a hand, a Skill is a manual, and a subagent is a colleague.
This article explains what each one extends, how to choose between them, and what the combined architecture looks like.
Let’s start with the key takeaways.
- MCP extends what the model can do (tool and data access)
- A Skill extends how the model knows to work (procedures and domain knowledge)
- A subagent extends the workforce (an execution agent with a separate context)
- They are complementary, not competing. A subagent naturally reads a Skill and uses MCP tools.
What Each One Extends
Here is a comparison table before we examine them one by one.
| Category | MCP | Skill | Subagent |
|---|---|---|---|
| Extension target | Capability (tools·data) | Knowledge (procedures·know-how) | Execution agent |
| Form | Protocol·server process | Markdown folder | Separate context session |
| Analogy | Hand | Manual | Colleague |
MCP is a channel that reaches into systems outside the model. It enables tasks the model cannot physically perform alone, such as querying a database, calling an internal API, or controlling a browser. A separate server where the code runs is the defining characteristic.
A Skill does not grant a new capability; it helps the model perform an existing task well. It stores knowledge about “how,” such as release-note formats, review checklists, and internal documentation rules, in files. Its implementation is simply Markdown.
A subagent is another model instance with an independent context window. It can take on tasks such as exploration and research without polluting the main conversation history. Even when it searches through a large number of files, only the conclusion returns to the main context.
Three Questions for Choosing What to Use
When the choice is unclear, ask these three questions in order.
First, is this something the model physically cannot do right now? If access itself is impossible, such as querying an internal database, the answer is MCP. No amount of knowledge creates a missing hand.
Second, can it do the task, but do you have to explain the method every time? Then use a Skill. Any repeated prompt is a candidate for a Skill.
Third, is the workload large enough to pollute the context? If research and exploration turn the conversation into clutter, it is time to isolate them in a subagent.
Put another way: no access means MCP, no know-how means Skill, and no context—or insufficient context—means a subagent.
Combine All Three in Practice
The three are not mutually exclusive. Well-designed automation usually looks something like this.
Take automated code review: define a reviewer subagent (who), have it follow the team’s review-checklist Skill (how), and let it leave PR comments through a GitHub MCP server (what it can do).
The roles do not overlap; they operate at different layers. Each answers one of three questions: who, how, and with what.
Two Common Wrong Choices
Once the boundaries are clear, the antipatterns become clear too.
One mistake is building an MCP server for something a Skill would handle. For example, applying commit-message conventions is a knowledge problem that takes a few lines of Markdown; writing a server for it is overkill. Servers also bring maintenance and security-review costs.
The other is handling everything in a single main session. If the main session explores a large codebase directly, file dumps fill the context and leave no room for implementation. The standard approach is to delegate exploration to a subagent and receive only the conclusion in the main session.
Summary
In short: no capability means MCP, no know-how means Skill, and no hands means a subagent.
The MCP and Skill articles cover each topic in detail, so use this article’s framework to first decide which layer the automation you are building belongs to.