MCP, Skills, Hooks, Sub-agents: What They Are and How to Choose

If you've spent any time customizing Claude Code, you've probably noticed there are several ways to extend it — MCP servers, skills (slash commands), hooks, and sub-agents. Each looks like a way to "add capabilities," but they operate at fundamentally different layers. Getting this wrong means you'll build brittle automations, miss obvious shortcuts, or spawn agents for tasks that a single tool call would handle cleanly.

Here's how I think about them.

MCP: Connecting Claude to External Systems

MCP (Model Context Protocol) is about data and tools from outside the process. When you configure an MCP server, you're giving Claude access to a set of callable tools that proxy to some external system — a database, a SaaS API, a file system overlay, a browser. The model decides when to call them based on context, and the results come back as tool outputs that inform the next step.

The right mental model: MCP is a standardized plug. If you need Claude to read from Notion, query a Postgres database, or fetch Figma frames, MCP is the correct layer. It doesn't change how Claude reasons or what instructions it follows — it just expands what Claude can see and act on in the environment.

The tradeoff is that MCP tools are always model-initiated. Claude decides whether to call them. If you need something to happen unconditionally — like logging every file write or enforcing a pre-commit check — MCP is the wrong tool. The model might simply not invoke it.

Skills: Injected Expertise for Repeatable Workflows

Skills (surfaced as slash commands like /code-review or /deploy) are specialized instruction sets that get loaded into the conversation when invoked. They don't add new tools — they guide how Claude approaches a particular type of task. A skill can load domain knowledge, enforce a structured workflow, or prime the model with the right mental framework before it starts working.

I think of skills as senior colleagues with narrow expertise. When I type /code-review ultra, I'm not asking Claude to do something it couldn't do with a long prompt — I'm invoking a structured, battle-tested approach that I don't want to re-specify every time. The knowledge is encoded once; the invocation is explicit and intentional.

Skills are the right choice when you have a workflow you repeat often and want to encode once. They're not for dynamic behavior — they can't react to system events, and they don't run autonomously. They need to be explicitly invoked each time.

Hooks: Deterministic Side Effects

Hooks are shell commands that execute in response to harness events — PreToolUse, PostToolUse, Stop, and others. They run independently of Claude's reasoning. The model doesn't decide whether they fire; the event does.

This is the most underutilized layer, and also the most precise. If you want to run a linter after every file edit, post a notification when Claude stops, or block certain tool calls before they execute, hooks are your only reliable option. MCP requires Claude to decide to call a tool. Skills require explicit invocation. Hooks just fire.

The tradeoff is that hooks are dumb — they're shell commands, not agents. They can't reason about context or make nuanced decisions. But that's often a feature, not a bug. Determinism is valuable when you're enforcing policy or triggering side effects that must not be optional. If something needs to always happen, it should not depend on the model choosing to make it happen.

Sub-agents: Context Isolation and Parallelism

Sub-agents are spawned instances of Claude with their own conversation context. They're the most expensive layer — each one starts cold and re-derives context from scratch. But they offer two things the other mechanisms don't: context isolation and true parallelism.

Context isolation matters when a research task would flood the main conversation with noise — searching dozens of files, fetching multiple URLs, running broad grep patterns across a large codebase. Delegating that to a sub-agent keeps the main context clean and focused. Parallelism matters when you have genuinely independent tasks that would take too long sequentially.

The mistake I see most often is spawning sub-agents for simple lookups that a direct grep or file read would answer in one step. Sub-agents are for open-ended investigation, not targeted queries. The cold-start cost is real — don't pay it unless the context isolation or parallelism genuinely earns it back.

A Simple Decision Heuristic

When I'm deciding which layer to reach for, I work through four questions in order.

Does it need to reach outside the process? A database query, an API call, a browser action — these are MCP's domain. If the answer is yes and the model should decide when to invoke it, configure an MCP server.

Does it need to run unconditionally, regardless of Claude's decisions? Enforcement, logging, side effects — anything that must not be optional belongs in a hook, not in a prompt or skill.

Is it a repeatable workflow I want to invoke explicitly? Encode the expertise once as a skill. Invoke it by name. Don't re-specify the same structured approach in every session.

Does it need isolated context or true parallelism? If yes, spawn a sub-agent. Otherwise, handle it inline. The overhead isn't worth paying for anything a direct tool call can answer.

Most tasks fit cleanly into one category. When they don't — when you need an external tool call that always fires after a certain event — the answer is usually to compose layers: a hook triggers deterministically, and an MCP tool makes that action reach an external system. The layers aren't mutually exclusive; they're a stack you can combine deliberately.

The concrete takeaway: before reaching for a sub-agent, ask whether a skill would suffice. Before writing a skill, ask whether a hook handles the determinism requirement. Before configuring MCP, confirm that Claude actually needs to decide to call the tool rather than having it fire automatically. Most of the time, the simplest layer that satisfies the requirement is the right one — and knowing which layer that is saves more time than any individual automation ever will.