← articles
Claude CodeSkillsMCPSubagentsAI Agents

Claude Skills vs MCP vs Subagents: When to Use Each

A decision framework for choosing between Claude Code skills, MCP tools, subagents, and memory: comparison table and choose-this-when breakdown per option.

Mixing up these four primitives does not break anything visibly. It just makes the architecture quietly worse every time you touch it.

Skills, MCP servers, subagents, and CLAUDE.md all look like “ways to give Claude more.” They are not interchangeable. Each one plugs a specific gap, and the overlap is shallow.

If you are new to Claude Code skills, the guide to building Claude Code skills covers SKILL.md, references, and progressive disclosure in full. Start there, then come back.

This article is the decision map: which primitive for which problem, when to combine them, and a checklist for each.

Four primitives, four jobs

Claude Code has four primitives: a skill (versioned method, no runtime), an MCP server (protocol exposing tools and live data), a subagent (isolated context for parallelism or clean state), and CLAUDE.md memory (always-on background context). Each solves a distinct problem. Using the wrong one is silent: nothing breaks, the architecture just gets worse.

Four primitives, one job each

Each primitive has one job. The common mistake is treating them as interchangeable.
DimensionSkillMCP ToolSubagentMemory
What it isVersioned method in SKILL.md + referencesServer exposing tools/data at runtimeIsolated context (fork/agent frontmatter)Always-on context (CLAUDE.md)
Has runtime?NoYesYesNo
Triggered how?Model reads SKILL.md on invocationAgent calls tool via protocolSpawned by orchestrator with frontmatterAlways in context, no trigger
Persists sessions?Yes (versioned file)Yes (server stays up)No (ephemeral worker)Yes (CLAUDE.md file)
Best forRepeatable method, consistencyTool/data access, live systemsIsolation, parallelism, long tasksAlways-on project/user context
Each primitive has one job. The common mistake is treating them as interchangeable.

The four primitives do not compete. They operate at different layers. A skill is not a lightweight MCP. A subagent is not a skill with more isolation. CLAUDE.md is not a skill you forgot to trigger. Combining them correctly is what makes a real production workflow.

MCP is the kitchen; a skill is the recipe

MCP exposes capability. It is the set of knives, pots, and raw ingredients your agent can reach for. A skill is what the agent does with them: a repeatable method with a standard of output. You can have a kitchen without a recipe (inconsistent results) or a recipe without a kitchen (elegant intentions, nothing cooked).

The analogy breaks if you push it. Some workflows need MCP with no skill: a one-off query against a live database does not need a method behind it. Some need a skill with no MCP: a pure reasoning or judgment task that only touches built-in tools. Combine them when the task is both structured and tool-dependent.

When a skill is the right tool

A skill belongs on the stack when you have a method worth repeating. Not a one-off query you can type inline. A judgment pattern that recurs, a framework you worked out once and do not want to reconstruct each session. Skills are for consistency. If you are copy-pasting the same long prompt, you are already building a skill; you just have not formalized it.

The tell is recurrence. I run an offer-evaluation skill backed by 13 Hormozi references. Every evaluation runs the same framework, checks the same criteria, and produces the same standard. I do not rewrite that each session. The skill is versioned in git, loads consistently, and has improved with each iteration.

I also run a full lifeos-* skill system: lifeos-capture, lifeos-ingest, lifeos-study, lifeos-plan, lifeos-review. Each is its own module with its own references and decision rules. None of these are prompts I repeat. They are methods I maintain.

Skill is not the right choice when:

  • The task is a genuine one-off with no recurrence
  • What you need is a tool call, not a method (MCP’s job)
  • The task needs isolated context or parallelism (subagent’s job)
  • You are trying to give the agent ambient background facts (CLAUDE.md’s job)

When MCP is the right tool

MCP belongs on the stack when the agent needs to do something it cannot do with built-in tools: write to a filesystem, query a live database, run browser automation, call an external API. It is not for judgment or method. It is for access. Most real workflows layer both: the skill tells the agent what to do; MCP makes the action possible.

Build a skill when...

  1. 01The same judgment or method recurs and needs consistency
  2. 02You have a framework to distill, not just a tool to call
  3. 03You want the same output standard applied every session
  4. 04Copy-pasting the same long prompt is already your current workflow
  5. 05You are encoding a decision process, not adding a capability

Build an MCP server when...

  1. 01The agent needs access to a live system, API, or database
  2. 02The task requires writing, reading, or executing something external
  3. 03You need browser control, filesystem ops, or real-time data
  4. 04Built-in tools fall short and the gap is capability, not method
  5. 05You want to share one tool across multiple skills or agents
Most confusion between skills and MCP is conflating method with capability.

The failure mode for MCP is reaching for it when you actually need a skill. If the agent’s results are inconsistent across sessions but it has access to the right tools, the problem is a missing method, not a missing server.

The failure mode for a skill without MCP is writing a method that instructs the agent to call tools it does not have. A skill can instruct the agent to use its existing built-in tools, but it cannot conjure new capabilities. If the method requires live data or external action, MCP is the missing layer.

When a subagent is the right tool

A subagent is an isolated Claude context. Use it when a task is too long for the main session, when you need clean state without context bleed, or when you can run multiple tasks in parallel. It is an execution boundary, not a reasoning upgrade. The skill still tells it how to reason; the subagent just runs it in a separate window.

Long tasks. A task that risks consuming the main context window (deep research, multi-step analysis, large refactors) belongs in a subagent. The orchestrator spawns it, it runs to completion, the result comes back clean.

Clean state. If a task should not be influenced by what happened earlier in the session, spawn a subagent. The previous context does not bleed in.

Parallelism. Running the same method on five inputs? Five subagents, one per input, all at once. Each gets the same skill loaded, each runs in its own context. I use this in the lifeos-study workflow: multiple documents, parallel ingestion, no cross-contamination.

A subagent is not a different reasoning engine. It is the same model in a separate context. The skill defines the reasoning quality; the subagent defines the execution boundary.

Pick your primitive

Run this top to bottom. First match wins.

Which primitive?

  • Required:
    Is this a repeatable judgment or method you want consistent across sessions?Yes → skill. Build SKILL.md + references + a loading map.
  • Required:
    Does the task require access to a live system, API, database, or external capability?Yes → MCP server. Add a skill on top if it also needs a repeatable method.
  • Required:
    Does the task need clean state, or would context bleed from the main session cause problems?Yes → subagent. Load a skill inside it if the method should be consistent.
  • Required:
    Is this something always true about the project or user: background facts, not a triggered method?Yes → CLAUDE.md memory. This is ambient context, not a task primitive.
  • Required:
    Are you running the same method on multiple inputs and want to parallelize?Yes → skill inside a subagent, one subagent per input.
  • Optional:
    Is this a genuine one-off with no recurrence, no external tool needed, no isolation?Yes → plain prompt inline. No infrastructure required.
Three yes's in one task? Combine them. The primitives are designed to layer.

FAQ

What is the difference between a Claude skill and an MCP tool?

A skill is a versioned method (SKILL.md plus reference files) that the model reads when invoked. It has no runtime and calls no external systems on its own. An MCP tool is a server that exposes real capabilities: database reads, API calls, browser actions, filesystem writes.

Short version: a skill tells the agent how to think; an MCP tool gives it something to do.

Can a skill and an MCP server work together?

Yes, and that combination is common. The skill defines the method: what to check, in what order, with what standards. The MCP server provides the capability the skill needs to act on.

My lifeos-capture skill encodes the capture method in SKILL.md; the MCP server is what actually writes structured output to the filesystem. The skill without MCP gives you instructions; MCP without the skill gives you inconsistent execution.

When should I use a subagent instead of running in the main session?

Use a subagent when the task is long enough to pollute the main context, when you need clean state with no bleed from prior turns, or when you are running the same task on multiple inputs and want to parallelize.

A subagent is an execution boundary, not a reasoning upgrade. The skill still defines the method inside it.

Is CLAUDE.md memory the same as a skill?

No. Memory (CLAUDE.md) is always-on background context: what is permanently true about the project or the user. It is never triggered by a specific task.

A skill activates when relevant: specific instructions, references to load, an output standard to follow. One is always on; the other fires on demand.

Do I need a skill inside a subagent, or can the subagent run without one?

A subagent can run with a plain prompt or from memory alone. The skill is relevant when the subagent's task follows a repeatable method you want consistent across every run.

If you find yourself rewriting the subagent's instructions every time, that is the signal to extract a skill.

What is the minimum reason to build a skill instead of a long prompt?

Recurrence. If you will run the same type of task more than once, a skill pays for itself. A prompt decays: it gets paraphrased, trimmed, and forgotten across sessions. A skill is versioned in git, loads the same references every time, and improves with each iteration.

The setup cost is real but bounded: one to three hours to build a proper SKILL.md and a handful of references. Everything after that runs on the infrastructure you built once.

What is progressive disclosure in the context of skills?

Anthropic's term for the three-layer loading pattern built into skills: the skill name and description always sit in context (metadata), the SKILL.md body loads when the skill is invoked, and the reference files under references/ load only when the model is explicitly routed to them.

This keeps the context window tight. The loading map in SKILL.md is what tells the model which references to reach for. Without it, the agent guesses, and guessing favors the weights over your files.

These compose

The four primitives do not compete, but they do combine. A skill inside a subagent backed by MCP-exposed tools is a standard production pattern, and it is cleaner than it sounds once each layer knows its job.

The guide to building Claude Code skills covers the skill layer from the ground up. If you are still deciding between a skill and a simpler option (a prompt, a note in CLAUDE.md), Claude skill vs prompt vs memory covers that boundary. For concrete examples from a real skill library, Claude skill examples in production is the follow-up.

Pick the primitive that matches the actual problem. The rest is wiring.