Agent Skills vs MCP
Skills tell Claude how to do something; MCP gives Claude access to something. They solve different problems and are usually used together.
Last verified August 21, 2026
The short answer
A Skill is knowledge — instructions and scripts Claude loads when the task calls for them. An MCP server is a connection — access to a tool or data source. If your problem is "Claude does not know our process", write a Skill. If it is "Claude cannot reach our system", stand up an MCP server.
Can you use both? Almost always. The common pattern is an MCP server that provides access to a system plus a Skill that encodes how your team uses it correctly.
Side by side
Option A
Agent Skills
Folders of instructions, scripts and resources. Loaded on demand when Claude judges them relevant. Portable across the Claude apps, Claude Code, the API and the Agent SDK.
Pick it when
The capability is procedural — a workflow, a house style, a checklist, a way of doing something that Claude could otherwise do but does wrong.
Option B
Model Context Protocol
An open client/server protocol. A server exposes tools, resources and prompts; any MCP client can use them.
Pick it when
Claude needs to read or write something outside itself — a database, a ticketing system, an internal API, a file store.
The one-line test
Does the task fail because Claude does not know something, or because it cannot reach something?
Knowledge → Skill. Access → MCP.
Most of the confusion comes from cases where the answer is both, and people pick one.
Worked example
Suppose you want Claude to triage incoming bugs in your tracker.
The MCP half: a server exposing your tracker — read issues, add comments, set labels, assign. Without it Claude cannot see a single ticket.
The Skill half: how your team triages. What counts as P1. Which labels are mandatory. That anything touching billing gets assigned to a specific team. What a good repro request looks like.
With only MCP you get generic triage against your data. With only a Skill you get a well-informed description of what Claude would do if it could see anything. Together you get the thing you wanted.
They fail differently
| A bad Skill | A bad MCP server | |
|---|---|---|
| Symptom | Claude does the wrong thing confidently | Claude cannot do the thing, or errors |
| Blast radius | Bounded by permissions | Bounded by the server’s own access |
| Fix | Edit a markdown file | Change code, redeploy |
| Risk | Wrong output | Wrong actions, with real credentials |
An MCP server holds credentials and can write. A Skill is instructions. That asymmetry is why reviewing a community MCP server matters more than reviewing a community Skill.
Where each one lives
| Skills | MCP | |
|---|---|---|
| Claude apps | Yes (Pro and above) | Yes |
| Claude Code | Yes | Yes |
| Claude API | Yes, via /v1/skills |
Yes |
| Agent SDK | Yes | Yes |
| Open standard | Yes, at agentskills.io | Yes |
Both are portable. Neither is Claude Code-specific, though Claude Code is where most people meet them.
Where plugins come in
A plugin can bundle both — skills, MCP server configuration, hooks and commands in one installable unit. If you are distributing a capability to a team, that is usually the container you want. See Plugins vs Skills.
Common misconceptions
- "A Skill can call our API." Not by itself. A Skill can contain scripts, but reaching an external system as a first-class tool is what MCP is for.
- "MCP servers teach Claude how to use them." They describe their tools, but not your conventions. Knowing a Jira server exists is not knowing how your team writes tickets.
- "Skills cost context even when unused." They do not. Claude scans available skills and loads only relevant ones — that on-demand loading is the core design decision.
- "MCP is a Claude Code feature." It is an open standard, and Claude Code is one client among several.
Sources
- 01Agent Skills announcementOfficialclaude.com
- 02Connect Claude Code to tools via MCPOfficialcode.claude.com
- 03Introducing the Model Context ProtocolOfficialanthropic.com