If you’ve spent more than ten minutes around Claude in the last six months, you’ve heard three words thrown around almost interchangeably: skills, plugins, and MCP. They sound like the same kind of thing. They’re not. And confusing them is the difference between shipping an agent that works and shipping one that quietly burns 60,000 tokens before you’ve typed a single message.
Here’s the one-line mental model that actually holds up:
MCP is the wiring. Skills are the instructions. Plugins are the package.
That’s the whole post in eleven words. The rest is earning it.
The three things, defined
MCP — Model Context Protocol
MCP is a protocol, not a product. Think of it as USB for AI agents: a single standard way for any AI assistant to talk to any external tool or data source — your CRM, your database, your file system, your email. An “MCP server” is just a small program that exposes some capability (say, “read rows from this Postgres table”) in a format Claude knows how to call.
If you’ve ever wired a chatbot up to your company’s data, you know the pain: every integration is bespoke, every model has its own tool-calling format, and rewiring it for a new model is a small project. MCP is the answer to that. Anthropic open-sourced it in late 2024, and by 2026 most major agent platforms speak it.
The thing to internalise: MCP is plumbing. It doesn’t know what your business does. It just moves structured data between Claude and the outside world.
Skills
A skill is a folder. Specifically, it’s a folder with a SKILL.md file at the root, written in plain markdown with a small bit of YAML metadata at the top. That file tells Claude how to do something — write a press release in your house style, fill out a vendor onboarding form, generate a financial model from a template.
Skills can include extra files: scripts Claude can run, reference documents it can read, templates it can fill in. But the entry point is always that one markdown file.
The clever bit is how skills load. Claude only sees the skill’s name and one-line description by default — roughly 30–50 tokens. The full instructions only get pulled into context when the skill is actually triggered. You can have a hundred skills installed and your context window stays clean.
Anthropic introduced the format in October 2025 and released it as an open standard in December 2025. By early 2026 it had been picked up by Claude Code, Claude.ai, the API, OpenAI Codex, Cursor, Gemini CLI, and Windsurf — which is unusual for a format from a single vendor and tells you something about how the gap was felt across the industry.
A skill is knowledge and procedure. It teaches the model how to do something well, the way you’d teach a new hire by handing them a runbook.
Plugins
Plugins are the newest of the three, shipped with Claude Cowork in early 2026. A plugin is an installable package that bundles everything you need for a job to be done: skills, MCP server connections, slash commands, and sometimes specialised sub-agents — all in one zipped folder you can install with a click.
If skills are runbooks and MCP servers are the wires, a plugin is the complete kit. The “Sales” plugin doesn’t just include a Salesforce MCP connector or just a “draft a follow-up email” skill — it includes both, plus the slash commands to invoke them, configured to work together out of the box.
Anthropic launched 11 official plugins at release, covering legal, sales, finance, marketing, and data analysis, and opened a marketplace shortly after.
A side-by-side that actually helps
| MCP | Skills | Plugins | |
|---|---|---|---|
| What it is | A protocol for connecting AI to external systems | A folder of instructions teaching the model how to do a task | A bundle of skills + MCP servers + commands |
| Answers the question | “How does Claude reach my data?” | “How does Claude do this specific job well?” | “What’s the easiest way to install a complete capability?” |
| Who builds it | Tool/platform vendors, internal infra teams | Anyone with a markdown editor | Solution providers, internal platform teams |
| Who consumes it | Skills, plugins, agent runtimes | End users (transparently), other skills | End users, directly |
| Lives where | A running server (local or remote) | A folder in the agent’s filesystem | A package installed into the agent |
| Token cost | Tools loaded eagerly can be expensive — a 5-server setup with 58 tools has been measured at ~55k tokens before you say a word | ~30–50 tokens per skill until triggered | Sum of whatever’s bundled inside |
A concrete example: the weekly sales report
Imagine you want Claude to produce a weekly sales report for your team every Monday morning. The report needs to pull live numbers from Salesforce, format them in your company’s voice, and land in a specific Slack channel.
Done with MCP alone: you connect a Salesforce MCP server and a Slack MCP server. Claude can now query data and post messages. But it has no idea what a “good” weekly report looks like for you. Every week you re-explain the structure, the tone, which metrics matter. Painful.
Done with a skill alone: you write a skill called weekly-sales-report that contains your template, your tone guide, and the exact metrics breakdown. But Claude has no way to actually fetch the numbers or post the message — the skill is a beautifully-written set of instructions for data that doesn’t exist in the conversation.
Done together: the skill says what the report should look like and walks Claude through composing it. The MCP servers give Claude the wires to fetch the live data and deliver it. The skill calls the MCP tools as part of its procedure.
Done as a plugin: someone (you, or a vendor, or your internal platform team) bundles the skill, both MCP server configs, and a /weekly-report slash command into a single .plugin file. Your sales ops team installs it in one click. They don’t need to know any of the above.
That’s the layering. MCP makes the data reachable. The skill makes the work repeatable and on-brand. The plugin makes the whole thing distributable.
Common confusions, cleared up
“Isn’t a skill just a fancy prompt?” No. A prompt is a single instruction to the model right now. A skill is a versioned, file-based artifact the model loads on demand and can include scripts and reference data. Closer to a function in your codebase than a chat message.
“Doesn’t an MCP server already include the instructions for how to use its tools?” It includes tool descriptions — what each tool does and what arguments it takes. It does not include opinionated workflows like “for our company, the sales report always opens with this paragraph and uses these three KPIs.” That’s skill territory.
“If a plugin contains skills, why have skills as a separate concept?” Because not every skill needs to ship in a plugin. A two-person startup can drop a single SKILL.md into a folder and be done. Plugins are the distribution and bundling story; skills are the unit of capability.
“Does Claude need MCP to use a skill?” No. Plenty of skills are purely instructional — “write a contract clause in this style,” “produce a one-pager from these notes” — and never call out to anything. Skills only need MCP when the work involves external data or actions.
Which one should you reach for?
A rough decision tree:
- You need Claude to talk to a system it currently can’t reach. That’s an MCP problem. Look for an existing MCP server; build one if you have to.
- You need Claude to do a recurring task in a specific way. That’s a skill. Write the SKILL.md, drop it in the skills folder, and let the model find it when relevant.
- You need to ship a working capability to people who don’t want to assemble parts. That’s a plugin. Bundle the skills and MCP configs and hand over a
.pluginfile.
The lazy-but-correct rule of thumb: start with a skill. If it needs to talk to your systems, add an MCP connector. If you’re going to share it with five or more people, wrap it in a plugin.
Where this is going
The interesting thing about the three-layer stack is how cleanly the responsibilities split. Vendors and infra teams own MCP. Domain experts own skills (you don’t need to be an engineer to write one). Distributors own plugins. That separation is what’s letting the agent ecosystem scale faster than the chatbot ecosystem ever did — each layer can be improved independently, by different people, on different timelines.
If you take one thing from this post, take this: the next time someone tells you to “just build an MCP server” or “just write a skill” for a problem, ask which of the three layers actually needs attention. Most teams I’ve watched struggle with Claude in production weren’t missing capability — they were trying to solve a skill problem with MCP, or a plugin problem with skills. The layers exist for a reason. Use the right one.
