Subagent vs MCP Server vs Skill: When to Build Each Claude Code Extension (2026)

Introduction #

By 2026, Claude Code has three distinct ways to extend it — skills, subagents, and MCP servers — and the single most common question we get is “which one do I build?” The confusion is understandable: all three are “ways to make Claude do more,” and the marketing blurs them together. But they sit on three completely different axes, and picking the wrong one means either over-engineering (a whole server for what a markdown file would do) or hitting a wall (a skill that can’t actually reach your database).

This article gives you a decision framework. We’ll define each extension point in one line, walk through the axis each one moves, run three real scenarios end to end, and call out the anti-patterns that waste a weekend. If you’ve already read Custom Agent Authoring and the MCP Servers 2026 rankings, this is the piece that ties them together.

The Three Extension Points, One Line Each #

• Skill — teaches Claude how to do something. Packaged instructions, a playbook, a checklist, loaded into context only when relevant.
• Subagent — who does it. A delegated worker with its own context window, spawned to keep the parent conversation lean (see the subagent patterns).
• MCP server — what it can reach. A connection to an external system: a database, an API, a SaaS tool, a data source.

Say it as a sentence and the confusion dissolves: a skill changes behavior, a subagent protects context, an MCP server adds capability. They are not three answers to one question. They are answers to three different questions.

The Axis Each One Moves #

Skills move the “knowledge” axis #

A skill is the answer to “Claude doesn’t know our specific procedure.” Your release process, your code-review rubric, your incident-response runbook — knowledge that’s situational. You don’t want it in CLAUDE.md (that loads on every interaction and bloats the base context); you want it loaded only when the task calls for it. A skill is a markdown file with a trigger description; when the work matches, the detailed instructions enter the conversation, and otherwise they stay out of the way.

Subagents move the “context” axis #

A subagent is the answer to “this work would blow up my context window.” The knowledge might already be there; the problem is that doing the work inline — reading 30 files, running a long exploration — would crowd out the reasoning you actually care about. A subagent runs it in a separate context and hands back only the conclusion. Nothing about capability changes; what changes is whose working memory pays for the exploration.

MCP servers move the “capability” axis #

An MCP server is the answer to “Claude literally cannot reach this system.” Your Postgres database, your internal metrics API, your Stripe account, your Linear board. No amount of skill-writing or subagent-spawning conjures a database connection — that’s a genuine new capability, and capabilities come from MCP servers. This is also the heaviest of the three: a separate process with deployment, authentication, and versioning to own.

A Decision Framework #

Ask these in order:

1. “Does Claude need to reach a system it currently can’t?” → MCP server. (Database, API, SaaS, external data.)
2. “Does Claude already have the capability, but the work would bloat my context?” → Subagent. (Big exploration, parallel research, isolated experiments.)
3. “Does Claude have the capability and the context, but doesn’t know our specific way of doing it?” → Skill. (Playbook, checklist, procedure.)

The cheapest option that solves your problem is almost always the right one. A markdown file (skill or subagent) beats a deployed service (MCP server) whenever it can do the job.

Worked Scenario 1: “Audit our codebase for SQL injection” #

• Capability? Reading code — Claude already has it. No MCP server needed.
• Context? Auditing the whole codebase means reading dozens of files. That would bloat the parent. → Subagent.
• Procedure? You want the audit to follow OWASP’s specific checklist. → Skill (or bake the checklist into a security-auditor custom agent’s system prompt).

Answer: a security-auditor subagent whose system prompt encodes the checklist. One artifact, two axes covered. No server.

Worked Scenario 2: “Show me which customers churned last month” #

• Capability? That data lives in your warehouse. Claude can’t reach it. → MCP server (a warehouse/SQL MCP).
• Context? A big result set could be noisy. → run the query inside a subagent that returns just the summary.
• Procedure? “Churn” has a specific definition at your company. → a skill documenting the churn query logic.

Answer: all three, composed. The MCP server connects, the skill defines “churn,” the subagent runs it cleanly. This is the canonical full-stack case.

Worked Scenario 3: “Make sure every release follows our checklist” #

• Capability? Git, file reads — already there. No server.
• Context? Light. No subagent strictly needed for protection.
• Procedure? Entirely the point — your team’s release steps. → Skill, or a custom agent if you want it to enforce and produce a report.

Answer: a skill (or a release-gate custom agent). Building an MCP server here would be pure over-engineering.

Anti-Patterns #

• The MCP-server-for-everything trap. Shipping a service to solve a documentation problem. If you’re not connecting to an external system, you probably don’t need a server. (Browse the MCP server registry to see what genuinely warrants one.)
• The bloated CLAUDE.md. Stuffing every procedure into always-on context. Move situational playbooks into skills so your base context stays sharp.
• The mega-subagent. A subagent that “does everything” is just the parent with a worse memory. Split by concern.
• Skill that needed a capability. Writing a beautiful skill for “analyze our metrics” when Claude can’t reach the metrics. No instructions substitute for the missing MCP connection.

The Principle #

The three extension points map to three resources: knowledge (skills), context (subagents), and capability (MCP servers). Diagnose which resource you’re actually short on, and the choice makes itself. Most teams over-reach for MCP servers because they sound powerful, when a markdown file would have shipped the same outcome by lunch. Build the lightest thing that moves the axis you’re stuck on.

Setting Up Production-Ready Claude Code #

Running all three layers — especially MCP servers — at scale wants stable infrastructure:

1. A reliable host for MCP servers and CI. MCP servers are long-running processes; you need a box that stays up. HTStack — Hong Kong VPS with low-latency mainland-China access and stable BGP. Same IDC that hosts dibi8.com, where we run our own MCP servers and agent pipelines. $5-12/month value tier.

2. Cloud headroom for parallel layers. When subagents fan out and MCP servers run alongside, you want spare CPU. DigitalOcean — $200 free credit for 60 days across 14+ regions.

3. A skills bundle. The fastest way to internalize the skill/subagent/server split is to study working examples. We packaged five battle-tested skills as a $19 bundle on Gumroad — see the floating CTA in the corner — including custom agent definitions and the orchestrator prompts that compose all three layers.

Related Reading #

• Custom Agent Authoring Guide — how to actually build the subagent half.
• Subagent Patterns — the five workflows for the context axis.
• MCP Servers 2026 Rankings — choosing the capability layer.
• MCP Server Registry Guide — the catalog of what’s worth connecting.

Verdict #

Stop asking “skill, subagent, or MCP server?” as if they compete. Ask instead: am I short on knowledge, context, or capability? Knowledge → skill. Context → subagent. Capability → MCP server. The full-stack cases use all three, layered. And when in doubt, build the cheapest artifact that moves your axis — a markdown file beats a deployed service every time it can.