Agent Skills vs MCP servers

They get compared constantly, usually as if you have to pick one. You don’t — they solve different halves of the same problem. The short version: an MCP server gives your agent somewhere new to reach; a skill gives it knowledge about work it can already do.

What each one actually is

An Agent Skill

A folder containing a SKILL.md file — YAML frontmatter with a name and a one-line description, then markdown instructions. Optionally some reference documents and scripts beside it. There is no process, no port, no configuration, no authentication. The agent reads the description, decides the skill is relevant, and pulls the instructions into context.

It is closer to onboarding documentation than to software. “When you generate a report, here is our house format, here is the template, here is the script that fills it.”

An MCP server

A running program that speaks the Model Context Protocol, exposing tools, resources and prompts over stdio or HTTP. The agent calls it and gets back live data — or causes an effect in a real system. It can hold credentials, maintain a session, query a database, hit a private API.

It is software, and it has software’s properties: it needs to be installed, configured and kept running, and it can fail in ways a markdown file cannot.

Side by side

	Agent Skill	MCP server
What it adds	Procedural knowledge — how to do something well	Capability — access to a system it could not otherwise touch
Form	A folder of markdown (+ optional scripts)	A running process speaking a protocol
Install	Copy a folder into a skills directory	Add an entry to a config file, then run the server
Context cost	One description line until invoked, then loaded on demand	Tool definitions occupy context for the whole session
Live data	No — it is static text	Yes, that is the point
Auth and secrets	None to manage	Usually needs credentials
Fails by	Being ignored, or giving stale advice	Crashing, timing out, or losing its connection
Versioning	Whatever the folder says today	Server version plus protocol version

The difference that bites people

The row worth staring at is context cost. Every MCP server you connect advertises its tools up front — names, descriptions, parameter schemas — and that sits in the context window for the entire session whether you use the tools or not. Connect six chatty servers and a meaningful slice of the window is gone before you type anything.

Skills are the opposite shape. Only the one-line description of each skill is visible by default; the body is read when the agent decides the skill applies. You can have fifty installed and pay almost nothing for the forty-nine you did not need. This is why teams who started by wiring up every MCP server they could find often end up moving the “how” into skills and keeping servers for the things that genuinely need a live connection.

Choosing between them

Reach for a skill when the capability is knowledge:

Your team’s conventions — commit format, review checklist, house style
A multi-step procedure the agent gets subtly wrong on its own
Working with a file format, complete with a helper script it can run
Anything you would otherwise paste into the prompt every single time

Reach for an MCP server when the capability requires a connection:

Reading from a database, ticket tracker or internal API
Anything behind authentication
Data that must be current — not what was true when someone wrote the markdown
Actions with side effects in a running system

A useful test: if you could write the capability down and hand it to a new colleague on paper, it is a skill. If they would need a login, it is a server.

They work better together

The interesting setups use both, with the skill acting as the operator manual for the servers. An incident-response skill might say: query the metrics server for the last hour, cross-reference the deploy log, open a ticket in this format, and post the summary in this shape. The servers provide reach; the skill supplies the judgment about what order to do things in and what “good” looks like.

Without the skill, the agent has the tools and no procedure. Without the servers, the procedure has nothing to act on.

Which to add first

Start with skills. They are reversible — delete a folder and it is gone — they cost nothing to keep around, and they need no configuration. Most of the disappointment people report with agents is a knowledge problem, not an access problem: the model could have done the task but did not know your conventions. Add servers when you hit an actual wall, which is usually the moment you need data the agent cannot see.

Installing each of them

Skills are a folder copy — see how to install skills in Claude Code for every method, or the universal directory if you use more than one agent. MCP servers are a config-file edit: an entry naming the command that starts the server, in .mcp.json, claude_desktop_config.json or the equivalent for your client.

{
  "mcpServers": {
    "example": {
      "command": "npx",
      "args": ["-y", "@example/mcp-server"]
    }
  }
}

That structural difference — a directory write versus a config merge — is also why Skill Installer handles skills today and treats MCP as a separate piece of work rather than a quick addition. Installing a skill means writing a folder. Installing an MCP server means editing a file you did not write, without breaking the entries already in it.