Three mechanisms, one instinct: reach for whichever one you learned first. That instinct is why most Claude Code setups are slower and less secure than they need to be.
Three Mechanisms, One Reflex
Skills, subagents, and MCP servers all get pitched the same way: a way to extend what Claude can do. That framing is technically true and practically useless, because it tells you nothing about which one to reach for. Most teams default to whichever mechanism they learned first, then bend every new problem to fit it - a skill for something that should have been a subagent, an MCP server for something that should have been a five-line skill.
Part of the confusion is that these three didn't arrive as a designed system. Anthropic open-sourced the Model Context Protocol in November 2024. Claude Code added subagents in 2025. Agent Skills launched as their own standard in October 2025, nearly a year after MCP. Nobody sat down and divided one problem into three mechanisms - three separate problems got solved in sequence, and the overlap in what they're capable of is what makes the choice feel arbitrary now.
It isn't arbitrary. The real differentiator was never capability - all three can, in some fashion, add a tool or a piece of knowledge to what Claude does in a session. The differentiator is where each one spends context, and what it exposes you to. That's the axis this article actually uses.
What a Skill Actually Costs
A skill runs in your main conversation by default. When Claude Code loads a skill's description into context at session start, that costs almost nothing - Anthropic's own design principle for this is progressive disclosure: metadata in the system prompt, full SKILL.md content only when the skill is actually invoked, and any bundled reference files loaded only when the skill's own instructions point to them. Anthropic's Agent Skills engineering post describes the intent plainly: skills "load information only as needed," which is exactly the discipline that keeps a 500-line reference document from taxing every single turn.
The cost shows up after invocation, not before it. Once a skill's content enters the conversation, Claude Code's own documentation is explicit that it stays there for the rest of the session - the instructions aren't re-read on later turns, they just sit in context, recurring cost included. Even Claude Code's compaction behavior treats this as a real budget problem: when the conversation gets summarized, re-attached skills share a combined 25,000-token budget, keeping the first 5,000 tokens of each, oldest ones dropped first if you invoked several.
That's the trade a skill makes: it saves you from re-explaining a procedure, at the price of a token footprint that persists for as long as the session runs. For a checklist you invoke once a day, that's a rounding error. For a large reference skill invoked early and needed all session, it's a standing tax - one worth paying only when the alternative (re-explaining the same thing every time) actually costs more.
What a Subagent Actually Buys You
A subagent flips the trade. It runs in an isolated context window - its own system prompt, a fresh task message, no conversation history from the main session unless it's a fork. When it finishes, only a summary returns to the parent conversation. Claude Code's own subagent documentation is specific about what background subagents (the default) get: a reduced tool set - Read, Grep, Glob, Bash, Edit, Write, WebFetch, WebSearch, plus MCP tools - while foreground subagents inherit the full parent tool set.
A skill adds cost to preserve access to everything in your session. A subagent removes access to everything in your session to preserve cost. They're mirror images of the same tradeoff, not two points on the same scale.
This is the mechanism for verbose or exploratory work you don't want cluttering the main thread: grepping four hundred files, reading half of them, and reporting back costs the parent conversation exactly one summary - not four hundred file reads. It's also the mechanism for enforcing a permission boundary: a subagent configured with tools: Read, Grep, Glob can research a codebase and structurally cannot write to it, which a skill running in your main context can't guarantee on its own.
The honest limitation here is that isolation has a cost of its own: a subagent starts cold every time. It doesn't share your conversation's accumulated context, so a task that genuinely needs the last ten turns of back-and-forth is a bad fit - you'd spend more effort re-explaining the situation than you saved by isolating the work. The decision isn't "subagents are better because they're isolated," it's whether the isolation is worth losing shared history for that specific task.
What an MCP Server Actually Exposes You To
MCP is the odd one out for a specific reason: it isn't a Claude Code feature. It's a protocol - stdio, HTTP, SSE, or WebSocket transport, connecting Claude to external tools and data sources - and Anthropic donated it to the Linux Foundation's newly formed Agentic AI Foundation in December 2025. OpenAI adopted it across its product suite in March 2025. Google DeepMind followed in April 2025, with CEO Demis Hassabis calling it "a good protocol" that was "rapidly becoming an open standard for the AI agentic era."
That scale is exactly why MCP's context-handling problem looks different from the other two. Anthropic's own MCP reference is direct about it: without deferred loading, connecting more servers would mean loading more tool schemas into context whether you use them or not. Tool search solves this by deferring full tool definitions until Claude actually needs them - only names and server instructions load at session start. Against an ecosystem that the official MCP Registry puts at nearly 2,000 servers, and that community directories like mcp.so (over 20,000) and LobeHub (more than 56,000) catalog at far larger scale, that deferral isn't an optimization. It's the only way the mechanism works at all.
The cost MCP trades for that reach is not a context-budget number - it's a trust surface. Anthropic's own MCP docs carry a direct warning: verify you trust each server before connecting it, because servers that fetch external content can expose you to prompt injection. That warning isn't theoretical. In April 2025, independent researcher Simon Willison documented Invariant Labs' proof-of-concept against a malicious calculator MCP server: instructions hidden inside a tool's description, invisible to the user, silently directed Cursor's underlying model to read a developer's SSH private key and MCP configuration and transmit both to a remote endpoint. The developer saw normal behavior the entire time. OWASP's MCP Top 10 now lists this pattern as MCP03: Tool Poisoning.
That's the asymmetry worth sitting with. A skill's worst case is a wasted token budget. A subagent's worst case is a task that needed context it didn't have. An MCP server's worst case is a tool description that reads your SSH key and tells you nothing happened. Connecting an MCP server is the one decision in this article that deserves a security review, not just an architecture one.
The Decision, Not the Feature Comparison
Stop asking which mechanism is more capable. Ask three questions in sequence, and let the answer to each one rule out the other two.
That tree is a simplification, and the honest caveat belongs here rather than left out: most non-trivial Claude Code setups don't end up using exactly one of these. They compose. A skill can run inside a forked subagent (context: fork) when a procedure needs isolation as well as persistence. A subagent can preload skills into its own context via the skills field. Either one can call MCP tools once connected. The decision tree tells you which mechanism is primary for a given task - it doesn't tell you the whole architecture, because the whole architecture is usually layered.
The composition is also where the earlier context-cost framing pays off. A skill invoked with context: fork doesn't leave its content sitting in your main conversation - it hands the work to an isolated subagent instead, so you get the reusability of a documented procedure without the recurring token tax of running it inline. That single frontmatter field is the bridge between the two mechanisms this article spent the most time contrasting, and it only makes sense once you've internalized that skills and subagents are opposite answers to the same cost question.
The gap in the tree above is real, and it's worth naming plainly: it treats "needs an external system" as a clean yes/no gate, when in practice the answer is often "yes, but only for one step of a five-step task." A setup that reaches for an MCP server for the whole task when only step three needed it inherits that server's trust surface for steps one, two, four, and five that never touched it. The tree tells you where to start. It doesn't excuse you from re-asking the same three questions at each step of anything longer than a single action.
The teams shipping fast with Claude Code aren't the ones who found the best mechanism. They're the ones who stopped asking which one is best and started asking what it costs.
Sources
- Anthropic - Introducing the Model Context Protocol (November 2024) - primary announcement of MCP as an open standard
- Anthropic - Equipping Agents for the Real World with Agent Skills (October 2025) - primary source on progressive disclosure and the design rationale for Skills
- Anthropic - Donating the Model Context Protocol and Establishing the Agentic AI Foundation (December 2025) - MCP's donation to the Linux Foundation
- Claude Docs - Subagents Reference - primary documentation on context isolation, tool restrictions, and invocation
- Claude Docs - Skills Reference - primary documentation on progressive disclosure, content lifecycle, and compaction budgets
- Claude Docs - MCP Reference - primary documentation on tool search, deferred loading, and output token limits
- TechCrunch - Google to Embrace Anthropic's Standard for Connecting AI Models to Data (April 2025) - Google DeepMind's MCP adoption
- Simon Willison - Model Context Protocol Has Prompt Injection Security Problems (April 2025) - the Invariant Labs tool-poisoning proof-of-concept against Cursor
- OWASP - MCP Top 10, MCP03:2025 Tool Poisoning - institutional classification of the attack class
- TrueFoundry - Best MCP Registries in 2026 - MCP ecosystem registry scale comparison
Working through the challenges in this post? I help engineering leaders and CTOs navigate complex technical decisions and scale high-performing teams. Schedule a consultation →