Skills vs MCP vs Tools vs Subagents: Stop Conflating Them

"How do I extend my agent to do X" has at least four different right answers, and they get conflated constantly. Someone writes a bespoke tool for something an MCP server already solves once for everyone. Someone else stuffs a system prompt with knowledge that should have been a skill. The confusion is understandable, because tools, MCP, skills, and subagents all sound like "give the agent more power." But they solve four genuinely different problems, and they stack on top of each other rather than compete. Getting the distinction right is most of the battle.

The one-line version#

Each of the four answers a different question:

Primitive	It is about	In one line
Tool (function calling)	Capability	One named action the model can invoke
MCP	Connectivity	A standard protocol that supplies tools and data from outside your process
Agent Skill	Know-how	Packaged procedural knowledge for using access you already have
Subagent	Isolation	A separate context window for delegating a sub-task

Everything below is just those four rows, expanded and then combined.

Tools: one capability#

A tool is a name, a description, and a schema the model can call. The model decides per turn whether to invoke it, and either your application runs it and hands back the result, or the platform runs it for you (web search, code execution, and the like). A tool is the atomic unit that everything else is built from: it does not discover other tools, does not package multi-step instructions, and does not isolate context. It is one schema, one decision, one call.

Tools have their own scaling problem, structurally similar to the one skills solve for knowledge. Past a few dozen schemas, listing every one on every call burns context and confuses selection. The answer to that is a separate mechanism again, a tool-search capability that discovers and loads tools on demand, not skills and not MCP. Worth knowing it exists so "too many tools" does not get misdiagnosed as a skills or MCP problem.

MCP: connectivity#

MCP is an open protocol for connecting an agent to external systems: data sources, tools, and prompt workflows, all through one client-server standard instead of a bespoke integration per app-and-tool pairing. A server exposes tools, resources, and prompts; a client inside a host application connects to it. The defining property is that MCP capabilities live outside your process and are discoverable at runtime. You write a server once, and any MCP-capable host, not just yours, can use it. That reuse is the whole point: it is the fix for the many-apps-times-many-tools integration explosion.

Agent Skills: know-how#

A skill is a folder of instructions, scripts, and resources the model loads on demand through progressive disclosure. The point for this comparison is narrow and important: a skill grants no new access. It cannot reach a database it has no client for, and it cannot call an API that MCP has not connected. What it does is tell the model how to use capabilities that already exist: which tool to call first, what format to produce, what the team's convention is. The clean split is that connectivity gets the agent to the data, and the skill teaches it what to do with that data.

Subagents: isolation#

A subagent is a separate agent instance with its own context window, its own system prompt, and its own tool permissions. You reach for one when a side task would flood the main conversation with output you will never reference again: a broad codebase search, a large log dump, an isolated review pass. The subagent does that work in its own context and returns only a summary. It is not a knowledge format or a connectivity layer; it is a delegation boundary. It can carry its own tools, its own MCP access, and its own skills, but the defining property is that everything it does mid-task stays in its own window, and only the final answer crosses back.

Side by side#

	Tools	MCP	Agent Skills	Subagents
What it is	A named function plus schema the model invokes	An open client-server protocol connecting a host to external servers	A folder of procedural knowledge, loaded on demand	A separate agent instance with its own context and permissions
It is about	Capability	Connectivity	Know-how	Isolation
Scope	One function call	A whole external system, reusable by any host	One procedure or domain of expertise	One delegated task, prompt in, summary out
Reach for it when	A one-off in-app action nobody else needs	The data or tool lives outside your process and should be reusable	The knowledge is stable and reused across calls	The sub-task would flood the main conversation

They compose, they do not compete#

The mistake is treating these as a menu you pick one item from. In practice they stack. The cleanest way to see it: connectivity gets you access to the aisles, and a skill is the employee's expertise. Access to the aisles does not tell an employee which shelf to check first, what to do when an item is out of stock, or how to write up the trip afterward. That is the skill's job, sitting on top of the access connectivity already granted.

A worked example makes the layering concrete. Picture a meeting-prep workflow. A skill defines which pages to search, how to structure the output, and what sections to include. An MCP server holds the actual connection that searches, reads, and creates pages in the knowledge base. The skill identifies the relevant pages; the MCP connection retrieves them; the skill structures the documents; the MCP connection saves them back; the skill enforces the formatting standard. Notice the pattern: the connection never decides what to search for or how to format the result, and the skill never touches the external system directly. Neither substitutes for the other. The skill is useless without something to call, and the connection is dumb without instructions for what to do with what it returns.

Subagents fold into the same stack rather than around it. A subagent gets its own scoped tool access, which can include a specific set of MCP servers and skills just for that delegated task. Some runtimes even let a skill's own body run as the prompt for a forked subagent, so one of these four primitives can directly spawn another.

Reach for X when#

• Reach for a plain tool when the action is a one-off, in-app capability nobody else will reuse: send this specific notification, run this one calculation, look up this one internal ID. Write the schema, done.
• Reach for MCP when you need to connect to an external system that already has, or should have, a maintained, reusable server: a code host, a chat platform, a company database, a docs store. Especially when the data changes at runtime, needs its own auth, or more than one agent should reach it without each hand-building a client.
• Reach for a skill when the gap is knowledge, not access: your company's report format, a style guide, "always filter by date range first," a checklist you keep re-pasting. A skill cannot manufacture a connection it does not have; it makes better use of connections that already exist.
• Reach for a subagent when a chunk of work would flood the main conversation with intermediate noise you will never reference again. Delegate it, get back only the summary, optionally on a cheaper model and in parallel with others.

Put them together and a single pipeline uses all four. A main conversation dispatches a security-scanner subagent (its own context, a cheaper model) to review a diff. Inside that isolated context, the subagent calls a scan tool directly on the changed files. A security-standards skill, loaded only inside that subagent, tells it which rule categories matter and how to phrase a finding. If the team's severity thresholds live in an external tracker, the subagent reaches them through an MCP server rather than a stale copy pasted into the skill. Four primitives, four jobs, one pipeline. Remove any one and the other three do not compensate.

Gotchas, or what actually bites teams#

• Writing a bespoke tool for something MCP already solves. If more than one agent or team needs the same external system, a hand-rolled per-integration tool is the exact many-to-many mistake MCP exists to prevent. Build the server once.
• Bloating the system prompt with what should be a skill. Team conventions and report formats pasted into the prompt are billed on every call forever. That is knowledge, and knowledge is a skill.
• Modeling knowledge as a fake tool. A "tool" with no real external effect, that just carries instructions, is a skill wearing the wrong costume. It clutters the schema list and confuses selection.
• Mistaking "too many tools" for a skills or MCP problem. That is a third, separate mechanism (tool search). Do not reach for the wrong fix.
• One legitimate exception, for balance. When a tool's API is unstable and nobody else will reuse it, one developer and one integration, writing it as a skill-bundled script can beat standing up and maintaining an MCP server. MCP earns its keep through reuse across many clients, not by default.
• Handing a subagent the parent's whole toolset. A subagent's value is isolation, which includes scoping its access. Give it the specific tools, MCP servers, and skills the task needs, not everything.

Where this goes next#

If the "know-how" layer is new to you, start with what Agent Skills are and why progressive disclosure changes the math. And since a skill can bundle scripts and reference MCP servers, both of which extend what runs with your agent's privileges, read A Skill Is a Dependency That Runs Code before you install one you did not write.