Claude Skills vs MCP vs Plugins: What Each One Actually Does
Skills, MCP servers and plugins get lumped together as "ways to extend Claude", but they solve different problems. A skill is packaged instruction: it teaches an agent how to do a task it could already technically perform. MCP is a protocol for connecting an agent to external tools and data it otherwise cannot reach. Plugins are host specific packaging that bundle either of those into a particular application. Pick based on whether your gap is knowledge or access.
What is a Claude Skill, precisely?
A skill is a folder of instructions, and usually some supporting files, that gets loaded into the model context when it becomes relevant. At minimum it contains a description of what the skill is for and a body of procedural guidance: the steps, the conventions, the edge cases, the output format you expect. It can also ship reference documents, example files, templates and scripts that the agent runs with the tools it already has.
The key thing to internalise is that a skill does not give the model any new capability. If Claude can already read files, run a shell and write code, a skill for generating PDF reports is not unlocking PDF generation. It is telling the model which library to use, how your reports are structured, which fields matter, and what to do when the data is missing. It converts a task the model would improvise badly into one it performs consistently.
That makes skills the right tool for anything where the failure mode is "it did the thing, but not the way we do it here". Coding conventions, review checklists, brand voice for marketing copy, the exact migration procedure your team follows, the shape of a spec document. All of those are knowledge problems. You are encoding institutional memory so you stop retyping it into every conversation.
What does MCP actually solve?
The Model Context Protocol is a specification for how an agent talks to an external system. An MCP server exposes a defined interface: a list of tools it can perform, resources it can read, and prompts it offers, all described in a machine readable way so any MCP compatible client can discover and call them. The client does not need bespoke integration code per system, which is the entire point of standardising it.
MCP is about capability and access, not instruction. If your database lives behind a VPN, or your issue tracker is a hosted SaaS with an API key, no amount of written guidance lets the model query it. You need something that can actually make the call, handle auth, and return structured results. That is an MCP server. The same logic applies to browser automation, filesystem access outside the working directory, internal search indexes and analytics warehouses.
MCP servers also carry a runtime cost that skills do not. A server is a process or a remote endpoint that has to be running, authenticated and reachable. It can fail, rate limit, or return stale data. When you evaluate one, you are evaluating an integration, so the questions are the usual ones: who operates it, what credentials does it want, what scope do those credentials have, and what happens when it goes down mid task.
Where do plugins and extensions fit?
Plugins are a packaging and distribution layer, and they are specific to the host application that defines them. A plugin format exists so a user can install a bundle in one step and have the host wire everything up, rather than manually copying folders, editing config files and starting servers. What goes inside the bundle is usually some combination of the two things above: skills, MCP server definitions, commands, and configuration.
Because the format belongs to the host, portability is limited by design. A bundle built for one application assumes that application knows how to read its manifest, resolve its dependencies and expose its commands. The underlying skill files or MCP server may well be reusable elsewhere, but the wrapper is not. This is worth knowing before you judge an ecosystem by its plugin count: those numbers describe one host, not the whole landscape.
The practical consequence is that plugins rarely belong in the "which one should I use" decision at all. You decide whether you need instruction or access first. The plugin question comes afterwards and is really a question about installation ergonomics for your team: is it easier to hand people a one line install, or to check the skill into the repo so it travels with the codebase and gets reviewed like any other file?
How do you decide which one you need?
Start with the failure you are trying to fix. If the agent has everything it needs but produces the wrong shape of output, misses steps, or reinvents an approach you have already settled, that is a knowledge gap and you want a skill. If the agent literally cannot see or touch the system in question, that is an access gap and you want MCP. This one distinction resolves most of the confusion, and it is worth running through explicitly rather than reaching for whatever you installed last.
They compose, and the best setups lean on that. An MCP server exposes a database with dozens of tools and no opinion about how to use them. A skill sitting alongside it can say: always run the read only query first, never drop a column without a backup migration, prefer these three views over raw tables, and here is the naming convention for new indexes. The server provides the reach, the skill provides the judgement. Neither is sufficient alone for a system with real conventions.
A useful sanity check: could a competent contractor do this task with only a written brief and the tools already on their laptop? If yes, write a skill. If they would first need a VPN, an API key and a login, you need MCP, and probably a skill to go with it once they start using it wrong.
What does all of this cost you in context?
Everything you load competes for the same context window. Skill descriptions have to be visible for the agent to know a skill exists, so a long list of installed skills consumes tokens on every request whether or not any of them fire. MCP servers advertise their full tool schemas, and a chatty server with fifty tools and verbose parameter descriptions can eat a serious chunk of the window before you have typed anything.
The second order effect is worse than the token count. More options means more chances to pick the wrong one. An agent with four overlapping ways to search a codebase will sometimes choose the slowest or least accurate, and you will spend the conversation correcting it. Ruthless pruning is a real performance optimisation, not tidiness. Install what you use this week, remove what you installed for one experiment last month.
This is also why skill authoring quality matters more than skill quantity. A skill with a sharp, specific description fires when it should and stays quiet otherwise. A vague description like "helps with code" either never triggers or triggers constantly. Keep the always loaded surface small and push detail into files the agent reads only after it has decided the skill is relevant.
The same discipline applies to MCP servers, with one extra step: you often get to choose which tools a server exposes. If a server offers forty operations and your workflow uses four, restricting it to those four shrinks the advertised schema and removes thirty six chances to pick the wrong call. Where a server has no such filtering, weigh whether the access is worth the permanent context tax it charges on every single request.
Frequently asked questions
Can a skill replace an MCP server?
Only if the access already exists through some other route. A skill can tell the agent to shell out to a CLI tool, hit a public HTTP endpoint with curl, or read a local file, and in those cases you genuinely do not need a server. But if the system is only reachable through an authenticated API with no CLI, a skill has nothing to instruct the agent to call. Written guidance cannot manufacture a connection.
Do I need a plugin to use a skill?
No. Plugins are one distribution mechanism among several. Skills are ordinary files, so you can commit them to your repository, drop them in a user level directory, or share them as a zip. Committing them to the repo has a real advantage for teams: the skill is versioned with the code it describes, changes go through review, and every contributor gets the same behaviour without a separate install step.
How many skills and MCP servers should I have loaded?
Fewer than you think. There is no universal number, but the useful heuristic is that if you cannot name what each installed item does and when it last helped, it should be removed. Overlapping capabilities are the specific thing to hunt for, because they make tool selection ambiguous and quietly degrade results. Treat your loaded set like a dependency list and audit it periodically.
Are skills portable between different agents and tools?
The content usually is, since a skill is largely instructions in a text file, and good instructions about your migration process or review checklist do not depend on the runtime. The packaging and the discovery mechanism are what vary: how a host finds a skill, when it decides to load it, and what metadata format it expects. Expect to rewrite manifests rather than rewrite substance.