What Skills, Subagents, Hooks, and MCP Are Each Actually For

Ask ten developers building on AI coding agents to explain the difference between a skill, a subagent, a hook, and an MCP server, and you'll get ten answers with real disagreement buried inside the overlap. Part of the confusion is honest — all four primitives can, in some configuration, make an agent do something it wouldn't do by default. But "can technically accomplish this" is a bad way to choose a tool, and the four are not interchangeable once you look at what each one is actually built to do well.

This matters more than it seems, because reaching for the wrong primitive isn't just inelegant — it's expensive. Building an MCP server to solve a problem a markdown file could have solved means you've taken on a persistent process, a protocol implementation, and an ongoing maintenance burden for something that needed none of it. Getting this choice right is close to the whole game of building efficiently in this category.

Skills: Packaged, On-Demand Expertise

A skill is knowledge plus optional tooling, loaded when relevant and otherwise invisible. It's the SKILL.md file described in the previous piece in this series: a description of when to use it, a procedure to follow, and optionally some scripts to run along the way. The defining trait is that a skill doesn't run continuously and doesn't hold a conversation — it's consulted, the way you'd flip to a reference chapter mid-task, and then it's done.

Reach for a skill when the problem is "the agent doesn't know how to do this specific thing well, but once it knows the procedure, following it is straightforward." Onboarding a new agent to your team's deployment checklist, teaching it your org's commit message conventions, giving it a battle-tested procedure for migrating a database schema — these are skill-shaped problems. The knowledge is static, reusable, and doesn't need a standing process to deliver it.

Subagents: Delegated Focus, Not Delegated Knowledge

A subagent is a separate agent instance, often with its own context window and sometimes its own restricted toolset, spun up to handle a bounded piece of work and report back. Where a skill hands the primary agent a procedure, a subagent takes the task off the primary agent's plate entirely and works it independently — useful specifically when the work would otherwise pollute the main context with detail nobody needs to see again, like an exhaustive codebase search or a long research pass.

The tell for "this should be a subagent, not a skill" is whether the work benefits from isolation. If letting the primary agent's context fill up with search results or tool output would make the rest of its work worse, spin off a subagent, let it do the noisy work, and have it return a distilled result. If the task is more about "follow this known-good procedure" than "explore and report back," a skill does the job with far less overhead — no separate context to manage, no coordination cost.

Hooks: Deterministic Enforcement, Not Judgment

Hooks are the primitive builders most often confuse with skills, and the confusion is understandable because both can shape agent behavior around a specific event. But a hook is fundamentally different in kind: it's a deterministic script that fires automatically on a defined trigger — before a tool runs, after a file changes, when a session starts — and it executes the same way every time, with no model reasoning involved in whether it fires.

That determinism is the entire value proposition. A hook is for the rules you never want the agent to reason its way around — blocking a commit that touches a secrets file, running a linter automatically after every edit, refusing a destructive command outright. If you find yourself writing a skill whose entire content is "always do X before Y, no exceptions," that's usually a sign you actually wanted a hook: something that enforces the rule structurally rather than hoping the model remembers to follow written guidance every time.

MCP: Live Access to Something Outside the Agent

Model Context Protocol servers exist to solve a problem neither skills, subagents, nor hooks touch: giving an agent live, structured access to an external system — a database, an API, a SaaS product, a piece of internal infrastructure — through a standing connection the agent can query and act through repeatedly during a session. An MCP server isn't knowledge you're teaching the agent; it's a door you're opening to something the agent couldn't otherwise reach at all.

This is the primitive most often reached for when a skill would have sufficed, largely because MCP got hyped earliest and hardest in the category, and "add an MCP server" became the default instinct for anything involving external interaction. But if the interaction is a one-shot script call — hit this webhook once, transform this file, run this CLI command — that's a skill with an attached script, not a standing protocol server. MCP earns its overhead when the agent needs ongoing, stateful, back-and-forth access to a live system across many turns, not when it needs to fire a single action.

This distinction is not academic. It's also the reason MCP is where a lot of the category's security exposure concentrates: a 2026 audit of more than 2,600 MCP servers found 82% vulnerable to path traversal and 67% vulnerable to code injection, because a standing server with broad system access is a fundamentally larger attack surface than a scoped script invoked once by a skill. Reaching for MCP when you didn't need to isn't just architectural overkill — it's taking on risk a simpler primitive wouldn't have carried.

A Rough Decision Order

None of these four are strictly ranked against each other — they solve different problems — but there's a useful order to check them in before building anything: is this a static procedure the agent should follow (skill), a bounded task worth isolating in its own context (subagent), a rule that must fire the same way every time with no room for model judgment (hook), or genuinely live access to an external system the agent needs across a whole session (MCP)? Most builders skip straight to whichever primitive they're most excited about — usually MCP, because it feels the most like "real infrastructure" — and back into a justification afterward.

The marketplace angle sharpens this further. A skill packaged as a SKILL.md file is portable across the 20-plus agents now compatible with the format and sells as a lightweight, low-risk artifact — a buyer can read the whole thing before running it. An MCP server sells as infrastructure with a much higher trust bar, because the buyer is granting it standing access, not just running a documented procedure once. If you're building something to sell in this category, the primitive you choose isn't just a technical decision — it's a decision about what kind of trust relationship you're asking a stranger to enter into with you, which is worth thinking through before you write a line of code.

Skills teach, subagents delegate, hooks enforce, MCP connects — and conflating them is the single most common architecture mistake in the skill economy right now. Getting the mapping right isn't just cleaner engineering. It's the difference between shipping something a buyer can evaluate in thirty seconds and something that needs an audit before anyone reasonably trusts it.

Part of the "The Skill Economy" series on aiskill.market.