Two things that get lumped together
If you've spent time around Claude Code, Cursor, or any other agentic coding tool recently, you've heard MCP and Agent Skills compared as if they're rival options: "should we build an MCP server or write a skill?" They get compared because both extend what an agent can do. But they solve different problems, and understanding the difference will save you from building the wrong thing.
Model Context Protocol (MCP) is a protocol for connecting an agent to external systems. Agent Skills are folders of instructions the agent reads from disk. One is infrastructure. The other is a file. MCP isn't the only other mechanism people conflate with skills, either. See Agent Skills vs Subagents and Agent Skills vs AGENTS.md for the other two comparisons that come up just as often.
What MCP actually is
MCP is a protocol, a defined way for an agent to talk to a server. An MCP server exposes tools, resources and prompts over a wire protocol, and the agent calls into it the way an API client calls an API. To use an MCP server, you need the server itself running somewhere, and you need to configure your agent to connect to it.
That's the whole shape: a server process on one side, a wire protocol in the middle, an agent on the other. If the server goes down, the tools it exposed go away with it. If you want the agent to see new capabilities, you write server-side code, redeploy the server, and reconnect.
That's exactly the right shape for a specific kind of problem: giving an agent live access to something outside its own context. Query a production database. Call an internal API. Read live rows out of a CRM. These are things a static file cannot do, because the data changes and the access needs live credentials, live connections, and a live process to broker them.
What an agent skill actually is
A skill is a folder containing a SKILL.md file: YAML frontmatter with a name and description, followed by a markdown body of instructions. It can optionally bundle scripts/, references/ and assets/ subfolders. That's the entire mechanism. No server, no protocol, no process to keep alive.
An agent discovers skills by reading their frontmatter at session start, cheap, because it's just a name and a short description. When a request matches a description, the agent loads that skill's full body into context. This is progressive disclosure, and it's why an agent can have hundreds of skills installed without the context window filling up before a single message is sent.
A skill doesn't give an agent a new capability in the MCP sense. It gives the agent knowledge and procedure: how your team reviews a pull request, the exact structure your company uses for a pitch deck, the steps to run before shipping a release. It's the same kind of thing as handing a new hire a well-written internal wiki page, except the agent actually reads it before doing the task instead of skimming it once during onboarding.
Agent Skills vs MCP at a glance
| Agent Skills | MCP | |
|---|---|---|
| What it is | A folder of markdown instructions on disk | A protocol connecting an agent to a server |
| Requires | Nothing running — just files | A running server process, plus configuration |
| What it gives the agent | Knowledge and procedure — how to do something | Capability — access to something external |
| Discovery | Automatic, via name + description matching | Explicit — you configure which servers to connect |
| Authoring | Write a markdown file | Build and host a server |
| Versioning | A folder in a git repo | A deployed service |
| Portability | Same folder works across Claude Code, Codex CLI, Cursor and more | Depends on the agent's MCP client support |
| Cost to install a hundred of them | Small — only names and descriptions load by default | One running (or reachable) server per integration |
The real distinction: capability vs procedure
The cleanest way to hold this in your head: MCP answers "can the agent reach X?" Skills answer "does the agent know how to do X well?"
An agent with an MCP connection to your database can run a query. Whether it runs the right query, formats the output the way your team expects, or knows to check for soft-deleted rows first. That's procedure, and procedure is what a skill encodes.
This is also why the two compose instead of competing. A skill's instructions can tell an agent to use an MCP tool as part of a documented process. The skill doesn't replace the MCP server. It wraps expertise around it.
A worked example: a skill that calls an MCP tool
Imagine your team already has an MCP server configured that exposes a query_database tool. Without a skill, an agent with that connection can technically run any query you ask for, but it has no idea about your schema conventions, which tables are safe to touch, or how your team likes results formatted. A skill fixes that:
db-report-skill/
├── SKILL.md
└── references/
└── schema-notes.md
---
name: db-report-skill
description: Use when the user asks for a usage report, revenue breakdown, or any query against the production analytics database.
---
# Database Report Skill
## Workflow
1. Use the `query_database` MCP tool to run read-only queries against the analytics schema.
2. Never query the `raw_events` table directly. Join through `events_clean` instead; see references/schema-notes.md for why.
3. Always filter out rows where `is_test_account = true`.
4. Return results as a markdown table, sorted by the most relevant date column descending.
5. If a query would scan more than 30 days of `raw_events`, ask the user to confirm before running it.
## Constraints
- Do not run any query containing INSERT, UPDATE, DELETE, or DROP.
- If the MCP tool is unavailable, say so. Do not guess at numbers.
The MCP server does the reaching. The skill does the knowing. Neither replaces the other. The skill is worthless without the live connection, and the connection is dumb without the procedure wrapped around it.
When to reach for MCP
Reach for MCP when the agent needs live access to something outside its own knowledge and outside the files in front of it: a database, an internal API, a SaaS product's data, a ticketing system. If the honest test is "the agent can't do this without talking to a system that changes underneath it," you need a server, and that means MCP.
MCP is the wrong tool when what you actually want is consistency of behaviour. Standing up a server to enforce "always write commit messages in this format" is a lot of infrastructure for something a markdown file does for free.
It's also worth being honest about when MCP is overkill even for external data. If the data is a static export (last quarter's pricing sheet, a fixed reference table, a one-time dump someone handed you) a skill bundling that file in its references/ folder can serve it just as well, with none of the operational overhead of a server. MCP earns its complexity specifically when the data changes underneath you and a stale snapshot would be wrong.
A second worked example: customer support
The database example above is deliberately narrow. The same pattern shows up anywhere an agent needs both live access and a documented process for using it well. Consider a support team whose agent is connected to an MCP server exposing get_ticket and update_ticket tools against their ticketing system.
Without a skill, an agent with that connection can technically read and update any ticket, but nothing tells it how the team actually wants tickets handled, what counts as a valid resolution note, when to escalate instead of closing, or which fields are mandatory before a ticket can move to "resolved." A ticket-triage skill wraps that:
---
name: ticket-triage
description: Use when the user asks to triage, respond to, or close a support ticket.
---
# Ticket Triage
## Workflow
1. Use the get_ticket MCP tool to pull the full ticket, including prior replies.
2. If the ticket mentions billing, security, or data loss, escalate. Do not close it yourself.
3. Before calling update_ticket to resolve, confirm the resolution note explains what was done, not just that it was done.
4. Never close a ticket with no reply on it.
Again, the MCP connection is what makes any of this possible at all. The skill is what makes it match how the team actually works.
When to reach for a skill
Reach for a skill when you need to encode expertise, process, or style, something the agent could technically already do, but not the way you want it done, or not without being told the specific steps every time. Code review conventions, report formats, brand voice, a checklist your team runs before every deploy: all of that is procedure, and procedure belongs in a skill.
Skills are also the right call when the barrier to entry matters. Writing a skill means writing a markdown file. Writing an MCP server means writing and hosting a service. If you want something your whole team, or the wider internet, can pick up and use in minutes, a skill is dramatically cheaper to produce, share, and keep current. That's part of why the skills CLI exists: npx skills add owner/repo/skill installs a skill in seconds, with no server to stand up.
Which should you use?
Ask these questions in order:
- Does the agent need to reach a live, external system it doesn't already have access to? If yes, you need MCP, or an existing MCP server someone else built.
- Does the agent need to do something it can already technically do, but consistently, correctly, or in your team's style? If yes, write a skill.
- Does it need both? Very common, connect or build the MCP server for access, then write a skill that tells the agent how to use it well. See the worked example above.
- Is this a one-off instruction for a single conversation? Then you probably need neither, just ask.
A useful shortcut: if the thing you're building would be a REST endpoint, it's MCP. If it would be a paragraph in an onboarding doc, it's a skill.
Common mistakes
Building an MCP server to enforce style or process. This is the most common overreach. If there's no external system involved, you don't need a server. You need a well-written SKILL.md.
Expecting a skill to fetch live data. A skill is static markdown loaded from disk. It has no network access of its own. If the instructions say "check the current stock price," the skill needs an MCP tool, or another tool, to actually go get it, the skill just tells the agent when and how to use it.
Assuming MCP tool descriptions are self-explanatory enough. Tool descriptions in MCP tend to be terse, built for machine matching rather than teaching a process. A skill that wraps a few MCP tools with real workflow guidance (order of operations, edge cases, output format) is often the difference between an agent using a tool correctly and using it badly.
Skipping the review step. Whether it's a skill or an MCP server, you're granting an agent new reach with your permissions. Read a skill's SKILL.md and any bundled scripts before installing it, the same way you'd review an MCP server's source before pointing credentials at it. See the security guide for a fuller checklist.
They compose, they don't compete
The single most useful thing to take from this comparison: MCP and skills sit at different layers, and the strongest agent setups use both deliberately. MCP builds the plumbing. Skills teach the agent how to use the plumbing well. If you're only reaching for one of the two, there's a good chance you're missing the other half of the picture. Check what agent skills are for the fuller picture of what a skill can encode, and browse the skills directory for examples already built around common MCP-connected workflows.
