Every week someone asks the same question in a slightly different costume: should I build a Skill or an MCP server for this? Do I need subagents or a Skill? The framing is wrong, and it's worth fixing once, because it decides how you architect everything downstream.

Skills, MCP, and subagents are not three answers to one question. They are answers to three different questions:

Get that straight and the "vs" dissolves. You will usually want more than one.

The one-screen version#

MCP connects. The Skill supplies the method. The subagent executes. If you can name which of those three a given problem is, you've picked your tool.

A quick gut check: if you keep re-typing the same instructions, that's a Skill. If the agent can't get at the data, that's MCP. If one task is drowning your main context or needs to run in parallel, that's a subagent.

Agent Skills: procedural knowledge, made cheap#

A Skill is a directory containing a SKILL.md file — YAML frontmatter plus a Markdown body — and, optionally, bundled scripts and reference files. Claude loads it automatically when a request matches. The whole design is built around progressive disclosure, which is the part founders underrate:

That's why Simon Willison called Skills "maybe a bigger deal than MCP": a library of 50 skills stays light, while a fat MCP server can spend tens of thousands of tokens at startup just describing tools you may never call.

Here's a minimal, real-shaped one:

---
name: quarterly-report
description: Generates our standard quarterly revenue report. Use when the
  user asks for a QBR deck, quarterly report, or revenue summary by segment.
---

# Quarterly Report

## Instructions
1. Pull revenue for the requested quarter (ask if it isn't specified).
2. Break it down by segment: Enterprise, Mid-Market, Self-Serve.
3. Compute QoQ % change against the prior quarter.
4. Output a table, then a 3-sentence summary of the largest mover.

## Style
- Round currency to the nearest thousand.
- Bold any segment down more than 10% QoQ.

The two required frontmatter fields are name (≤64 chars) and description (≤1024). Spend your effort on the description: it must say what the skill does and when to use it, because that sentence is what the model matches against. A vague description is a skill that never fires.

MCP: the reach, not the recipe#

MCP is the wrong tool for "teach the agent our release process" and the right tool for "the agent needs to read our Postgres and open a GitHub PR." It's a connection layer. The distinction that ends most of the confusion: MCP gives the agent the ability to touch GitHub; a Skill tells it how your team wants a release cut. One is capability, the other is procedure. You will frequently pair them — the Skill's instructions call the MCP server's tools.

Subagents: context isolation and parallelism#

Reach for a subagent when the who matters: a task needs a narrowed tool set, its own system prompt, or a separate context so it doesn't pollute your main thread — or when you want several things happening at once. A market-researcher gathering sources while a technical-analyst reads the repo, each in its own window, returning just their findings, is the canonical shape. Subagents are about where the work runs, not what it knows or what it can reach.

The production answer: all three#

The mistake is treating this as a bracket to win. Anthropic's own guidance is that Skills, MCP, and subagents are composable and the sweet spot is usually a combination. A realistic stack for a real workflow:

  1. MCP connects the agent to your data room and your repo.
  2. A Skill encodes the exact procedure your team follows, loaded on demand for ~100 tokens until it's needed.
  3. A subagent runs that procedure in an isolated context and hands back only the result.

Pick the tool by the question you're actually asking. If you're still deciding between agent frameworks underneath all this, we mapped that in Claude Agent SDK vs LangGraph; and if you want the hands-on version of authoring one of these, see how to turn a repeated prompt into an Agent Skill.