Claude Code Skills vs Subagents vs MCP Servers: Which One Do You Need?

You've been using Claude Code for a few weeks. It's fast, it's capable, and now you keep hitting the same wall: you re-explain your deploy checklist every session, your context window fills up with a 40-file refactor before you're halfway done, and you wish Claude could just query your Postgres database instead of you copy-pasting query results into the chat.

All three of those problems have a fix — but they're three different fixes. Claude Code gives you skills, subagents, and MCP servers, and picking the wrong one wastes time (and tokens) solving a problem you don't have. This guide gives you a decision framework you can apply in under a minute, plus working examples of each.

The One-Question Test

Before touching any config file, ask yourself: am I short on knowledge, context, or capability?

• Short on knowledge — Claude doesn't know how your team does something (your commit message format, your migration checklist, your review rubric) → build a skill.
• Short on context — the task itself is big enough that doing it inline would flood your context window with intermediate noise (reading 200 files to find 3 relevant ones, running a long test suite and parsing the output) → delegate to a subagent.
• Short on capability — Claude literally cannot do the thing because it has no tool for it (query your live database, open a PR, read your Sentry dashboard) → connect an MCP server.

These aren't competing options. They're answers to different questions, and most real Claude Code setups end up using all three together.

Skills: Teaching Claude How You Work

A skill is a folder with a SKILL.md file describing a procedure, plus optional supporting scripts or reference docs. Claude reads the skill's one-line description at session start and decides on its own when to load the full instructions — you don't have to invoke it by name (though you can, with /skill-name).

Skills are the right tool when:

• The same workflow repeats across many sessions (code review checklist, PR template, release process)
• The procedure is mostly instructions, not a separate reasoning context
• You want the behavior to activate automatically based on what the user asks, not on an explicit command

Minimal skill example

markdown---
name: db-migration-checklist
description: Use when creating or reviewing a database migration file. Enforces backward-compatible migration rules for this repo.
---

# Database Migration Checklist

Before writing a migration:
1. Never DROP a column in the same migration that stops writing to it — split into two deploys.
2. All new NOT NULL columns need a DEFAULT or a backfill step.
3. Add the migration file to `db/migrations/` with a zero-padded sequence number.
4. Run `npm run migrate:dry-run` and paste the output in the PR description.

Drop that in .claude/skills/db-migration-checklist/SKILL.md and Claude applies it any time a migration-shaped task comes up — no re-explaining required.

Subagents: Protecting Your Context Window

A subagent is a specialized Claude instance with its own context window, its own system prompt, and (optionally) a restricted tool set. It runs the task in isolation and returns only a summary to your main conversation — none of its intermediate exploration pollutes your context.

Subagents are the right tool when:

• The task requires reading, running, or generating a lot of intermediate material you don't need to see
• You want to parallelize independent work (three subagents auditing three different modules at once)
• You want to cap what a piece of work can touch (a subagent with Read-only tools can't accidentally edit files)

Minimal subagent example

Create .claude/agents/test-runner.md:

markdown---
name: test-runner
description: Runs the test suite, diagnoses failures, and reports a fix plan. Use proactively after any code change that touches src/.
tools: Bash, Read, Grep
---

You are a test-diagnosis specialist. Run the full test suite, identify
every failure, read only the files needed to explain root cause, and
return a concise list: file, line, cause, suggested fix. Do not edit
any files — only report.

Now instead of running npm test, watching 400 lines of output scroll past, and manually correlating failures to files inside your main session, you say "run the tests" and get back a five-line diagnosis. The 400 lines never touch your context.

MCP Servers: Giving Claude New Capabilities

The Model Context Protocol (MCP) is Anthropic's open standard for connecting Claude to external systems. An MCP server exposes tools, data resources, and prompts over a defined protocol — connect one and Claude Code can query a live database, open a GitHub PR, drive a browser, or call any internal API the server wraps.

MCP servers are the right tool when:

• Claude needs to act on a system outside your local files (a database, a SaaS API, a browser)
• You want that capability available across every session and project, not just one repo
• The capability involves live, changing state — not something you can just paste into a skill's instructions

Adding an MCP server

bashclaude mcp add postgres --scope project \
  -- npx -y @modelcontextprotocol/server-postgres "postgresql://localhost/mydb"

Once connected, Claude can run read queries against your schema directly, instead of you exporting rows and pasting them into chat. In 2026 most popular services — GitHub, Vercel, Linear, Notion, Stripe, Postgres — publish OAuth-secured remote MCP servers, so increasingly you're connecting a URL rather than running a local process.

Side-by-Side Comparison

Composing All Three

The pattern that actually holds up in production isn't picking one — it's stacking them. A common setup:

None of the three could do that alone. The skill has no way to touch the database. The MCP server has no opinion on query hygiene. And running it all in your main session would burn your context window on log output you don't need to see.

Common Mistakes to Avoid

• Building a subagent to "teach" Claude something. If the fix is a set of instructions with no need for isolation, that's a skill wearing a subagent's clothes — you're paying spin-up cost for nothing.
• Building a skill for something that needs live data. Skills are static instructions loaded at read time. If the "how" depends on current database state or an API response, you need an MCP server behind it, not a longer SKILL.md.
• Connecting an MCP server for a one-off task. If you need database access exactly once, a direct query and paste is faster than wiring up a persistent server. Reach for MCP when the capability is recurring.
• Giving a subagent every tool "just in case." Restricting a subagent's tools: list is a feature, not a limitation — it's what makes the isolation trustworthy for tasks like automated test runs or file audits.

Frequently Asked Questions

Yes. Subagents load skills the same way your main session does, based on the skill's description matching the task. A test-runner subagent can still pick up a "how we write test names" skill without you wiring anything extra — the isolation is about context and conversation history, not about which skills are visible.

Indirectly. A skill's instructions can tell Claude to use a specific MCP tool as part of the procedure (for example, "check the Postgres schema via the connected database server before writing a migration"). The skill itself doesn't grant the capability — the MCP server does — but the two compose naturally: the skill supplies the rule, the MCP server supplies the access.

No. Subagents pay off when the task generates a lot of intermediate noise you don't need in your main thread — logs, search results across dozens of files, long tool output. A large task that's mostly linear editing (rewrite this one file, refactor this one function) usually doesn't benefit from the isolation and just adds spin-up overhead.

For a one-off lookup, that's often faster than connecting a server. MCP earns its keep when the same external system needs querying repeatedly across sessions, or when the data changes too fast for a paste to stay accurate — a live database or ticket queue, not a static reference doc.

They shift the trust boundary rather than removing it. A remote, OAuth-secured MCP server means you're not running arbitrary code locally, but you're still granting Claude whatever scopes that OAuth token carries — read-only database access behaves very differently from a token with write and admin scopes. Review the permission scope before connecting either kind.

Skills. They require no new infrastructure — just a Markdown file — and they teach you how Claude decides what's "relevant" to a task, which is the same intuition you'll need later for scoping subagents and MCP tool permissions correctly.

Key Takeaways

• Ask "knowledge, context, or capability?" before reaching for any of the three.
• Skills teach Claude a repeatable procedure and cost context only when relevant.
• Subagents isolate noisy or large tasks in their own context window and report back a summary.
• MCP servers give Claude new capabilities against live external systems — increasingly as OAuth-secured remote endpoints in 2026.
• Production setups compose all three rather than picking a single winner.

Next Steps

If you're building your first custom skill, our step-by-step Claude Code skills tutorial walks through the full SKILL.md structure. Building your own MCP server instead? See our guide to building an MCP server with Claude.

Want to check how AI-fluent your current workflow actually is before you invest more time customizing Claude Code? Try the free AI Work Readiness diagnostic — it takes five minutes and tells you exactly where to focus next.