Skill, tool, MCP server, plugin, hook: what is the difference?
Skills, tools, MCP servers, plugins, hooks and sub-agents all extend an agent. They differ in who starts them, when they enter the context window, what they cost in tokens and whether code or the model's judgement decides.
Anyone who sets up or builds an agent and meets these words in documentation. No programming is needed to follow it; the configuration samples help if you write such files yourself.
- Four questions that tell any kind of agent extension apart
- Which things sit in every request, which load only when needed, and what each costs in tokens
- What a SKILL.md, an MCP tool listing, a plugin folder and a hook configuration look like
- When to split work across sub-agents, agent teams or A2A, and what that costs
- Which one to reach for first, and the mistakes people make most often
Why these words get mixed up
Many different things extend an AI agent, and documentation uses the words loosely. Four questions separate them: who starts it, when it enters the model's input, what it costs, and whether code or the model decides.
An agent is a language model running in a loop: it reads its input, decides on a step, a program around it carries the step out, and the result goes back into the input. That program is the harness. Almost everything in this guide is a way to change what the harness puts in front of the model, or what the harness does around it. Because all of it ends up as text in the same input, the context window, the words are easy to confuse: a skill, a slash command and a playbook can hold the same Markdown, and a tool, an MCP server and a hook can run the same script.
The differences lie in the mechanics, not in the content. The same rule ("quote every fare including one cabin bag") behaves very differently as a line in the system prompt, as a step in a skill, or as a hook that rejects a spreadsheet row without a bag fee. The four questions in the table below separate them, and the next part answers them for twelve common kinds.
The fourth question matters most. A model follows instructions with high probability, not with certainty. If a rule must hold every time, it has to be checked by code that runs whatever the model decides. Vendor documentation says so plainly: instruction files are treated as context, not as enforced configuration, and an action that must always be blocked needs a hook.
All of them side by side
One table with twelve common kinds of agent extension, answering the four questions for each. Read across a row to see how one kind behaves, or down a column to compare them.
Each row is one kind of extension. The columns are the four questions, plus what the thing is and what it suits best. The Deterministic? column says whether code guarantees the behaviour. "Partly" means that some pieces are code, such as a script bundled with a skill, while the decision to use them is still the model's.
Read the column When it enters the context and three groups appear. The system prompt, instruction files and memory are loaded on every request. Skills, playbooks, slash commands and retrieval (RAG) enter only when a task needs them. Tools, MCP servers and hooks are about acting and enforcing rather than knowing, and sub-agents split the work across separate context windows. Plugins are not a kind of their own: they package the others. The next parts take these groups one at a time, with the file formats and the token arithmetic behind each row.
Always loaded: system prompt, instruction files, memory
Some text is placed in front of the model at the start of every request: the developer's standing instructions, project rule files and saved memory. It is always there, so it is always paid for.
The system-prompt is the developer's standing text at the top of the input: role, rules, output format and guidance on when to use which tool. The model API keeps nothing between calls, so the harness sends it again with every request of a run. It is written once and changes rarely, which makes it the best candidate for prompt-caching: the provider stores the processed form of an unchanged beginning of the input and bills later reads of it at a fraction of the normal input price, a tenth or less on Claude models (October 2026).
Instruction files are Markdown files the harness finds on disk and adds at the start of every chat or job. AGENTS.md is the cross-tool format, stewarded by the Agentic AI Foundation and used by more than 60,000 open-source projects; many harnesses also read their own file, such as CLAUDE.md or GEMINI.md. Files are layered: a personal file, a project file shared in the repository, and files in sub-folders, where the nearest one wins. Some harnesses load a sub-folder's file only once the agent works in that folder, and Codex caps the combined chain at 32 KiB by default (October 2026).
Memory is what the agent keeps from one chat or job to the next: preferences, decisions, progress. It lives outside the model, in files or a database, and is loaded back. Two shapes are common. An index loaded at the start (Claude Code loads the first 200 lines or 25 KB of its MEMORY.md, October 2026) is always paid for. A memory tool, which the model calls to create, read and update its own notes, costs tokens only when used, but depends on the model deciding to look.
The cost is simple multiplication. A run of 40 tool calls is about 40 requests, and everything always loaded is paid in each of them: as an illustration with invented sizes, a 2,000-token instruction file costs 80,000 input tokens before any work is done. Caching lowers the price but not the competition for attention. Every always-loaded line sits next to the task, which is why vendors advise short files; Claude Code suggests under 200 lines per CLAUDE.md.
Loaded when needed: skills, slash commands, playbooks
Know-how for one kind of task can wait on disk until that task comes up. Until then only a one-line description sits in the model's input, so an agent can carry many of these at little cost.
A skill is a folder with a SKILL.md file: YAML front matter (a block of named fields between two --- lines) followed by Markdown instructions, and optionally scripts/, references/ and assets/ folders. The open specification at agentskills.io requires two fields. name is at most 64 characters of lower-case letters, digits and hyphens and must match the folder name; description is at most 1,024 characters and says what the skill does and when to use it. Optional fields are license, compatibility, metadata and an experimental allowed-tools.
Skills load in three stages, which is called progressive disclosure. At the start the harness puts only each skill's name and description into the input, about 100 tokens per skill. When a task matches a description, the model reads the full SKILL.md; the specification recommends under 5,000 tokens and 500 lines. Files in references/ or scripts/ are opened only when the instructions point to them, and a script can be run without its source entering the context, since only its output comes back. By that figure, twenty skills would cost roughly 2,000 tokens per request until one is used.
A skill is started by the model, on its own judgement, or by the person, by name. The model decides from the description alone, so the description is the trigger: write what the skill does and "Use when ..." with the words a user would type. Harnesses let you restrict this. In Claude Code, disable-model-invocation: true means only the person can start the skill, which suits actions with side effects such as a deploy, and user-invocable: false hides it from the person's menu.
A slash-command is a saved prompt template started by name, such as /review, with arguments filled into placeholders. Claude Code states that custom commands have been merged into skills: a command file and a skill of the same name both create the same slash command. MCP servers can offer the same as prompts, which the specification calls user-controlled, giving slash commands as an example of the interface. A playbook is a written procedure for a recurring task with steps, checks and a definition of done; Devin's documentation compares one to a custom system prompt for a repeated task. Stored as a skill, it loads only when its task starts.
Plugins: one install for a whole setup
A plugin is not a new kind of extension. It is a package that installs several skills, sub-agents, hooks and MCP servers together, so that a team can share one setup and update it as a unit.
A plugin is a folder with a manifest, a JSON file that names the plugin and describes its parts, plus the parts themselves. In Claude Code the manifest is .claude-plugin/plugin.json, and a plugin can hold skills, sub-agent definitions, a hooks file and an .mcp.json file that adds MCP servers. Plugins are distributed through marketplaces, which are catalogues kept in ordinary Git repositories or folders. A vendor-neutral Agent Plugins specification (version 1.0.0) defines a shared package format, with a plugin.json manifest, for skills and MCP servers; its initial Technical Steering Committee includes core maintainers from Amazon, Cursor, Microsoft, OpenAI and Vercel.
Every part keeps its own behaviour after installation. A skill in a plugin still loads progressively, a hook still fires on its event, an MCP server still adds tools. The context cost of a plugin is therefore the sum of its parts, and it is paid in every session where the plugin is enabled, not only when you use it: the names and descriptions of its skills and agents that the model may start on its own sit in the input on every turn, its MCP servers run alongside the session and its hooks fire at their events. Claude Code shows an estimated context cost for plugins in Anthropic's official marketplace before you install them (October 2026).
A plugin also carries the risk of its parts. It runs code with your user privileges, and an update can change what it does. Read its contents, pin a version, enable it only in projects that need it, and switch off plugins you no longer use.
Things that act: tools and MCP servers
A tool is a function the model can ask the harness to run, such as a fare search. An MCP server is a separate program that offers tools to any app that speaks the same open protocol.
Tools are how an agent does things rather than knows things. Each tool is described by a name, a description and a JSON Schema for its inputs, and these definitions are sent with every request. When the model wants a tool, it emits a structured call with the tool's name and inputs and stops; the harness validates the call, runs the real code and returns the result as a new message. This is function-calling. Choosing the tool and its arguments is the model's judgement, but the code then runs exactly as written, which is why the table marks the action itself as deterministic.
The Model Context Protocol standardises where tools come from. The host application runs one MCP client per server. The mcp-server answers a tools/list request with its tool definitions and a tools/call request with results, using JSON-RPC messages, locally over standard input and output or remotely over HTTP. The harness turns each listed tool into an ordinary tool definition, so the model sees no difference. Servers can also offer resources (data to read) and prompts (templates). The current revision, 2026-07-28, made the core stateless, so a server no longer keeps a session per client.
The cost of tools lies in their definitions, which are input on every request whether a tool is used or not. Anthropic described a setup of five MCP servers with 58 tools that used about 55,000 tokens before the conversation starts, and said it has seen tool definitions consume 134,000 tokens internally (November 2025). Tool search keeps only a search tool in the input and loads definitions when needed; Anthropic reported an 85% cut in definition tokens and better tool choice on its MCP evaluation (November 2025). Results cost too, so a tool should return short, filtered output rather than a raw dump.
Tool definitions sit at the very start of the cached part of the input. Adding a server in the middle of a session or reordering tools therefore invalidates the cache for everything after them. The MCP specification says servers should return their tools in a deterministic order, and names prompt cache hit rates as one reason.
Things that enforce: hooks
A hook is a small script the harness runs automatically at a fixed moment, for example just before a tool is used. It runs whatever the model decides, so it is the place for rules that must always hold.
Hooks reverse the direction. The model does not choose to call a hook; the harness fires a lifecycle event and runs every hook registered for it. Typical events are the start of a session, a submitted prompt, before and after each tool call, before the context is compacted, and the moment the agent wants to stop. Claude Code documents 33 such events (October 2026). Claude Code and Cursor share a common shape: the event arrives as JSON on standard input, a matcher selects which tools or commands the hook applies to, and exit code 2 blocks the action.
In Claude Code, exit code 0 lets the action proceed. Exit code 2 blocks it on events that can be blocked, and the text on standard error goes back as the reason. Any other code is a non-blocking error, so a script that crashes does not block. A PreToolUse hook that exits with 2 stops the tool call; a Stop hook that exits with 2 keeps the agent working, which is how a definition of done such as "the tests pass" is enforced. A hook can also print JSON with an additionalContext string inside hookSpecificOutput, which Claude Code adds to the context as a system reminder at the point where the hook fired.
Output is the only way a hook touches the context: the additionalContext string, plain text on standard output for a few events such as SessionStart and UserPromptSubmit, and the standard error text when a hook blocks. The script itself never enters the context, so a hook costs close to zero tokens; its price is time, because a slow hook on every tool call delays every turn. Not every hook is deterministic: Claude Code also offers hook types that ask a model for a decision or start a small agent to check a condition (the agent type is experimental), which bring judgement back in. For a rule that must hold, use a command hook whose logic is plain code. Hooks run with your permissions, so install them only from sources you trust.
Things that split work: sub-agents, agent teams, A2A
Some jobs are better split among several agents, each with its own fresh input. The helpers send back a short result, which keeps the main agent's input small but uses more tokens overall.
A sub-agent is a separate agent instance with its own context window, its own instructions and often a narrower set of tools or a cheaper model. The main agent calls it like a tool, with a written brief, and gets back only its final message. Everything the helper read along the way (search results, files, dead ends) stays in the helper's context. In Claude Code a sub-agent is a Markdown file with front matter (name, description, optional tools and model) whose body becomes its system prompt; as with skills, the description decides when the main agent delegates.
The cost cuts both ways. The main context stays small, but every helper pays for its own input, and the brief is all it knows: unless it is a fork of the current conversation, it sees nothing of the parent's conversation. Anthropic's multi-agent research system beat a single agent by about 90% on an internal research evaluation while using about 15 times the tokens of a chat (June 2025). A Google study of 180 agent configurations found that every multi-agent variant degraded performance on a sequential planning benchmark by 39 to 70%, while centralised coordination improved a parallel financial-reasoning benchmark by 80.9% over a single agent (January 2026).
Agent teams go a step further: several full agents share a task list and message each other, with a lead that assigns work, instead of each helper reporting only to its caller. They suit work whose parts need discussion, and they cost the most. In Claude Code they are experimental and off by default (October 2026). The pattern underneath both is orchestrator-workers: a lead plans at run time and delegates the parts.
A2A, the Agent2Agent protocol, crosses the boundary between organisations. A remote agent publishes an agent-card that describes its skills, address and authentication; other agents send it whole tasks through one of the protocol's bindings (JSON-RPC, gRPC or HTTP with JSON) and receive status updates and results, while its internal state, memory and tools stay hidden. Version 1.0.0 is the latest released version of the specification (October 2026). The A2A project draws the line in one sentence: A2A is about agents partnering on tasks, MCP about agents using capabilities.
Which one do I need?
Start from the problem, not from the feature. The steps below match a problem to the lightest thing that solves it, and the list after them names the mistakes people make most often.
Each step asks one question; stop at the first yes. The order runs from cheapest and most predictable to most expensive, in line with the common advice to start with the simplest design and add complexity only when tests show it is needed. The talk "Tool, skill, or subagent? Decomposing an agent that outgrew its prompt" from the Claude channel is about the same choice.