People treat plugins, skills, and MCP servers as three options on the same menu, then get confused when the comparison doesn’t quite work. The reason it doesn’t is that they’re not at the same level. Skills and MCP servers are individual capabilities. A plugin is a container that can bundle them — and slash commands, subagents, and hooks — into one installable package.
Once you see the layering, the “vs” dissolves. This article lays out the layers, shows how they nest, and gives a clear rule for when you want a single piece versus a whole bundle. If you’ve already got the skills-versus-MCP distinction down, this adds the plugin layer on top; if not, skills vs MCP vs subagents is the companion piece.
The layering
Think in two layers: the pieces, and the package that bundles them.
Pieces vs package
| Layer | What it is |
|---|---|
| Pieces | Individual capabilities you add |
| Package | A bundle of pieces installed together |
A skill teaches a procedure. An MCP server connects to a system. A slash command runs a prompt. A subagent delegates work. A hook fires on an event. Each is a single, independent piece. A plugin is a box you put several of those pieces in so they install as a unit.
That’s the whole relationship. A plugin isn’t a competitor to a skill any more than a toolbox is a competitor to a hammer.
How they nest
A concrete example makes it click. Imagine a “code quality” plugin. Open it up and inside you might find:
- A subagent — a code reviewer.
- A skill — your team’s review conventions.
- A slash command —
/reviewto trigger it on demand. - A hook — auto-format after edits.
- An MCP server — GitHub, so the reviewer can read PRs.
Installing that one plugin sets up all five pieces. You could also assemble the same thing by hand: add the subagent, write the skill, create the command, configure the hook, connect the server. Same result, more steps. The plugin just packages the assembly.
The context-cost consequence
Because a plugin is the sum of its contents, its cost is too. This matters most for MCP servers, which load their tool definitions up front every session.
Where context goes
| Skill (standalone or in a plugin) | Near-zero until relevant |
|---|---|
| MCP server (standalone or in a plugin) | Standing cost every session |
| Plugin | Sum of what it bundles |
A plugin that bundles three MCP servers costs you three servers’ worth of context whether or not you use all three. So “install this plugin” can quietly mean “connect three servers,” with the context hit that implies. Always look at what a plugin contains — the too-many-MCP-servers guide explains why this adds up.
When you want a single piece
Reach for an individual piece when your need is specific and you want control:
- You need Claude to reach one system — add that MCP server directly.
- You want to encode one procedure — write that skill.
- You repeat one prompt — make a slash command.
- You want one focused helper — define a subagent.
Adding a piece directly keeps your setup transparent: you know exactly what’s there and why. For a single capability, a plugin is overhead.
When you want a plugin
Reach for a plugin when:
- You want a coordinated bundle — a whole code-quality or platform-integration setup, not one piece.
- You’re distributing to a team — a plugin in a marketplace means everyone installs the same setup with one command, no step-by-step wiki.
- You’re adopting someone’s setup — a maintained plugin that matches your stack saves you assembling it yourself.
The deciding question is simple: are you adding a capability, or a set? One piece, add it directly. A set, especially one others should share, use a plugin. For the how-to, see installing plugins and marketplaces.
The decision in one place
Which layer do you need?
- Need one system connection? → Add an MCP server directly
- Need one procedure encoded? → Write a skill
- Need one reusable prompt? → Create a slash command
- Need a coordinated set of pieces? → Use a plugin
- Distributing a setup to a team? → Build a plugin in a marketplace
- Always check a plugin's contents for context cost and reach
Wrapping up
Plugins, skills, and MCP servers aren’t three choices at the same level. Skills and servers are pieces; plugins are packages that bundle pieces together. Add a piece directly when you need one capability and want control. Reach for a plugin when you want a coordinated set or need a team to share one setup — and always check what a plugin bundles, because its context cost and reach are the sum of its parts.
For the related decision between connecting versus bundling, see MCP vs plugins — which to use, and for the full feature map, the power-user guide.
