Skills, Plugins, and MCP Servers: Which One Should You Build?

What each one actually is

A skill is a packaged set of instructions for a recurring task, loaded when that task comes up. Your deployment procedure, your code review checklist, the house conventions for writing migrations. The defining property is timing: it is not in the context window until it is relevant, so it costs nothing on the other ninety percent of turns.

An MCP server exposes capabilities through the Model Context Protocol: tools the agent can call, and resources it can read. Its job is access. Your ticket system, your database, your internal deployment API. Write one when the agent cannot otherwise reach the thing.

A plugin is packaging. It bundles skills, commands, hooks, and MCP server configuration so someone else can install the whole set in one step. The question it answers is distribution, not capability.

The confusion in most tutorials comes from treating these as three flavors of the same idea. They are three different layers: knowledge, access, and distribution.

The decision rule

Ask what is actually missing when the agent fails at the task.

It does not know how you do this. It produced technically correct work that violates your conventions, skipped a step your team always performs, or used the wrong pattern. That is missing procedural knowledge. Write a skill.

It cannot reach the system. It needs the current state of a ticket, a row from a production database, a deploy to be triggered. No amount of instruction fixes this. Write an MCP server, or use an existing one.

It needs facts it does not have. It needs to know what the retry policy is, why a service was split, what the schema means. That is knowledge, and it usually already exists in your docs, your code, or your notes. Do not write anything. Index it and let the agent retrieve it.

Other people need what you built. Package it as a plugin.

That third case is the one most often solved wrongly. Teams build an MCP server that wraps a documentation folder, effectively turning their docs into a tool call. It works, but it means the agent has to know to call the tool and know what to ask, and it burns a tool schema on every request forever.

The hidden cost: everything in the system prompt is bought on every request

This is the part that decides architecture once you are past a handful of extensions.

Every MCP server you connect registers its tools, and every tool schema is sent with every request for the entire session. Connect five servers exposing eight tools each and a meaningful fraction of your window is gone before the user has said anything. It also degrades tool selection, because the model is now choosing among forty options, many of which look similar.

Skills avoid this by loading on demand. Only the trigger description is standing cost, and the body is loaded when it applies. That is the entire reason to prefer a skill over stuffing the same content into a system prompt.

Retrieved knowledge avoids it even more thoroughly. Nothing is standing cost, the agent fetches passages when a query matches, and updating the knowledge means editing a file rather than shipping a new version of a server. RDK indexes files from local vaults, docs, and code as encrypted private chunks the agent searches before it queries a model, cutting token spend 80 to 90 percent because the answer is retrieved instead of regenerated.

Writing a skill that actually gets used

Two failure modes account for most dead skills.

The first is a vague trigger. The agent decides whether to load a skill based on its description, so "helps with deployments" loads unpredictably while "use when deploying to staging or production, or when editing the release workflow" loads when it should. Write the description as a condition, not a summary.

The second is including knowledge that should be retrieved. A skill that embeds the current service list, environment names, and config values goes stale silently and confidently. Keep skills procedural, the steps and the judgment calls, and let the volatile facts come from the index or from the code itself.

Good skills read like a runbook written by someone who has done the task fifty times: the order of operations, the checks that matter, the mistakes that look tempting, and the point at which to stop and ask a human.