Agent Skills vs MCP vs plugins

Three extension points, overlapping names, and a lot of confusion about which solves what. The distinction is actually clean once you see it:

• Skills change what the agent knows and decides
• MCP servers change what the agent can reach
• Plugins are how you distribute either one

Most of the time you want the first, and people reach for the second.

Skills: instructions loaded on demand

A skill is a folder with a SKILL.md file — Markdown guidance plus a short frontmatter block naming when it applies. The agent keeps only each skill’s name and description in context, and pulls in the full body when your request matches.

There is no process, no port, nothing to keep alive. It is knowledge, written down, in a place the agent knows to look.

Skills are the right tool when the agent is capable of doing the thing but keeps doing it wrong:

• It writes tests, but not in your project’s style
• It knows the deployment commands, but not that staging must go first
• It picks the library you migrated away from last year

None of that needs new capabilities. It needs judgement the model has no way to infer from the code in front of it. That is a skill.

MCP servers: capabilities the agent does not have

The Model Context Protocol is an open standard for connecting agents to external systems. An MCP server is a running process that exposes tools, resources, and prompts over that protocol; the agent discovers them and can call them.

This is a genuinely different axis. No amount of instruction lets an agent query your production Postgres, read a Jira ticket, or fetch a Figma file. It needs an actual connection, with actual credentials, to an actual system.

Reach for MCP when the answer to “why can’t the agent do this?” is “it has no way to reach that system”, rather than “it doesn’t know how we do things”.

The cost is real, though: a server to run, credentials to manage, a failure mode when it is down, and tool definitions that occupy context whether or not you use them. It is infrastructure. Skills are a text file.

Plugins: the packaging layer

A plugin is not a third kind of capability — it is a bundle. One plugin can contain:

• Skills
• Slash commands
• Subagents
• Hooks
• MCP server configuration

When you run /plugin marketplace add owner/repo followed by /plugin install name, you are usually installing a set of skills in one step, sometimes with MCP servers wired up alongside them.

This is why “plugins vs skills” is a category error. Asking it is like asking whether you want a library or a package manager. Most of the entries in our catalog are individual skills that happen to be distributed inside a plugin.

Side by side

	Skill	MCP server	Plugin
What it is	Markdown instructions	Running process exposing tools	A bundle of the others
Changes	How the agent decides	What the agent can reach	How you install things
Runtime	None	A process you operate	None itself
Credentials	None	Usually yes	Whatever it bundles
Context cost	Name + description at rest	Tool definitions always	Depends on contents
Fails when	Description is vague	Server is down	—
Effort to build	Minutes	Hours to days	Packaging step

Choosing, in one question

Can the agent already reach everything it needs?

If yes, your problem is judgement — write a skill. This covers far more cases than people expect, because an agent with filesystem and shell access can already do a great deal; it just does not know your constraints.

If no, you need an MCP server for the missing connection. And you will often still want a skill alongside it, telling the agent when and how to use those new tools well.

They compose

The strongest setups use both, in layers:

1. An MCP server connects the agent to your issue tracker
2. A skill explains your team’s triage conventions — which fields matter, what “priority 1” actually means, when to escalate
3. A plugin packages both so a new engineer installs them in one step

The MCP server supplies capability. The skill supplies judgement about using it. The plugin makes it distributable. None substitutes for the others.

Practical starting point

If you are setting this up for a team, start with a project-scoped skill. Put a SKILL.md in .claude/skills/ in your repository, capture the convention people re-explain most often, and commit it. Cost: one Markdown file. Benefit: every engineer’s agent, including the next hire’s, applies it automatically.

Add MCP when you hit a concrete wall — a system the agent genuinely cannot see. Add plugins when you have enough pieces that installing them one at a time is annoying.

To see what already exists before building anything, browse the catalog by category — integrations is where MCP-adjacent skills cluster, while workflow and testing hold the judgement-encoding kind. The best integrations picks are a reasonable place to start.