Claude Skills vs MCP vs Agents: What's the Difference?

Skills, MCP servers, and agents are three different layers of the Claude stack. Here is how they compare, how they work together, and when to use each.

What is the difference between Claude skills, MCP, and agents: a comparison table from the post
What is the difference between Claude skills, MCP, and agents

Claude skills, MCP, and agents are three different layers of Anthropic’s Claude stack. Skills are folders of instructions and scripts that teach Claude a repeatable procedure. MCP is an open protocol that connects Claude to external tools and data. Agents are autonomous Claude instances that plan and execute multi-step work. They work together, not instead of each other.

Most pages that rank for this comparison describe the three from a distance. They name the layers and never open the files. My stack runs on all three, and the AI SEO team that wrote this post is built from those same layers. This is the plain version, with the actual artifacts: a real SKILL.md, a real MCP server entry, and a real subagent definition.

TL;DR

  • Skills carry knowledge. MCP carries tool connections. Agents carry multi-step work.
  • A skill is a folder with a SKILL.md file. An MCP server plugs outside data and tools into Claude. A subagent is a Claude instance in its own context that returns only a summary.
  • Start with a skill. Add MCP when the job needs live data or other software. Add a subagent when one job floods the conversation.
  • All three are layers of one stack. They work together, not instead of each other.

What is the difference between Claude skills, MCP, and agents?

The difference is the kind of thing each layer contributes. A skill contributes knowledge, how to do a task. An MCP server contributes access, which outside tools and data Claude can reach. An agent contributes action, which multi-step job to run and in what order. They are separate layers that stack.

The confusion is fair. All three change what Claude does, all three live in config folders inside your home directory, and all three arrived in the same era of Claude. The tidy split is knowledge, access, and action.

Skill MCP server Agent (subagent)
What it is A folder with a SKILL.md file plus optional scripts and resources A program that exposes tools and data over the Model Context Protocol A Claude instance in its own isolated context
What it contributes Knowledge and procedure Access to outside data and software Planning and multi-step execution
Where it lives ~/.claude/skills/ or .claude/skills/ A host config such as .mcp.json .claude/agents/ or ~/.claude/agents/
When to reach for it A repeatable job done the same way every time A job that needs live data or outside accounts A job with many steps or a heavy context
What it does not replace A data connection. It teaches procedure, it does not hold accounts A playbook. It exposes tools, it has no opinion on how you work Knowledge or access. It plans, then returns a summary

Two of the three are files you can open. The third, the agent, is the only one that acts on its own.

Skills carry knowledge. MCP carries access. Agents carry action. That split decides every other difference.

What are Claude skills?

A Claude skill is a folder with a SKILL.md file at its root. YAML frontmatter requires two fields, name and description, and the body below is plain markdown instructions. Scripts, references, and assets sit in optional folders beside the main file. The skill loads when a task matches its description.

Personal skills live in ~/.claude/skills/ and project skills in .claude/skills/, one folder per skill, per the Claude Agent Skills documentation. The mechanism is progressive disclosure: Claude reads the description up front and loads the full file only when a task needs it, instead of consuming context for every skill you have installed.

Here is the frontmatter of the skill that wrote this post:

---
name: seo-copywriter
description: Turn a content brief into a full blog post in Content-Capsule format, voice-clean, source-cited, ready for the Publisher. Use when the goal is to write the post from this brief.
---

Write the post as content capsules. Every section opens with a 20 to 50 word answer. Cite every factual claim. Never fabricate experience.

That file carries the format rules. The agent brings the writing, the file brings the procedure, and that is the entire idea of a skill.

Claude Code skills follow the Agent Skills open standard at agentskills.io, so the same folder works in any tool that adopts it, which the standard’s own site describes as a growing number of agent products. Anthropic publishes a skills repository with a template-skill you can copy, and both claude.ai and the Claude API support Agent Skills.

Custom commands have merged into skills. A skill fires automatically when the description matches, or on demand when you type /skill-name, and frontmatter can pull in live data, which the Claude Code skills docs call dynamic context injection.

Security is the part most explainers skip. A skill grants Claude new capabilities through instructions and code, and a malicious skill can direct Claude to invoke tools or execute code. The skill security guidance is blunt: trust only skills you created yourself or obtained from Anthropic, and audit the SKILL.md, scripts, images, and other resources of anything from an unknown source before it runs.

Mine are working files, not exhibits. Every skill I ship started as a procedure I was tired of repeating, and they all live in the skills bundle: all skills for $99, and the bundle keeps growing. The full mechanics of loading sit in what Claude Code skills are, and the build walkthrough is in how to create a Claude skill.

The AutomateReal skills page AutomateReal skills

A skill is knowledge on disk. It makes Claude good at a task Claude already has the tools to do.

What is MCP (the Model Context Protocol)?

MCP is an open standard from Anthropic, released on November 25, 2024, for connecting AI systems to data sources. Its architecture has three layers: the host application, the client that keeps a connection, and the server that exposes tools, resources, and prompts. David Soria Parra and Justin Spahr-Summers created it.

Anthropic introduced MCP in the Model Context Protocol announcement as a universal standard that replaces fragmented integrations with a single protocol. It ships with the specification, TypeScript and Python SDKs, and local MCP server support in the Claude Desktop apps.

MCP follows a client-server architecture with three participants, per the MCP architecture docs. A host is the AI application itself, such as Claude Desktop or Claude Code, or a custom app built on the Claude Agent SDK. A client keeps one connection to one server. A server exposes what Claude can use, and the protocol defines the primitives it can expose: tools, resources, and prompts.

A real server entry is smaller than people expect. This is the minimal shape in a host config:

{
  "mcpServers": {
    "site-data": {
      "command": "node",
      "args": ["/srv/site-data-server/index.js"]
    }
  }
}

The most common mistake I see is putting a procedure inside an MCP server. A server gives Claude a tool. It does not teach Claude how you want the job done. In my own stack the split is visible: the research agent uses a live search connection to fetch pages, and the skill file tells it how to verify a source. Fetching is the server’s job. Judging is the skill’s job.

MCP is a plug, not a playbook. It decides what Claude can touch, never how Claude should work.

What are Claude agents and subagents?

An agent is a Claude instance that plans and runs multi-step work. A subagent works in its own isolated context, takes a single job, and returns only a summary. Claude Code ships two built-ins, Explore and Plan, and custom subagents are files in .claude/agents/ or ~/.claude/agents/.

Each subagent starts with a fresh context window. It does not see your conversation history, the skills you already invoked, or the files Claude already read. It returns only the summary, and that is the point: per the Claude Code subagents docs, use one when a side task would flood the main conversation with results you will not reference again.

The two built-ins cover the common cases. Explore is a fast read-only agent for searching and analyzing codebases. Plan is a research agent that gathers context during plan mode before a plan is presented. Both skip your CLAUDE.md files and the parent session’s git status to stay fast and cheap.

Subagents scale two ways. They run in parallel, each exploring its own area before Claude synthesizes the findings, and Claude can spawn and supervise a coordinated team of sessions, which the docs call agent teams. There is a practical budget too: when combined custom subagent descriptions exceed 15,000 tokens, Claude Code warns at startup. Trim descriptions and move detail into the system prompt.

The team that wrote this post is this pattern. I built it as five agents: researcher, planner, copywriter, reviewer, publisher, each in its own context, each handing a summary to the next stage. The copywriter never sees the raw keyword research. The publisher never sees the draft decisions. Isolation keeps every job clean, and that is the reason agents exist.

A subagent’s whole value is isolation. The work happens away from your main context, and only the summary comes back.

When should you use a skill, an MCP server, or an agent?

Start with a skill. A repeatable job with a known procedure wants a folder of instructions. Add an MCP server when the job needs live data or other software. Add a subagent when one job floods the context. Three test questions pick the layer, and most automations stop at one or two.

Ask the three questions in order:

  • Is the job repeatable, with steps you already know? That is a skill. Typed it once, it stays a prompt. Typed it twice this week, it becomes a skill.
  • Does it need data or actions outside Claude? That is an MCP server.
  • Does it flood the conversation, or run long and messy? That is a subagent.
When the job is… The layer is…
A procedure you repeat the same way a skill
Needing live data, accounts, or other software an MCP server
Long, messy, or flooding the main context a subagent

The automation that changed my week was follow-up on autopilot. My own outreach system lands around 200 form submissions a day, and the follow-up runs as skill files. No agent fleet, no server farm. The first combination I would ship to a small business is the same shape: one follow-up skill, one connection to the tools they already use, and zero agents until the queue proves it needs a nightly worker.

The mismatches are where people burn time. The most common one I see is procedural knowledge in an MCP server, or a one-off tool wired when a skill would do. A server that encodes one procedure cannot be reused. A skill that needs live data cannot finish its job.

Knowledge goes in the folder. Access goes in the server. A job becomes an agent only when it outgrows my attention. The reverse happens too: a skill cannot fetch a live page, so my research step needs both the skill file and the connection. Neither replaces the other.

Most of the time the right answer is a skill. Add a layer only when the job proves it needs one.

How do skills, MCP, and agents work together?

They stack. A subagent plans the job, loads the skill that teaches the procedure, and calls the MCP servers that reach the outside world. Each layer does the one thing it is good at. One skill and one server can serve many agents, and none of the layers conflicts with the others.

This post is the workflow. The team that wrote it runs on all three layers at once:

  1. The researcher agent searches the live web through its connection and hands a research pack to the planner.
  2. The planner agent turns the pack into a brief.
  3. The copywriter agent loads the seo-copywriter skill, which carries the format and voice rules in a SKILL.md file.
  4. The reviewer agent checks the draft against the checklist.
  5. The publisher agent ships the post.

Every stage is a subagent in its own context. Every stage loads the skill file for its job. The research stage reaches the outside world through a connection. Agent, skill, server, in that order, on every post.

The official docs do the same in miniature. Claude Code’s own skills documentation runs a research skill using the Explore agent, so one skill and one built-in subagent replace a whole manual research loop.

The shape transfers to a small business too. A follow-up skill writes the message. A connection brings new leads in from the web form. A nightly subagent works the queue while the owner sleeps. I would ship that combination before anything bigger.

The AutomateReal services page AutomateReal services

The layers never compete. They divide the work: knowledge in the skill, access in the server, execution in the agent.

For a managed version, see the skills bundle.

FAQ

Is a Claude skill the same as a prompt or a slash command?

No. A prompt is an instruction you type once. A slash command is a skill you invoke by name. Custom commands have merged into skills, but a skill is a folder with instructions, scripts, and resources, and a prompt is not a file at all.

That merge is official, per the Claude Code skills docs: a skill and an old command file can share a trigger, and the skill wins.

Where are Claude Code skills stored on disk?

Personal skills live in ~/.claude/skills/ and project skills in .claude/skills/, one folder per skill with a SKILL.md file at its root. Claude Code watches those folders, so edits land in the current session without a restart, unless you created a brand-new top-level skills directory.

The split is access control in practice: personal skills reach every project, project skills stay inside one repository, per the Claude Agent Skills documentation.

Do skills work with Claude Code subagents?

Yes. Claude Code can run a skill inside a subagent, so the skill’s instructions execute in their own isolated context instead of the main conversation. The docs’ own example runs a research skill with the Explore agent, and the context: fork frontmatter field makes the split explicit.

A forked skill is the right home for long or messy jobs, because the run never bloats the session that ordered it. See run skills in a subagent in the Claude Code docs.

What is the SKILL.md format for a Claude skill?

YAML frontmatter at the top, markdown instructions below. The frontmatter requires two fields: name, a unique lowercase identifier, and description, a complete statement of what the skill does. Optional scripts, references, and assets folders sit beside the file. Anthropic’s template-skill shows the exact shape.

The contract is public: Anthropic’s skills repository states the frontmatter requires only those two fields.

Do I need MCP to use Claude skills?

No. A skill is a folder on disk. It loads on its own with no server, no connection, and no MCP config anywhere. MCP is a separate layer that adds live tools and data. Start with skills alone, and add a server only when the job needs something from outside Claude.

The Claude Agent Skills docs describe skills as filesystem-based, which is exactly why they need nothing else to run.


If you want help finding that first workflow, a discovery call maps it in about thirty minutes.