The one-line answer: skills teach Claude how to do something, MCP servers let Claude reach something, and plugins are the box you ship either one in. If Claude already has the access but does the task wrong, you need a skill. If Claude literally can't touch the system (your database, your analytics, a browser), you need an MCP server. If you want to hand your setup to someone else, you package it as a plugin.

That distinction resolves most "which one do I build?" questions. Here's the longer version.

The three mechanisms side by side

	Skill	MCP server	Plugin
What it is	Markdown instructions (`SKILL.md`)	A program exposing tools over the Model Context Protocol	A distributable bundle
What it adds	Knowledge, procedures, conventions	New capabilities: APIs, databases, browsers	Skills, agents, MCP configs, hooks, commands — together
Where it lives	`.claude/skills/` or `~/.claude/skills/`	Runs as a process (local stdio) or hosted (remote HTTP)	Installed from a marketplace or repo
When it loads	On demand, when relevant or invoked with `/name`	Tools registered while connected	Whatever it contains, by that thing's rules
Costs when idle	~nothing (one description line)	Tool definitions in context	Depends on contents
Write one when	Claude has access but needs the method	Claude lacks access entirely	You want to distribute or install a setup

Skills: instructions, not code

A skill is a folder with a SKILL.md — frontmatter (name, description) plus markdown instructions. When your request matches the description, Claude loads the skill and follows it; typing /release-check invokes it directly. No process, no protocol, no dependencies.

Use a skill when the model is capable but uncalibrated: your deploy checklist, your migration conventions, the exact way your team writes commit messages. If you've corrected Claude the same way twice, that correction wants to be a skill.

MCP servers: capabilities, not knowledge

MCP (Model Context Protocol) is the open standard for giving AI agents tools. A server exposes typed tools — query_database, get_deployment_logs, click — and Claude Code calls them like any built-in tool. Servers run locally over stdio (claude mcp add name -- npx …) or hosted by the vendor over HTTP with OAuth (claude mcp add --transport http vercel https://mcp.vercel.com).

Use MCP when the limiting factor is reach: Claude can't query your Postgres, read your Sentry issues, or drive a browser by being told how — it needs the connection. Our best MCP servers for Claude Code list covers which ones earn their context cost, and the MCP catalog has 50+ pre-configured ones.

Plugins: the distribution layer

A plugin is not a third capability — it's packaging. One install can carry skills, subagents, MCP server configs, hooks, and slash commands as a unit. Marketplaces (git repos with a manifest) make them shareable across a team or a community.

Use a plugin when the audience is bigger than you-in-this-repo: your team's shared review workflow, a vendor's official toolkit, a themed bundle like an SEO or design pack. For just yourself in one project, plain .claude/ files are lighter — see how to organize skills, agents, and prompts for the layering rules.

How they compose

The mechanisms are complements, not competitors, and mature setups use all three:

A skill can instruct Claude on how to use an MCP server well ("query the analytics MCP with these event names, never raw SQL against prod").
A plugin can ship the skill and the MCP config it depends on, so one install produces a working workflow.
An agent defined in a plugin can be granted exactly the MCP tools it needs and nothing else.

A concrete example: a "database reviewer" setup is an MCP server (Postgres access) + a skill (your team's migration checklist) + an agent definition (read-only reviewer persona) — shipped as one plugin.

Common confusions, settled

"Slash commands" are skills. /deploy is just invoking a skill by name; they're one mechanism.
Installing a plugin doesn't automatically connect its MCP servers to your accounts — OAuth or keys still happen on first use.
MCP isn't Claude-specific. It's an open protocol; the same server works with other MCP clients. Skills and plugins are Claude Code conventions.
You rarely need to write an MCP server. For mainstream systems one already exists — writing one is for your internal/proprietary systems.

FAQ

I want Claude to follow my code style. Skill or MCP? Skill (or just CLAUDE.md if it's a short list of facts). Style is method, not access.

I want Claude to see production errors. Skill or MCP? MCP — that's reach. Connect Sentry's server, then optionally add a skill for your triage procedure.

I built a great setup. How do I give it to my team? Project-level things: commit .claude/ and .mcp.json to the repo. Cross-project things: package a plugin, or keep the canonical copies in a shared library like Vibe Coders' Kit and let teammates import from your public profile.

Do skills work inside plugins exactly like local ones? Yes — a plugin's skills load by description-match or slash command the same way; the plugin is just where they came from.