Skills, MCP servers and subagents all get described as ways to "extend your AI agent", which makes them sound interchangeable. They are not. Each one fixes a different gap:
- A skill gives your agent knowledge and a procedure: how to do a kind of task the way you want it done.
- An MCP server gives your agent access: tools that reach a system outside the chat, like GitHub, a browser or a database.
- A subagent gives your agent a separate context: a second agent that takes a task, works on it in its own conversation and hands back a summary, and can run alongside others.
Put shortly: a skill changes what your agent knows, an MCP server changes what it can reach, and a subagent changes where the work happens.
Skills: knowledge and procedure
A skill is a folder with a SKILL.md file: a name, a description, and
instructions. Your agent holds only the description until a task matches it,
then reads the rest. The
agent skills explainer
covers the format and how loading works.
Skills are good at the things a new teammate would need telling once: your commit message format, the checklist for reviewing a pull request, the order you debug things in, how to write tests in this codebase. They can include scripts, but they add no new connection to anything. A skill can only use what your agent could already reach.
What it costs: about 100 tokens a skill until it is used, per the spec, then the instructions while it is in use.
MCP servers: access to outside systems
An MCP server is a program that gives your agent new tools, over a protocol that most AI apps now share. A GitHub server adds tools for issues and pull requests, a browser server adds tools for opening pages and clicking things. The MCP explainer walks through how a tool call works.
What an MCP server does not bring is judgement. It says what each tool does, but not when your team would want it used, in what order, or what to check afterwards.
What it costs: the app offers the model the tools from every connected server, so each server you add is more for the model to read on every turn. The MCP docs note that apps with many servers can load tools progressively instead of all at once, and some do.
Subagents: separate context and parallel work
A subagent is another agent that your main agent hands a task to. In Claude Code's words, each one "runs in its own context window with a custom system prompt, specific tool access, and independent permissions". It does the work, then returns a summary, so the searching, the logs and the dead ends stay out of your main conversation. Several can run at the same time.
Claude Code, Cursor and Codex all have them, defined as files in a project or home folder. The details differ. Codex's local apps, for instance, only start subagents when you or a skill ask for them.
Claude Code's docs suggest a subagent when a side task would flood your conversation with output you will not look at again, when you want to limit which tools a task can use, or when the work is self-contained and can come back as a summary. They suggest staying in the main conversation when the task needs a lot of back-and-forth.
What it costs: a subagent is a whole separate agent run, with its own requests to the model. You pay for it in usage even though it saves space in your main context.
Which one do you need?
Start from the problem you actually have:
| If the problem is… | Reach for | Because |
|---|---|---|
| The agent does a task, but not the way your team does it | A skill | It is missing knowledge, not access |
| You keep pasting the same instructions into the chat | A skill | Written once, loaded when the task matches |
| The agent cannot see your issues, database or browser | An MCP server | It needs a connection it does not have |
| The agent has the tools but uses them clumsily | A skill that covers those tools | Access without a procedure |
| Research or log reading fills up the conversation | A subagent | The noise stays in its context |
| You have several independent tasks at once | Subagents | They can work in parallel |
| You want a reviewer that can read but never edit | A subagent with limited tools | Tool access is set per subagent |
Two rules of thumb sit behind the table. If the agent could do the job with what it can already reach but does it badly, write a skill. If it cannot reach the thing at all, it needs an MCP server, or an ordinary command line tool it can already run.
Using them together
The most useful setups combine them. The common one is a skill that tells the agent how to use an MCP server well. Anthropic described this when it introduced skills: skills can complement MCP servers "by teaching agents more complex workflows that involve external tools and software".
Say you have connected the Playwright MCP server, so your agent can drive a browser. Left alone, it might open your page once at desktop size and call it done. A short skill fixes that:
---
name: check-ui-in-browser
description: Checks a UI change in a real browser using the Playwright MCP tools. Use after changing a page, component or stylesheet.
---
1. Make sure the dev server is running, and start it if not.
2. With the browser tools, open the page you changed at 390px wide
first, then at 1280px.
3. Read the page snapshot rather than guessing from the code.
4. Check the browser console for errors.
5. Report what you saw at each width. Do not say the change works
until you have looked at both.The server supplies the browser, and the skill supplies the checks you would have done yourself.
Subagents can hold both. In Claude Code, a subagent's file can list skills to preload and MCP servers only it can use, so a "browser tester" subagent could carry the skill above and the Playwright server, while your main conversation has neither and stays uncluttered.
Where to go next
Every entry in our AI Agents section has been read before it was listed, with install steps pinned to the version we checked:
- Agent skills, for planning, code review, frontend work and writing. The React Best Practices skill is a good example of pure knowledge: rules your agent follows while it writes code.
- MCP servers, for code, browsers, docs and more. The Context7 server is a good example of pure access: current library docs your agent can look up.
Sources
All checked on 27 September 2026.
- Agent Skills, Specification
- Anthropic, Equipping agents for the real world with Agent Skills
- Model Context Protocol, Architecture overview
- Claude Code docs, Subagents and Skills
- Cursor docs, Subagents
- Codex docs, Subagents
