Claude skills vs agents: five names, three jobs, one real decision

The hard part isn't learning what a skill is. It's the moment you have a task and five plausible homes for it: a skill, a subagent, an MCP server, a plugin, or just more text in CLAUDE.md. Ask in any Claude community and you'll find the same question phrased a dozen ways — skill or slash command? subagent or MCP? do plugins replace any of this?

The names suggest five competing options. There are really three jobs:

Skills teach. Subagents isolate. MCP connects. Plugins are how you ship the other three to someone else.

Everything below is that sentence with the receipts — and one thing no comparison seems to state plainly: these mechanisms differ most in when they enter your context window and what they cost you when they do. That's the decision axis.

The 60-second answer

Anthropic's own framing matches: CLAUDE.md is always-on context, skills are on-demand knowledge, MCP supplies external services, subagents supply isolation, hooks supply deterministic automation.

Skills: on-demand knowledge

A skill is a folder. SKILL.md at the root with a name and description, optionally scripts and reference files beside it. Anthropic's docs describe them as filesystem-based resources discovered by metadata and loaded only when relevant.

The mechanism that matters is progressive disclosure: at startup the agent preloads only each skill's name and description; the full body loads only when Claude judges it relevant. Twenty installed skills cost you a paragraph until one fires. That is the whole trick, and it's why Simon Willison called them possibly a bigger deal than MCP.

Skills are also portable: one artifact works across Claude.ai, Claude Code, the Agent SDK and the Developer Platform, and the format became an open standard in December 2025.

"Claude Skills" vs "Agent Skills" — same SKILL.md standard, different deployment layer. Claude Code's flavour is a superset: it adds invocation control, execution inside subagents, and dynamic context injection on top of the portable format.

Subagents: isolation, not intelligence

A subagent is a Markdown file with YAML frontmatter that runs in its own separate context window, with its own system prompt, tool access and permissions, and hands back a summary. It is not a smarter model. It's a clean desk.

That clean desk has a price. Anthropic's own multi-agent research write-up puts it plainly: their multi-agent system beat single-agent Opus 4 by 90.2% on an internal research eval — and used about 15× the tokens of a chat interaction, with token spend alone explaining ~80% of performance variance.

So: reach for a subagent when the context is the problem — a sprawling search, a noisy build log, a review pass you don't want in your main thread. Not because the task is hard.

Do skills work inside subagents? Yes, but not by accident: a subagent only gets the skills listed in its frontmatter, and Claude Code's built-in agents can't use your custom ones. Since June 2026 subagents can also spawn their own subagents, capped at five levels.

MCP servers: plumbing, and the bloat that comes with it

MCP is how Claude reaches things it doesn't contain: your database, your issue tracker, your API. Anthropic frames it as the complement to skills — MCP supplies the capability, a skill supplies the procedural knowledge for using it well.

The catch is that tool schemas load up front. Every session, before you type anything. Community measurements:

Sources: Scott Spence's audit, a nine-server setup on r/ClaudeAI, HN measurements. At 67,300 tokens that last one is roughly a third of a 200k window spent before work begins. In fairness, some tools double-count what /context reports — but the direction is not in dispute, and the ecosystem's own fix (progressive disclosure of tools, code-mode execution) is borrowed straight from the skills philosophy.

That convergence is the real story: MCP is becoming more skill-like, because loading everything up front doesn't scale.

Plugins: distribution, not a fourth capability

A plugin bundles slash commands, subagents, MCP servers, hooks and skills into one installable unit, distributed through git-repo marketplaces and installed with /plugin. It adds no new powers. It answers "how does my team get all of this at once?"

Worth knowing before you install broadly: one practitioner audited 47 public community skills and reported that 40 of them made results worse — extra tokens, extra latency, narrower output — with 7 worth keeping. One person's audit, not a study, but it matches the intuition: every installed skill spends description tokens on every session, and a vague description fires when it shouldn't.

Composing them: one real workflow

The mechanisms aren't rivals; a decent setup uses three at once. Concretely — an agent producing a client report:

1. A skill carries the house style: section order, how to phrase a caveat, which numbers always need a source. It's dormant until a report is actually being written.
2. A subagent does the research sweep — dozens of pages read, one summary returned. The reading never touches your main context.
3. One MCP call publishes the finished report to a live, tracked URL. That last step is ours: ReportRoom exposes publishing as an MCP tool, so the agent finishes the job instead of handing you HTML to paste somewhere.

claude mcp add --transport http reportroom https://mcp.reportroom.io/mcp

Then "publish this as a tracked page" is a single tool call, and get_analytics later tells the agent who actually read it. That's the shape worth copying whatever tools you use: teach with a skill, isolate with a subagent, and let MCP carry the output somewhere real — the docs are here.

Sharing this across a team

The honest state of play: skills version like code because they are files — commit the folder, review changes in a PR, tag releases. Plugin marketplaces are just git repos, so an internal one is a private repo your team installs from. What's still missing is curation and inspection: no permission model that tells you what an installed skill can reach, no signal beyond stars for whether a community skill is any good, and no inheritance — a subagent doesn't get your skills unless you list them.

If you're rolling this out to a team, the durable advice is: keep skills in the repo they serve, and treat a marketplace install like adding a dependency, because that's what it is.

FAQ

Are skills and agents different things, or two names for the same idea? Different layers. A skill is knowledge an agent loads when relevant; an agent (or subagent) is a process with its own context and tools. An agent uses skills.

If an agent can already do the work, why add a skill? Because the agent doesn't know your way of doing it. A skill is the difference between a competent stranger and a colleague who's read your handbook — and it costs almost nothing until it's needed.

Can one skill be shared across agents? Yes — the same SKILL.md works across Claude.ai, Claude Code, the Agent SDK and the Developer Platform, and it's an open standard other agents can adopt. Inside Claude Code, a subagent must list the skills it's allowed to use.

Do subagents make things faster, or just cleaner? Mostly cleaner — isolation is the point. You can get parallelism from several subagents, but you pay for it: ~15× the tokens of a chat turn.

Where do plugins fit now? Packaging. They bundle commands, subagents, skills, MCP servers and hooks so a team installs one thing. No new capability of their own.

MCP or skills? Both, usually. MCP is a connection; a skill is knowledge. If the answer is "Claude can't reach that system," you want MCP. If it's "Claude reaches it but does the wrong thing with it," you want a skill.