Agent Skills vs MCP vs Subagents: What's the Difference?

Three things keep showing up in agent conversations as if they were interchangeable: skills, MCP servers, and subagents. They're not. They operate at different layers, they cost different amounts, and picking the wrong one is why some agent setups feel sharp while others feel like you're arguing with a very willing, very confused intern.

Here's the short version before the long one:

• A skill is knowledge. A folder of markdown your agent reads to learn how to do something well.
• An MCP server is capability. A running service your agent connects to so it can do something — reach a database, call an API, drive a browser.
• A subagent is labor. A separate agent you hand a whole chunk of work to, so it happens somewhere other than your main conversation.

Same agent, three different questions: does it know how? can it reach what it needs? who does the work?

The three, one at a time

Skills: knowledge your agent loads on demand

A skill is a folder with one markdown file in it — SKILL.md — holding instructions the agent reads when a task matches. You might have a hundred installed. At startup the agent sees only each skill's name and description (that's progressive disclosure), and reads the full file only when the task calls for it.

What makes skills the lightest option: there is no process. Nothing starts, nothing listens, nothing authenticates. A skill is text. Its whole job is to change what the model does next — by giving it the workflow of someone who's done this before.

Skills are also the only one of the three that improves quality rather than adding reach. An MCP server can give your agent a terminal; it can't tell it that linear easing is wrong for motion a person sees, or which of three failure modes to check first. That judgment is what a skill encodes, and it's why I collect them in the agent skills hub.

Use a skill when the gap is "my agent doesn't know how to do this well."

MCP: a connection to the outside world

The Model Context Protocol is a standard way to plug external tools into an agent. An MCP server is a program — local or remote — that exposes tools (things to call), resources (things to read), and sometimes prompts. Your agent discovers what it offers and calls it like any other tool.

The classic examples: a Postgres server so the agent can query your database, a filesystem server, a GitHub server for issues and PRs, a browser server for the live web.

The difference from a skill is the difference between a manual and a machine. A skill tells the agent how to write a good migration; an MCP server gives it a database to run the migration against. One is instructions, the other is a live connection — with all that implies: credentials, permissions, a process that can fail, and a schema you have to keep honest.

Use MCP when the gap is "my agent can't reach the thing it needs" — a system, a dataset, a service that lives outside the model.

Subagents: a second agent with its own context

A subagent is what it sounds like: an agent spawned by your main agent to handle a chunk of work in its own context window, then report back. The orchestrator stays clean; the subagent's long reading, searching, and dead ends happen somewhere else, and its context is discarded when the task ends.

That's the real value — context hygiene. Have a subagent read forty files and summarize, and your main conversation keeps the two-paragraph summary instead of forty files' worth of noise. Most harnesses also let you scope a subagent's permissions separately: the research agent gets web access and no write access, the shell agent gets the terminal and nothing else.

Subagents are labor, and labor is the expensive one of the three: each is a full agent loop, potentially running in parallel with others. You reach for one when a task is large or dangerous or both — big research sweeps, isolated risky operations, parallel workstreams.

Use a subagent when the gap is "this work shouldn't happen in my main context — or under my main permissions."

Side by side

How to choose

Start from the gap, not the technology:

"My agent tries and produces mediocre work." It knows the destination but not the craft. → Skill. This is the most common gap and the cheapest to fix.

"My agent can't touch the system in question." It needs to query the warehouse, file the ticket, read the calendar. → MCP server.

"My agent keeps derailing — context fills up, it loses the thread, or it needs permissions I don't want it to have." → Subagent.

And notice the failure signature of each, because that's how you diagnose which one you're actually missing:

• The agent does the wrong thing repeatedly → missing skill (it never learned the workflow).
• The agent says it can't or doesn't have access → missing MCP (it has no reach).
• The agent starts fine and degrades — forgets earlier instructions, truncates, wanders → missing subagent (its context is overfull).

The realistic answer: you'll use all three

They compose, and the layered version is how good agent setups actually look:

Subagent (the worker)
├── has its own context window, scoped permissions
├── loads skills: how to do the work well
└── connected to MCP servers: what it can reach

A concrete version: a code-review subagent runs in its own context so the diff and its analysis don't crowd your conversation; it loads a review skill that encodes your team's standards; and it's connected to a GitHub MCP server so it can read PRs and post comments. Remove any one layer and a different thing breaks — no craft, no reach, no isolation.

The practical ordering if you're building this up: skills first (a folder, two minutes, no infrastructure), MCP when you hit a wall on reach, subagents when your context or your permissions demand it. Teams routinely skip the first step and buy the other two — which produces agents that can reach everything and know nothing about how you want the work done.

Further reading

• The agent skills hub — 90 indexed skills across eight categories, browsable on GitHub, if you want to see what "knowledge" looks like at scale.
• How to Write a SKILL.md — the anatomy of a real skill, if you're writing your own.
• What Is a Decision Model? — the layer below all three: how an agent decides which route, tool, or worker to pick in the first place.