Prompt, agent, MCP, Skill, hook: in most conversations about building with Claude right now, these five words get used like they mean the same rough thing, some way of getting the model to do what you want. They don't. Nobody would call MCP and Skill the same thing if you stopped and asked directly, but under deadline pressure, "give Claude access to do X" and "teach Claude to do X well" collapse into the same mental bucket, and you reach for whichever term you saw most recently in a changelog or a tweet. Same thing happens with prompt, agent, and hook. Five words, treated like synonyms, that actually sit at five different layers of the stack and answer five different questions. Mix them up and you don't get an error. You get the wrong thing, built competently.
Five layers, five questions
Before going further: three of these five terms are borrowed by everyone in the industry, prompt, agent, and increasingly MCP mean roughly the same thing whichever vendor's docs you're reading. Skill and Hook, as I'm defining them here, are specifically Claude Code / Anthropic-ecosystem terms. "Skill" means something else entirely if you're coming from Alexa, and "hook" already has two other meanings in your codebase (git hooks, React hooks) before you even get here. I'm grounding all five in the Anthropic stack because that's what this series is about. Worth knowing going in, so nothing here reads as more universal than it is.
Prompt: what do I want, right now?
A prompt is an instruction. One-shot or a few back-and-forth turns, steered by a human in the moment. It has no memory beyond the conversation it's in, and nothing about it persists once the context window rolls over. Ask it to "add input validation to this endpoint" and it does exactly that, once, for this conversation; say nothing next week and the rule is gone. If the thing you need done is a one-time ask, a prompt is correctly scoped for the job.
Agent: who's carrying this out?
An agent is the loop, not the instruction. It takes a goal, breaks it into steps, decides which tools to call, and keeps going (across multiple turns, without you steering each one) until the goal's done or it gives up. Hand it "add input validation across every endpoint in this service" instead, and it goes and finds each one, edits them in turn, and checks its own work, without you feeding it a file list. A prompt tells the agent what you want this time; the agent is the thing that keeps working after you've stopped typing. (Worth a side note: "subagent" gets used for something narrower: a delegated, isolated agent spun up to handle one slice of work. Same underlying concept, smaller and more contained scope.)
MCP: how do I reach outside the model?
Model Context Protocol is the connectivity layer, an open standard for how an agent discovers and calls things that live outside it: databases, internal APIs, other services. It's the "how do I get out of the sandbox" answer: a Postgres MCP server, say, that lets Claude run a read query against staging directly instead of you pasting query results into the chat. Crucially, MCP gets you access to a capability. It says nothing about whether you're using that capability correctly.
Skill: what does doing this well look like?
A Skill is packaged procedural knowledge: a folder with instructions, and optionally scripts or reference material, that Claude loads only when it's relevant to the task at hand. A pr-description Skill, for instance, that knows your team's actual PR template, so what comes back matches what your reviewers expect instead of a generic three-line summary. It's not a permanent instruction sitting in context the whole session; it surfaces when needed and can even change what tools or model are in play for that task. Where MCP answers "can I reach this," a Skill answers "do I know how to do this well, in this specific situation."
Hook: what must always happen, no matter what the model decides?
A hook is code (most commonly a shell command, though it can also be an HTTP call or another model invocation) that the harness fires at fixed points regardless of what the model reasoned its way into. A PreToolUse hook that runs your linter before any file write lands, and blocks the write outright on failure, whether or not the model thought the change looked fine. The defining property isn't what runs, it's that it runs every time, independent of the model's judgment. That's the one primitive on this list that isn't, in any sense, a suggestion.
One rule, five ways: enforcing a changelog
Here's where the boundaries stop being abstract. Say the rule is: every time an API endpoint changes, the changelog gets an entry. Watch what happens when you try to enforce that with only one of these five tools at a time.
Only a prompt: you tell Claude, once, "remember to update the changelog when you touch an endpoint." It works for that session. Next week, new conversation, no memory of the instruction. The rule is gone. A prompt was the wrong shape for something meant to be standing policy.
Only a Skill: you write a changelog-entry Skill with the exact format and a script that appends to the file. Real improvement: now when Claude does remember to update the changelog, it does it well, in the right format, without you re-explaining. But the Skill only fires if the model decides this moment calls for it. It's knowledge, not enforcement.
Only MCP: you expose the changelog store as a tool Claude can call directly: no more manual file edits. Now Claude can write the entry cleanly. That still doesn't mean it will. MCP gave you the door; nothing's making anyone walk through it.
Only a hook: a PreToolUse (or PostToolUse) hook watches every edit under /api/ and blocks the operation (hard fail, no ambiguity) if the changelog wasn't touched in the same pass. This is the piece that actually holds. It doesn't care what the model "thought" was fine to skip.
The agent is what's running this whole sequence: interpreting the goal, deciding to edit the endpoint, calling the Skill for format, reaching MCP to write the entry, getting stopped or waved through by the hook. None of the other four exist as a coherent workflow without something driving the loop.
Put together: the Skill gives it good judgment, MCP gives it reach, the hook gives you a guarantee that survives bad judgment, and the agent is what's actually moving through all three. That's the whole argument in miniature.
The pair everyone actually confuses: MCP vs. Skill
If you only remember one distinction from this post, make it this one. It's not the only mix-up out there. Plenty of people also stall on "wait, isn't an agent a separate thing entirely from either of these?" But MCP and Skill are the two that get flattened together most, often enough that "should this be an MCP server or a Skill" has become its own small genre of blog post this year.
MCP is a door. It tells you a capability is reachable and gives you a defined way to reach it. It says nothing about whether reaching it right now, in this way, is the correct move. A Skill is the opposite half: it's the accumulated judgment about how to use a capability well in a given situation: which format, which edge cases to check, which shortcuts are actually mistakes. You can have an MCP connection to a changelog service and still write garbage entries into it forever, because access was never the missing piece.
If you're staring at a design doc and the plan is "let's build an MCP server for this," pause and ask whether the actual gap is reach or judgment. A shocking number of MCP servers get built to solve problems a well-written Skill would've closed in an afternoon.
The one-question test
Next time you're deciding what to build, skip the vocabulary debate and ask this instead: am I giving it an instruction, a capability, a skill, an enforcement mechanism, or a way to run all four together toward a goal? Whichever answer you land on tells you which of these five you actually need. Building the wrong one doesn't fail loudly. It just quietly ships the wrong solution, well-engineered.
A Skill is how you get good judgment into the loop. MCP is how you get reach. A hook is the one guarantee in the list that doesn't care what the model concluded. The agent is what's actually walking through all three, and a prompt is just this one ask, right now. Get the wrong one of these five, and nothing breaks loudly. You just ship something well-built that answers a question nobody asked.
Enjoyed this breakdown? I write about architecture decisions like this: modular monoliths, bounded contexts, and where AI helps vs. where it quietly breaks things, in my newsletter, AI + Architecture.
Top comments (0)