Claude Code skills, subagents, MCP, and hooks, defined plainly
Straight up: the reason these four get confused is that they all sound like ways to make Claude Code do more. They are, but they answer different questions. Before you decide when to use each, you need a clean definition of each one that does not lean on the others.
A skill is packaged know-how. It is a set of instructions, conventions, and sometimes helper files that teaches Claude how you want a particular kind of work done. Think of it as a written standard operating procedure that loads when it is relevant. A skill does not run on its own and it does not connect to anything outside. It shapes how the work is done.
A subagent is a separate worker with its own context window, dispatched to handle a focused sub-task and report back. It keeps its own scratch space, so the noise of a big investigation does not crowd the main conversation. Anthropic documents subagents as a first-class feature here: https://docs.anthropic.com/en/docs/claude-code/sub-agents . The key word is isolation. A subagent exists to do a chunk of work without polluting the main thread.
An MCP server is a connection to external tools and data. It is how Claude Code reaches a database, a ticketing system, a design file, or an internal API in a structured way. If you want the deeper background, we wrote it up in [what are MCP servers and why they matter](/blog/what-are-mcp-servers-and-why-they-matter). MCP is about reach, not behavior.
A hook is an automatic action that fires on an event. When something happens, such as a file being edited or a session wrapping up, the hook runs a command you defined. You are not asking Claude to remember to do it. The harness does it every time, deterministically.
The one question that picks the right primitive
When a teammate asks which one to use, I do not start by describing features. I ask what they are actually trying to change. There are only four honest answers, and each maps to one primitive.
- If the answer is "I keep re-explaining how I want this done," you want a skill. You are encoding a standard.
- If the answer is "this sub-task is big and noisy and I do not want it cluttering the main thread," you want a subagent. You are isolating work.
- If the answer is "Claude needs to read or write something that lives outside the codebase," you want MCP. You are adding reach.
- If the answer is "this should just happen automatically every time X occurs," you want a hook. You are removing a manual step.
Notice that none of these is about power. They are about the shape of the problem. The most common waste I see is people reaching for the heaviest tool because it feels the most capable, when a one-paragraph skill would have solved it cleanly.
The decision table
Here is the reference I hand to people on client teams. Find the situation that matches, use the primitive in the middle column, and the right column tells you why it is the right call rather than one of the others.
Situation to primitive to reason
| Situation | Use | Why |
|---|---|---|
| You repeat the same instructions for how a task should be done | Skill | It packages the know-how so you stop re-explaining the standard |
| A focused sub-task generates a lot of intermediate noise | Subagent | It runs in its own context so the main thread stays clean |
| You want a second opinion or parallel investigation while you keep working | Subagent | Isolation lets it work without consuming or derailing your context |
| Claude needs to query a live database or internal API | MCP | MCP is the structured connection to external tools and data |
| Claude needs to read tickets, design files, or another system | MCP | Same reason: reach into systems that are not in the repo |
| You want tests to run automatically after every edit | Hook | A hook fires deterministically on the event, no reminder needed |
| You want a wrap-up note written at the end of every session | Hook | The harness runs it every time, so it never gets skipped |
| A one-off check you will run twice this week | None of these | Just ask directly; automation overhead is not worth it yet |
Common mistakes that slow you down
These are the patterns I correct most often. None of them break anything outright. They just add friction or cost that you stop noticing, which is worse.
The first is using a subagent when a skill would do. People dispatch a subagent to "review code the way we like it," when what they actually needed was a written review standard. A skill is cheaper, it is reusable, and it does not spin up a separate context for what is really just guidance. Reach for the subagent when the work is genuinely large or noisy, not when you only needed to tell Claude how you want it done.
The second is wiring a hook for something you do once. Hooks earn their keep on repetition. If you are only going to run a check twice, the time spent configuring and testing the hook outpaces the time it saves. Automate the thing you do every session, not the thing you did once and labeled a workflow.
The third is reaching for MCP when the data is already local. If the information lives in the repo, Claude can already read it. MCP is for systems outside the codebase. Adding a connection you do not need is just another moving part to maintain.
The fourth is letting skills pile up. A skill that loads when it is not relevant adds noise. Keep your skills narrow and well-scoped so the right one engages at the right time. We go deeper on keeping context clean in [how to use Claude Code like a pro](/blog/how-to-use-claude-code-like-a-pro) and on persistent memory in [the Claude Code memory system](/blog/claude-code-memory-system-three-tiers).
How they fit together on a real project
On a typical client build, all four show up, each in its lane. Skills carry our standards: how we review, how we commit, how we write tests. Subagents take the heavy investigations, like tracing a bug through an unfamiliar module, so the main thread stays focused on shipping. MCP connects to the client's staging database and their ticket system so Claude is working from real context, not guesses. Hooks keep the boring discipline automatic, running the test suite after edits and writing a short session summary at the end.
The point is not to use all four. The point is to recognise which question you are answering so you stop forcing one primitive to do another's job. Get that right and the system feels calm and predictable, which is the whole goal on paid work.
If you want to see how operators actually wire these together day to day, that is most of what we trade notes on inside the Claude Code Club community: https://www.skool.com/claudecodeclub/about . Worth a look if you are setting this up for real client work. For more guides, the [blog index](/blog) has the rest.
Frequently asked questions
What is the difference between a skill and a subagent?
A skill is packaged know-how that shapes how a task is done. A subagent is a separate worker with its own context that does an isolated sub-task and reports back. Use a skill to set a standard, a subagent to isolate noisy work.
When should I use MCP instead of a skill?
Use MCP when Claude needs to reach external tools or data, such as a live database, an API, or a ticketing system. A skill cannot connect to anything outside; it only governs behavior. If the data is already in your repo, you do not need MCP.
Are hooks worth setting up for a small project?
Only if you repeat the action. Hooks fire automatically on events, so they pay off when you do something every session, like running tests after an edit. For a one-off, configuring a hook costs more than it saves.
Can I use a skill and a subagent at the same time?
Yes. A subagent can run with a skill loaded, so the isolated worker still follows your standard. They are complementary, not competing.
Where can I read Anthropic's official documentation on subagents?
Anthropic documents subagents as a first-class Claude Code feature at https://docs.anthropic.com/en/docs/claude-code/sub-agents .
Last reviewed by Duncan Rogoff on June 15, 2026
