Skills, plugins, and MCP servers: what's actually the difference?

You wired up an MCP server, someone told you to install a skill instead, and a third person said just grab the plugin. Three answers, three words, and a quiet suspicion that they might all be the same thing wearing different hats.

They are not. Skills, plugins, and MCP servers sit at three different layers, and once you see the layers the confusion goes away for good. Here is the short version, then the longer one.

The 20-second answer

An MCP server is a connection. It lets your AI tool reach an outside system: a database, a repo, a Slack workspace, an API. A skill is an instruction set. It teaches the tool how to do a specific job, and nothing more. A plugin is a box. It bundles skills, MCP configs, commands, and more into one thing you install in a single step.

Connection, instruction, box. If you remember those three words you already understand the difference. The rest of this post is why each one exists and where people trip.

What an MCP server is (the connection)

MCP stands for Model Context Protocol, an open standard introduced by Anthropic in late 2024 and now backed by every major model vendor, Anthropic, OpenAI, Google, Microsoft, and AWS. Its whole job is to let an AI application talk to outside tools and data through one common interface.

The problem it solves is boring and enormous. Before MCP, every model needed its own custom glue for every tool it wanted to touch. Ten models and ten tools meant up to a hundred one-off integrations. MCP turns that N-times-M mess into N-plus-M: each tool implements the protocol once, each model speaks it once, and they all interoperate.

So an MCP server is a small program that exposes a capability. One server reads your Postgres database. Another queries GitHub. Another posts to Slack. Your AI tool, the host, spins up a client for each server and calls it when it needs to reach that system. The keyword people search, mcp servers, usually means exactly these: the connectors that give an AI model hands in the outside world.

What an MCP server is not: it does not tell the model how to do your job well. It hands over the reach. The judgment lives somewhere else.

What a skill is (the instructions)

A skill is that judgment. It is procedural knowledge: a folder with a set of instructions that teaches the model how to perform one task the way you want it done. Certification report formatting, a code-review routine, a specific way to draft an outbound email. The good ones encode "here is how we do this thing around here" so the model stops improvising.

Here is the line that clears up half the confusion: a skill is instructions only. On its own it cannot fetch data, call an API, or reach an external service. It is a playbook, not a pair of hands. If a skill needs to touch your database, it leans on an MCP server to make the connection while the skill supplies the method.

That is why "skills vs MCP servers" is the wrong framing. One is the how, the other is the reach. You usually want both.

Skills are also the layer where quality swings wildest, because anyone can write a folder of instructions and call it production ready. Some are sharp. Plenty are a confident README sitting on top of a method that falls apart on the second run. That gap is the whole reason a certified skill catalog exists.

What a plugin is (the bundle)

A plugin is a container. It packages several of the pieces above, skills, MCP server configs, slash commands, subagents, hooks, into a single installable unit. Instead of adding a skill here, wiring an MCP server there, and copying in three commands, you install one plugin and get the whole set.

So a plugin is not an alternative to a skill or an MCP server. It is a level up from both: a way to ship and share a working bundle at once. When people compare "claude code plugins vs skills," they are comparing a moving box to the furniture inside it. The box holds the furniture.

This is also where "claude code marketplace" and "claude code plugin marketplace" come in. Those are the storefronts where plugins get listed and installed. Which raises the question every comparison table on this topic skips.

The part the comparison tables leave out: where did yours come from?

Every explainer walks you through connection, instruction, box, then stops. Nobody asks the next question, which is the one that bites you later: who wrote the thing you are about to install, and did anyone check it before it reached you?

It matters more here than in normal software, because these three layers all run with access. An MCP server can hold credentials and reach your systems. A skill can carry instructions that get followed. A plugin can bundle both and install them in one click, which means one click can bring in a lot you never read. In June 2026, attackers took over a maintainer account for a popular AI-agent framework on npm and republished more than 140 packages laced with a credential stealer, in under 20 minutes. The install step is exactly where trust gets skipped.

Most catalogs check none of this and let you assume all of it. "It installed" gets treated as "it works," and "it works" gets treated as "someone vetted it." Three different claims, and the marketplace quietly collapses them into one.

This is the layer ClearPoint Nexus is built on. Every skill in the catalog clears 96 certification checks across structure, platform fit, and quality, plus a separate 7-dimension security scan that blocks anything with a serious finding before it lists. You can read what each certification layer checks rather than take our word for it. Skills are certified across all four platforms people build on, Claude Code, Codex, OpenClaw, and Google Antigravity, because a skill that only runs in a demo is not a skill. There are 200-plus certified skills today, and new ones land every month. Certified agents are coming; for now the catalog that exists is the point.

We tell you exactly what we checked, and we stand behind every skill in the catalog. That is a promise we can keep.

Common mix-ups, cleared up

"Do I use a skill or an MCP server?" Usually both. The MCP server gives the model reach into a system; the skill gives it the method for the task. They complement, they do not compete.

"Is a plugin just a fancy skill?" No. A plugin can contain skills, plus MCP configs, commands, and more. Fancy box, not fancy furniture.

"Are MCP servers a security risk?" They can be, because they run with real access to your systems. That is an argument for installing connectors and skills you can trace to a source that checked them, not an argument for avoiding the whole ecosystem. Provenance is the fix, not fear.

"If I have skills, do I still need MCP?" Yes, the moment your task needs to touch anything outside the model. Skills supply the how; MCP supplies the reach. Our install guides walk through wiring both.

The takeaway

• An MCP server is a connection to an outside system. It gives the model reach.
• A skill is an instruction set for one task. It gives the model method, and it cannot reach anything on its own.
• A plugin is a bundle that ships skills, MCP configs, and commands together in one install.

They are three layers, not three competitors, and most workflows want all three. The one question the explainers skip is the one worth asking before you click install: who checked this, and can you see what they checked?

Start with skills someone already vetted. Browse the certified skill catalog and see what clears the bar before it ships.

Sources

• Model Context Protocol, "What is the Model Context Protocol," modelcontextprotocol.io, accessed July 2026. Anthropic, "Introducing the Model Context Protocol," anthropic.com, November 2024.
• Skills as instructions-only, and the skills / MCP / plugins layering: vendor and practitioner documentation, 2026.
• npm maintainer-account takeover and package republishing, June 2026: OX Security and StepSecurity incident write-ups.