Agent Skills vs MCP Servers vs Subagents: When to Use Which

Agent Skills and MCP servers solve different problems. A skill is a folder of instructions, scripts and reference files that teaches an agent how to do a task. An MCP server is a running program that gives an agent live tools and data from another system, like GitHub, a database or your calendar. Subagents are a third thing: separate agent instances with their own context window that take on part of the work.

Short version: use a skill for know-how, an MCP server for access, and a subagent for delegation. Most real setups use more than one. The rest of this post shows how to tell them apart and how they fit together.

Quick comparison

	Agent Skill	MCP server	Subagent
What it is	Folder with SKILL.md, optional scripts and docs	A program speaking the Model Context Protocol	A separate agent with its own prompt and tools
What it adds	Procedures, context, house rules, helper scripts	Tools, resources and prompts from an external system	A fresh context window for a focused job
How it loads	Name and description at startup, body when relevant	Tool definitions listed to the model when connected	Invoked when the main agent delegates
Runs where	Inside the agent's own environment	As a local process or remote service	Inside the same host app
Typical example	Release notes style and a script to group commits	GitHub server that can list and comment on PRs	A code reviewer that only reads files
Authentication	None of its own; scripts run with whatever access the agent already has	Remote servers can use OAuth, defined in the MCP authorization spec; local servers usually read keys from env vars	Inherits the host app's credentials and the permissions you grant it
Audit and monitoring	Shows up in the agent's own transcript; there is no separate service to log	The server can log every tool call it receives; the 2026-07-28 spec documents OpenTelemetry trace context in _meta (changelog)	Its result returns to the main conversation; its own steps stay in its context
Context cost	About 100 tokens of metadata until triggered (Claude docs)	Every connected tool's definition is listed to the model	Its working context is separate, so only the result costs main-context tokens
Typical failure mode	Vague description, so it never triggers, or triggers on the wrong task	Server will not start, auth fails, or a tool description misleads the model	Returns a thin summary that misses detail the main agent needed
How it updates	Edit the files; changes apply next time it loads	Ship a new server version, then users update or the remote host redeploys	Edit its Markdown definition
Governed by	The open spec at agentskills.io	The Agentic AI Foundation under the Linux Foundation	Each host app (for example Claude Code)

What Agent Skills are for

Skills package procedural knowledge. They load through progressive disclosure: roughly 100 tokens of metadata per skill at startup, the full SKILL.md only when a task matches, and extra files only when needed. That is covered in depth in our guide to Agent Skills, and a full explainer on agent skills covers loading in detail.

Reach for a skill when the agent can already do the work but keeps doing it your way wrong:

• It writes reports, but not in your template.
• It queries your warehouse, but forgets to exclude test accounts.
• It can edit a .docx file, but needs a tested script for tracked changes.

Skills are also portable. The format is an open standard, and Claude, OpenAI Codex, GitHub Copilot in VS Code and Gemini CLI all read SKILL.md folders.

What skills do not do on their own is reach systems the agent cannot already reach. A skill can include a script that calls an API, but on the Claude API skills run with no network access, and baking credentials and API calls into a skill script is usually the wrong design.

Does installing a skill expand data access?

No, not by itself. A skill adds instructions and files, not a new connection. Its scripts run with the access the agent already has: none on the Claude API, whatever your admin settings allow on claude.ai, and the same network and file access as your user account in Claude Code (Claude docs). That last case is why a skill can still do damage: it cannot reach new systems, but it can steer the agent to misuse the ones it already reaches.

What MCP servers are for

The Model Context Protocol is an open protocol for connecting AI apps to external tools and data. An MCP server exposes tools the model can call, such as create_issue or run_query, plus resources and prompts. The client, for example Claude Desktop, Claude Code or VS Code, connects to the server and passes the tool list to the model. If you are new to this, read what an MCP server is.

Reach for an MCP server when the agent needs to:

• Read or write live data in another system.
• Authenticate to a service with its own credentials.
• Share one integration across many agents and apps.

What changed for MCP in 2026?

Two things matter when you compare MCP with skills today:

• The protocol went stateless. The 2026-07-28 revision removed the initialize handshake and protocol-level sessions, including the Mcp-Session-Id header. Each request now carries its protocol version and client capabilities, and servers MUST implement a new server/discover method that advertises their versions, capabilities and identity.
• MCP moved to a foundation. In December 2025 Anthropic donated MCP to the Agentic AI Foundation, a directed fund under the Linux Foundation.

Neither change affects skills, which are files rather than a wire protocol.

MCP servers carry their own risks. Tool descriptions themselves can carry hidden instructions, which our post on MCP tool poisoning explains. Whether the server runs on your machine or someone else's also changes the threat model, as covered in local vs remote MCP servers.

What subagents are for

In Claude Code, a subagent is a specialised assistant defined as a Markdown file with YAML frontmatter in .claude/agents/ or ~/.claude/agents/. Each one runs in its own context window with a custom system prompt, its own tool access and its own permissions. It starts fresh, does its job and returns a result to the main conversation.

Reach for a subagent when:

• A task produces a lot of noisy output, like searching a large codebase, that you do not want in your main context.
• You want a narrower tool set for one job, for example a reviewer that can read but not write.
• You want a different model or system prompt for one part of the work.

A subagent is a unit of work. A skill is a unit of knowledge. They overlap only a little.

Subagents run inside one host app. Agents that talk to other agents across vendors use protocols such as A2A.

Should I use a skill, an MCP server or a subagent?

Ask three questions in order.

1. Does the agent need access to something it cannot reach today? Use an MCP server, or an existing CLI the agent can already run.
2. Does the agent have access but do the job inconsistently? Write a skill with your procedure, examples and any fragile steps as scripts.
3. Is the job big or noisy enough to pollute the main conversation? Hand it to a subagent.

Some quick cases:

• "Claude should file Jira tickets." That is access, so use a Jira MCP server.
• "Claude should file Jira tickets with our labels, priority rules and template." Use the MCP server for access, and a skill for the rules.
• "Claude should audit 400 files for a deprecated API and report back." Use a subagent, perhaps one preloaded with a skill describing the migration.

The same job as a skill and as an MCP tool

Take one job: "summarise this week's merged pull requests." Here it is both ways.

As a skill, it is instructions plus a script that uses access the agent already has, here the gh CLI:

---
name: weekly-pr-summary
description: Summarises pull requests merged in the last 7 days. Use when the user asks for a weekly PR or changelog summary.
---

1. Run `gh pr list --state merged --search "merged:>=$(date -d '7 days ago' +%F)" --json title,number,author`.
2. Group the results by label: features, fixes, other.
3. Write one line per PR: number, title, author. No commentary.

As an MCP tool, the server owns the GitHub access and exposes one typed call:

server.registerTool(
  "weekly_pr_summary",
  {
    description: "List pull requests merged in the last 7 days for a repo",
    inputSchema: { repo: z.string().describe("owner/name") },
  },
  async ({ repo }) => {
    const prs = await listMergedSince(repo, 7); // your GitHub API call, using the server's token
    return { content: [{ type: "text", text: JSON.stringify(prs) }] };
  },
);

The skill is quicker to write and easy to change, but only works where gh is installed and signed in. The MCP tool works for any client that connects, holds its own credentials, and costs a tool definition in every session. A common middle ground is both: the MCP tool for access, and a short skill for how you want the summary formatted.

Using them together

The combinations are where these pieces get useful.

A skill that drives MCP tools

A skill can tell the agent exactly how to use an MCP server's tools. Anthropic's best practices recommend fully qualified tool names in the format ServerName:tool_name, so the agent does not pick the wrong tool when several servers are connected:

---
name: triaging-github-issues
description: Triages new GitHub issues using our label and priority rules. Use when the user asks to triage, label or prioritise GitHub issues.
---

# Triage GitHub issues

1. Use the GitHub:list_issues tool to fetch open issues without labels.
2. For each issue, choose one type label: bug, feature or question.
3. Mark as priority:high only if it mentions data loss or a security problem.
4. Apply labels with the GitHub:add_labels tool. Never close issues.

The tool names in that example depend on the server you connect. Check what your server actually exposes.

Subagents preloaded with skills

Claude Code subagents can load skills at startup with a skills field in their frontmatter. The docs say the full content of each listed skill is injected into the subagent's context:

---
name: api-developer
description: Implement API endpoints following team conventions
skills:
  - api-conventions
  - error-handling-patterns
---

Implement the requested endpoint. Follow the preloaded conventions exactly.

Skills that run as subagents

Going the other way, a Claude Code skill with context: fork in its frontmatter runs in a forked subagent context, with the agent field choosing which subagent type (Claude Code skills docs). This suits skills that do a lot of reading before producing a short answer.

Security differs by type

All three extend what an agent can do, so all three deserve review, but the risk sits in different places:

• Skills: the instructions and the bundled scripts. A script runs with whatever access the agent has.
• MCP servers: the server code, its dependencies, the tool descriptions and the credentials you give it.
• Subagents: mostly the tools and permissions you grant them.

On AgenticMart, any listing can get a free automated scan; each listing page shows its scan status. A scan runs the same checks on skills and MCP servers: static analysis, secret detection, a known-vulnerable dependency check and a sandboxed run with outbound network traffic recorded. You can check the agent skills directory or the MCP server directory before installing. No scan proves something is fully safe, so still apply least privilege to whatever you install.

FAQ

Can a skill replace an MCP server?

Sometimes. If the agent can already reach a system through a CLI it is allowed to run, a skill with clear instructions may be enough. If you need authenticated access to a remote service, a shared integration, or an environment without network access for scripts, an MCP server is the better fit.

Do skills and MCP servers work in the same apps?

Often, yes. Claude Code, VS Code and other agent tools support both. The details differ by app, so check each one's docs for where skills live and how MCP servers are configured.

Is a subagent the same as a skill?

No. A subagent is a separate agent instance with its own context window, prompt and tools. A skill is a package of instructions and files that any agent, including a subagent, can load when a task matches.

Can a skill call an MCP server?

Yes, indirectly. A skill cannot open its own MCP connection, but its instructions can tell the agent which connected MCP tools to call and in what order. Anthropic's best practices recommend naming them as ServerName:tool_name.

Which uses more context, a skill or an MCP server?

Usually an MCP server. An installed skill costs about 100 tokens until it is used, and its body loads only when a task matches. A connected MCP server lists every tool definition to the model, so a server with many tools costs context in every session whether you use it or not.

Which should I build first?

Start with a skill if your problem is inconsistent results. Start with an MCP server if the agent simply cannot reach the data or service it needs.