Claude Skills vs MCP vs Subagents: What Each One Actually Does

Three Names for Three Different Problems

If you've built anything with Claude in the last few months, you've run into all three terms in the same breath: Skills, MCP, and subagents. Most explanations treat them as competing options, "should I use a Skill or MCP for this?", as if you pick one and move on. That framing is wrong, and it's wrong in a way that costs people real engineering time, because the three solve genuinely different problems and a serious agent setup usually needs all of them at once.

The cleanest way to hold the distinction: Skills are knowledge, MCP is action, subagents are isolation. One tells the model how to do something. One lets the model actually go do it in the outside world. One decides who's doing the work and keeps that work from polluting everything else. Knowing which lever you're pulling is the difference between an agent setup that scales past a demo and one that quietly falls over at 40 tools and a bloated context window, the same failure mode we covered in why AI agents get dumber the longer they run.

What a Skill Actually Is

A Skill is a folder. At minimum it contains a `SKILL.md` file with a name and a description, and optionally bundled scripts, templates, or reference material. That's the entire mechanism, there's no special runtime, no API call, no server process, just a directory Claude reads.

What makes Skills work at scale is how they load, not what they contain. Anthropic's official announcement describes three stages: discovery, where the agent only holds the skill's short name and description in context, cheap enough to keep hundreds of skills on standby; activation, where the moment a task matches a skill's description, the full `SKILL.md` body gets read into context; and execution, where the agent follows those instructions and optionally runs the bundled code. You can have fifty skills installed and the model is only ever "paying" context-window rent for the two-sentence descriptions of the forty-nine it isn't using right now.

The part that matters for anyone evaluating this seriously: Skills shipped as an open, cross-platform standard, not a Claude-only feature. Anthropic published the spec and reference implementation at github.com/anthropics/skills, and the broader standard lives at github.com/agentskills/agentskills and agentskills.io, with adoption already spanning OpenAI Codex, Gemini CLI, GitHub Copilot, Cursor, and over 20 other platforms. A skill you write once works the same way regardless of which model reads it.

What MCP Actually Is

The Model Context Protocol solves a completely different problem: how does a model reach a live system it doesn't already know about, your database, your calendar, a running API, instead of a static instruction file. MCP is a client-server protocol built on JSON-RPC, where a host application (Claude Desktop, Claude Code, an IDE) runs an MCP client that connects to one or more MCP servers, each exposing tools (callable functions), resources (readable data), and prompts (reusable templates). We walked through the full request/response mechanics in what is MCP and how AI agents actually use it, including where the trust model breaks down when you connect an untrusted server.

MCP is also fully open source, hosted by the Linux Foundation rather than run as an Anthropic-only project, with SDKs in Python, TypeScript, C#, and Kotlin at github.com/modelcontextprotocol and the full spec at modelcontextprotocol.io. If your task involves the words "query," "fetch," or "current state," you need a live connection, which means MCP, not a skill, no static folder can tell an agent today's inventory count or this week's calendar availability.

What a Subagent Actually Is

Subagents solve neither knowledge nor action, they solve contamination. A subagent is a separately configured instance, its own system prompt, its own restricted tool permissions, and critically its own context window, invoked by a parent agent to handle one bounded piece of work. According to Claude Code's official subagent documentation, subagents are stored as Markdown files with YAML frontmatter, either project-level in `.claude/agents/` or user-level in `~/.claude/agents/`, and each one can be scoped to exactly the tools it needs and nothing else.

The reason this matters mechanically: every tool result, every file you read, every intermediate reasoning step accumulates in a single context window unless something isolates it. A research task that reads twenty files and produces one paragraph of useful signal will otherwise leave all twenty files' worth of noise sitting in your main conversation. A subagent runs that research in its own window and hands back only the distilled result, so the parent conversation stays clean regardless of how much exploration happened underneath it.

How the Three Compose

None of these replace each other, they stack. A skill can describe a multi-step procedure whose steps call MCP tools. A subagent can be handed a skill for domain conventions and a scoped MCP server for live data, then dispatched to do isolated work and report back. The pattern that's actually paying off for teams in 2026: a lightweight subagent, running on a cheaper model where the task allows it, preloaded with one relevant skill and one narrowly scoped MCP server, rather than one giant agent holding every tool and every instruction at once.

If you're automating a real workflow, say, an agent that triages support tickets, that same three-layer split shows up again in practice: a skill for your refund policy and tone, an MCP server for your live ticketing system, and a subagent boundary so ticket research doesn't bloat the main triage loop. That's the same architecture we build out step by step inside n8n's MCP Server Trigger: how to turn any workflow into a tool Claude can call.

Where to Start

Don't reach for all three on day one. Start with the actual bottleneck: if Claude keeps getting your process wrong because it doesn't know your conventions, write a skill, it costs one Markdown file. If Claude can't see something real, inventory, a calendar, a ticket queue, you need MCP, no amount of instructions substitutes for a live connection. If your context window is filling up with exploration noise from a task that should produce one clean answer, wrap it in a subagent. Each layer is genuinely free to adopt, open-source, and now cross-platform, so there's no lock-in cost to trying the smallest version first and adding the next layer only once you've actually hit its specific failure mode. Building the full stack, skills for judgment, MCP for live systems, subagents for isolation, is exactly the kind of applied agent architecture we go deep on inside AI Product Development Bootcamp.