Guide
Skills vs subagents vs MCP vs plugins
Four primitives, four jobs. A Skill changes how the agent works (methodology, loaded into the current context). A subagent changes where work runs (a separate instance with its own context window). An MCP server changes what the agent can reach (external tools and data). A plugin changes how they ship (a bundle of the other three). Most real setups use several at once.
If you only need the Skill / MCP / plugin distinction, the shorter Skill vs MCP vs Plugin guide covers three. This page adds subagents — the fourth primitive people most often confuse with Skills.
The one-line answer
Four primitives
Skill
How the agent works — methodology, conventions, voice. A SKILL.md file (instructions + optional scripts) the agent loads when its description matches the task.
Subagent
Where the work runs — isolated from the main conversation. A separate agent instance with its own model, tools, and context window that does a job and returns only the result.
MCP server
What the agent can reach — databases, APIs, browsers, filesystems. A running program exposing tools and data to the agent over the Model Context Protocol.
Plugin
How a coordinated set is shipped — packaging, not a new capability. A distribution package that bundles Skills, subagents, slash commands, hooks, and MCP servers into one installable unit.
Side by side
What each one is
| Primitive | Changes | Context | Use it when |
|---|---|---|---|
| Skill | How the agent works — methodology, conventions, voice. | Loads into the current session’s context, on demand. | You want the agent to do something it can already attempt, but better and more consistently. |
| Subagent | Where the work runs — isolated from the main conversation. | Its own fresh context window; the main thread sees only the summary. | You want to isolate a noisy or long task (a big search, a review) so it does not flood the main context. |
| MCP server | What the agent can reach — databases, APIs, browsers, filesystems. | External process; the agent calls its tools. | The agent needs access to a system it cannot otherwise touch. |
| Plugin | How a coordinated set is shipped — packaging, not a new capability. | Installs its contents; namespaced so multiple plugins coexist. | You want a one-line install for a coordinated set across repos or a team. |
Decision tree
Pick the right primitive
- Q1. Can the agent reach the data and tools the task needs? → If no, add an MCP server.
- Q2. Is the agent capable of the task but doing it inconsistently or to a low standard? → Add a Skill.
- Q3. Is the task long or noisy enough to pollute the main conversation’s context? → Run it in a subagent.
- Q4. Are you shipping a coordinated set of the above to a team or marketplace? → Wrap it in a plugin.
In practice
They stack
These are not alternatives — they compose. A worked example: a plugin ships a code-review subagent that runs in its own context, loads the trail-of-bits Skill for the audit methodology, and calls a GitHub MCP server to fetch the diff. One install, four primitives, each doing the one job it is good at.
FAQ
Common questions
What is the difference between a skill and a subagent?
A Skill changes how the main agent works by loading instructions into the current context. A subagent is a separate agent instance with its own model, tools, and context window — it runs a job in isolation and returns only the result. Use a Skill to improve how a task is done; use a subagent to keep a noisy task out of the main conversation.
Is a subagent the same as an MCP server?
No. A subagent is another instance of the agent itself, running in its own context. An MCP server is an external program that exposes tools and data. A subagent can use Skills and MCP servers; an MCP server cannot run an agent.
When should I use a skill vs an MCP server?
Use a Skill when the agent is already capable of the task but inconsistent — you are giving it methodology. Use an MCP server when the agent cannot reach the data or system it needs — you are giving it access. Most workflows use both: MCP for connectivity, the Skill for the method.
Do plugins replace skills?
No. A plugin is packaging. It bundles Skills, subagents, commands, hooks, and MCP servers so they install together. Plugin skills are namespaced (for example /my-plugin:review) so multiple plugins can coexist.
Can one plugin contain a skill, a subagent, and an MCP server?
Yes. That is the point of a plugin — it is a container for a coordinated set of extensions, so a team can share a complete capability (the methodology, the isolated worker, and the connectivity) in a single install.
Next: What is a Claude skill · How to create one · Best skills by use case