There’s a real decision hiding behind a confusing comparison. MCP servers and plugins aren’t the same kind of thing — a server is one connection, a plugin is a bundle that might include servers — but you genuinely do choose between them in practice. The question “should I add this MCP server directly, or install the plugin that includes it” comes up constantly, and the answer shapes how lean and transparent your setup stays.
This is that decision, made simple. If you want the conceptual layering first, plugins vs skills vs MCP explained covers why these sit at different levels. This article is about the practical call.
The actual choice
You rarely choose “MCP or plugin” in the abstract. You choose between two ways of getting a capability:
Two ways to get the same capability
| Add a raw MCP server | You connect one server with claude mcp add. You control the config. |
|---|---|
| Install a plugin | You get a bundle that may include that server plus commands, skills, hooks. |
If the GitHub integration you want exists both as a standalone server and inside a plugin, that’s the fork in the road. Same underlying capability, two delivery mechanisms — one minimal, one bundled.
Add a raw MCP server when…
You want one specific connection and nothing else. The advantages of going direct:
- Transparency. You know exactly what’s connected and why. Nothing extra rode along.
- Control. You set the scope, the credentials, the exact config. No surprises from a bundle.
- Leaner context. You pay for one server’s tool definitions, not a plugin’s worth of pieces.
This is the right default for single capabilities. Need a database connection? Add the Postgres server. Need GitHub? Add the GitHub server. The MCP setup guide covers the mechanics, and the best MCP servers list covers the picks.
Install a plugin when…
You want a coordinated set, or you’re working at team scale:
- A bundle you’d assemble anyway. If you’d end up adding the server plus a reviewer subagent plus a
/reviewcommand plus a format hook, a plugin that ships all of them saves the assembly. - Team distribution. A plugin in a marketplace means everyone installs the same setup with one command. That’s the strongest reason to choose a plugin over raw pieces — consistency without a setup wiki.
- Adopting a maintained setup. A well-kept plugin that matches your stack is less work than building and maintaining the equivalent yourself.
The deciding factor is breadth and sharing. One piece, just for you → raw server. A set, or for a team → plugin. The marketplace setup guide shows how to install and publish them.
The context-cost angle
This is where the choice has a measurable consequence. An MCP server costs the same context whether you add it raw or it arrives inside a plugin — its tool definitions load up front either way. What a plugin adds is everything else it bundles.
What you pay
| Raw MCP server | That server's tool definitions, up front |
|---|---|
| Plugin with one server | Same server cost, plus any commands/skills/hooks it adds |
| Plugin with several servers | Every bundled server's cost, every session |
So a plugin is never cheaper than the raw server for the connection itself — it can only be equal or heavier, depending on what else it carries. If you’re watching context, that argues for raw servers unless you genuinely want the rest of the bundle. The too-many-servers guide has the full picture on keeping context lean.
They coexist
This isn’t exclusive. A normal setup mixes both: a couple of raw MCP servers you control directly, plus one plugin for a coordinated toolset or a team standard. The goal isn’t ideological purity about delivery mechanism — it’s the leanest setup that does your work. Sometimes that’s all raw servers; sometimes a plugin earns its place.
Making the call
- Need one connection? → Add the MCP server directly
- Want a coordinated bundle you'd build anyway? → Plugin
- Distributing a standard to a team? → Plugin in a marketplace
- Only want one piece of a plugin? → Add that piece directly instead
- Check a plugin's bundled servers for hidden context cost
- Mixing both is normal — optimize for a lean setup, not purity
Wrapping up
The real choice is delivery: add a capability as a raw MCP server, or get it inside a plugin bundle. Go raw for single connections — it’s transparent, controllable, and lean. Choose a plugin when you want a coordinated set or need a team to share one setup. And remember the cost math: a plugin is never cheaper than the raw server for the connection itself, only potentially heavier from what it bundles alongside.
For the layered concept behind all this, see plugins vs skills vs MCP explained; for the full feature set, the power-user guide.
