Claude Code skills vs subagents vs plugins vs MCP servers: what to use when

The four are not four ways to do the same thing, which is why "skills vs subagents" is the wrong question to start from. A skill is instructions Claude follows in your current conversation, a subagent is a separate context window that does side work and hands back a summary, an MCP server is a connection to a system outside Claude, and a plugin is the box you put the other three in so somebody else can install them. Pick by the problem: repeated instructions become a skill, context pollution becomes a subagent, an external system becomes an MCP server, and sharing any of them becomes a plugin.

Everything below was checked against the Claude Code documentation, with commands confirmed against Claude Code 2.1.281. The skills, subagents and MCP pages were checked on 24 September 2026; Anthropic reorganised the plugin documentation on 25 September, so every plugin claim here was re-checked against the pages that carry it on 26 September 2026.

#Which one solves which problem?

Read the last column first. Three of the four rows describe a different failure you are trying to fix, and the fourth is about distribution rather than behaviour.

#What exactly is a skill?

A skill is a directory containing a SKILL.md file: YAML frontmatter, then Markdown instructions. The documentation describes the case for one directly. Use a skill "when you keep pasting the same instructions, checklist, or multi-step procedure into chat, or when a section of CLAUDE.md has grown into a procedure rather than a fact."

The economics are the part people miss. As the docs put it, "Unlike CLAUDE.md content, a skill's body loads only when it's used, so long reference material costs almost nothing until you need it." CLAUDE.md is paid for on every turn. A skill is paid for when it fires.

Skills load from more places than most people realise:

Two invocation routes are on by default. You can type /skill-name, and Claude can load the skill on its own based on the description in the frontmatter. Each can be switched off: disable-model-invocation: true leaves only you able to invoke it, and user-invocable: false leaves only Claude.

For writing one, our guide to Claude Code skills and custom slash commands covers the authoring side in detail, and the Agent Skills hub tracks the cross-tool format.

#What exactly is a subagent?

A subagent is a Markdown file with frontmatter that defines a specialist: name, description, and optionally tools, model, permissionMode, skills, memory and more. The documentation's framing of when to reach for one is precise about the benefit:

Use one when a side task would flood your main conversation with search results, logs, or file contents you won't reference again: the subagent does that work in its own context and returns only the summary.

That separation is the whole point: "Each subagent runs in its own context window with a custom system prompt, specific tool access, and independent permissions."

A minimal definition is short:

---
name: code-reviewer
description: Reviews code for quality and best practices
tools: Read, Glob, Grep
model: sonnet
---
You are a code reviewer. When invoked, analyze the code and provide
specific, actionable feedback on quality, security, and best practices.

There are three ways to reach it, escalating in how strongly you commit: name it in your prompt and let Claude decide whether to delegate, @-mention it directly, or make it the session default with claude --agent code-reviewer.

Our subagents guide goes further into built-in agents and routing work to cheaper models.

#How do you decide between a skill and a subagent?

Ask what you are trying to protect. A skill protects you from repeating yourself. A subagent protects your context window.

That gives a usable test. If the work produces output you want to read and build on in this conversation, a skill keeps it where you can see it. If the work produces output you want the conclusion of and nothing else, a subagent keeps the raw material out of your way.

The line is softer than it looks, and it is worth knowing why before you argue about it. A SKILL.md can set context: fork to run in a forked subagent context, and agent to choose which subagent type handles it. A related field, background, only applies with context: fork and can be set to false to wait for the forked subagent's result. So a skill that has grown expensive can be moved behind a context boundary without being rewritten as a subagent.

The two also compose in the other direction: a subagent's frontmatter takes a skills field that preloads skills into its context. A skill is not a small subagent and a subagent is not a big skill. One is instructions, the other is an execution boundary, and a mature setup usually has both.

#When is an MCP server the right answer?

When the gap is access rather than instruction. MCP is an open standard for connecting Claude to external tools and data sources, and the documentation's trigger for using one is behavioural:

Connect a server when you find yourself copying data into chat from another tool, like an issue tracker or a monitoring dashboard. Once connected, Claude can read and act on that system directly instead of working from what you paste.

No skill can close that gap on its own. A skill can tell Claude how to interpret your Jira tickets beautifully and still have no way to read one.

Servers are added from the command line, and the scope decides who gets them:

claude mcp add --transport http notion https://mcp.notion.com/mcp
claude mcp add --transport http shared-server --scope project https://example.com/mcp
claude mcp add --env AIRTABLE_API_KEY=YOUR_KEY --transport stdio airtable -- npx -y airtable-mcp-server

Project scope is the one to reach for on a team, because .mcp.json is a checked-in file. HTTP is the recommended transport for remote servers, stdio runs a local process, SSE is documented as deprecated but supported, and WebSocket is configured through claude mcp add-json rather than a --transport flag.

The MCP hub tracks the protocol itself.

#Where do plugins fit in?

A plugin is not a fifth kind of capability. It is a directory that holds the other kinds, with a manifest at .claude-plugin/plugin.json:

One placement rule is worth naming, because getting it wrong fails silently. The documentation puts it plainly: "Only plugin.json goes inside .claude-plugin/. Components saved there don't load." So skills/, agents/, hooks/ and the rest go at the plugin root, beside that folder rather than inside it.

The documentation frames the decision as standalone configuration versus a plugin rather than as plugin versus skill, and it draws the line by audience rather than by capability:

Skills, agents, hooks, and MCP servers all work standalone in your project or home directory. Keep that standalone setup while it serves one project or only you. Make a plugin when you want to share the setup with teammates, install it in several projects, or publish versioned releases.

Take that literally. Nothing you can do in a plugin is unavailable standalone, so the reason to package is distribution, not power. The visible difference is naming: a standalone skill is /hello, and the same skill inside a plugin is /plugin-name:hello. Building the plugin first buys you namespacing and a manifest you do not need yet.

Installing one from Anthropic's official marketplace is a single command, because Claude Code registers that marketplace for you the first time you start an interactive session. Any other marketplace has to be added first, with /plugin marketplace add:

/plugin install commit-commands@claude-plugins-official

While you are developing, claude --plugin-dir ./my-plugin loads a plugin without installing it at all.

One caution belongs here rather than at the end, because a plugin is the one mechanism of the four that ships somebody else's executable code. Claude Code's plugin security page is direct about it:

A Claude Code plugin you install can execute arbitrary code on your machine with your user privileges.

The same page is specific about how: hooks "execute shell commands with your full user permissions", and "Claude Code runs hooks and MCP servers outside the sandbox". It also warns that Anthropic "cannot verify that they will work as intended or that they won't change", so a plugin you audited can change under you. Nothing on ClawDocx endorses any third-party plugin or skill. Before installing somebody else's bundle, work through our skill security audit checklist.

#A worked decision

Say you want Claude Code to review pull requests against your team's standards.

1. The standards themselves are a skill. They are a procedure you would otherwise paste. Put them in .claude/skills/pr-review/SKILL.md and commit them.
2. Reading the pull request needs an MCP server. Claude cannot see GitHub without one. Add it at project scope so the whole team gets it from .mcp.json.
3. If the review floods your context, it becomes a subagent. Diffs, CI logs and file contents are exactly the material the subagent documentation describes keeping out of the main conversation. Define .claude/agents/pr-reviewer.md with only the tools it needs.
4. When another team asks for it, it becomes a plugin. Move the skill into skills/, the agent into agents/, the server config into .mcp.json, add a manifest, and publish it through a marketplace.

Each step is triggered by a problem that appeared, not by a decision made up front. That ordering is the practical answer to "what should I use", and the Claude Code hub tracks the features as they change.

#What this comparison does not settle

Two things are genuinely open rather than simply unwritten here.

The first is what happens when the same name exists twice, standalone and inside a plugin. For skills the answer is visible in the name: a plugin skill is namespaced as /plugin-name:skill-name, so a standalone /skill-name and a plugin copy coexist rather than one shadowing the other. For agents we could not establish the rule from the pages we checked, so we are not stating one. If you are migrating a standalone setup into a plugin, check the behaviour you get rather than assuming it matches the skill case.

The second is cost. The /plugin interface shows a context cost estimate for a plugin before you install it, and /plugin lists plugins you have not used recently, but neither gives you a per-skill budget across a whole configuration. If you are running many skills at once, measure rather than assume.