MCP servers, skills, and plugins are three different layers

People use "skill," "plugin," and "MCP server" as if they were three words for the same download. They are not. Each fixes a different deficiency, and each fails in a different way. If you install the wrong layer, the agent will look busier without becoming more capable.

This guide separates the three. It is not a buyer's guide to any particular package; the directory has thousands of those. It is a way to name what you are missing before you go looking for it.

A skill is a procedure

A skill is a folder of instructions, usually a short manifest plus a longer instruction file, that the agent loads when a request matches its description. In the Claude-style packaging, the file is SKILL.md, with a name and a description in its frontmatter. The description is what the agent matches against, so it has to say both what the skill does and when to use it.

The loading is staged. The name and description sit in context from the start, at roughly a hundred tokens each. The instruction body is read only after the skill triggers, and bundled reference files or scripts are read only when the instructions call for them. That design is why you can keep twenty skills installed without paying for twenty instruction files on every request.

What a skill adds is a procedure and a vocabulary: which steps to run, in what order, what to check, and what to refuse. It does not add a capability the model lacked. "Run the migration on a copy, compare row counts, then report the diff" is a skill. "Be a senior engineer" is not, because nothing in it can be checked.

An MCP server is reach

The Model Context Protocol is a standard way for an AI application to talk to an outside program. The application is the host; it runs a client that connects to a server. The server exposes three things: tools, which are functions the model can call; resources, which are data the application can read; and prompts, which are reusable templates. The messages are JSON-RPC, and a session begins with a capability negotiation.

The point is reach, not procedure. An MCP server lets the agent list the tables in a database, open a browser, search a ticket system, or read a file share. Before MCP, each of those connections was a bespoke integration inside the host. After MCP, the host implements the protocol once and any server can plug in.

Reach is also risk. Tools are arbitrary code, and a tool description is written by the server, not by your vendor. The specification says tool behavior and annotations should be treated as untrusted unless the server is trusted, and hosts should get explicit user consent before invoking a tool. Authorization is optional at the protocol level, which means scopes and credentials are still your job. The prompt injection guide covers what can go wrong when a server's output is treated as an instruction.

A plugin is a host-specific bundle

A plugin is the layer that belongs to one application. For DeepSeek Harness it is a package that changes how that host behaves or what it can reach: a panel in the interface, a different model route, memory across sessions, a browser tool. Under the hood a plugin may contain skills, an MCP client configuration, code that calls a model, or all three.

That convenience is why plugins are the most fragile layer. They are tied to the host's internals, so a host upgrade can break them. They can run code at install time. They can request credentials. A skill can waste your afternoon; a plugin can act with your permissions. Read the repository, the release history, and the permissions before you install one, as the plugin check guide describes.

How the three fit together

A useful way to hold the layers apart:

They compose. A plugin can ship an MCP server so the host can reach a service. A skill can teach the agent when to call that server's tools and how to check the result. The server provides the reach, the skill provides the discipline, and the plugin makes both available in one install. None of them substitutes for the others.

The composition is also where people over-buy. If the agent already has a shell and a file system, a skill that says "use rg before cat" may solve the problem without any new server. If the agent cannot see the ticket system at all, no amount of prompt writing will fix it; you need the server. Diagnose the missing layer first.

What to check before installing each

For a skill, read the instruction file. You are looking for a trigger you can state, a procedure with an end, and a refusal. If the prompt tells the agent to ignore other instructions, hide its steps, or continue after an error, stop. The audit guide is the longer checklist, and how to write your own is the version for authors.

For an MCP server, list its tools before you connect it to real work. Ask what each tool can read, write, and send over the network. Check whether the server runs locally or remotely, whether it holds a token, and whether the host asks you before destructive calls. Prefer a server whose source you can inspect and whose version you can pin.

For a plugin, read the repository and the install script. Check whether it needs a credential, whether it writes outside its own folder, and whether it has releases rather than a single upload. Test it on a scratch project before you point it at a repository you care about.

A decision rule

Ask what the failure looks like:

• The agent knows the steps but performs them inconsistently: you need a skill.
• The agent cannot see or act on the system at all: you need an MCP server or a tool.
• The agent needs the capability inside one host, with UI or configuration: you need a plugin.

If two answers seem true, start with the smallest layer that removes the failure. A skill is easier to remove than a server; a server is easier to audit than a plugin. Install one layer, run one real task, and check the result before adding the next. The checklist before you install is the short version of that discipline.