MCP vs Claude Skills: When to Use Which

Use an MCP server when Claude needs to reach something it cannot otherwise touch: a board, a database, a ticketing system, anything that lives behind a login. Use a skill when Claude already has the access but needs to know how your team does a job: the steps, the checks, the format, the script that does the fiddly part. Anthropic puts it in one line in Skills explained↗ (opens in a new tab): MCP connects Claude to data; Skills teach Claude what to do with that data. Most useful setups have both, with a skill describing a procedure that calls MCP tools. If you need the protocol explained first, see what MCP is.

What a skill is

A skill is a folder with a SKILL.md file in it: YAML frontmatter with a name and a description, then instructions in Markdown, plus any scripts, templates or reference files the job needs. According to Anthropic’s Agent Skills overview↗ (opens in a new tab), skills load by progressive disclosure, in three levels.

• Metadata, always loaded: the name and description, around 100 tokens per skill. The description is what Claude matches your request against, so it has to say what the skill does and when to use it.
• Instructions, loaded when triggered: the body of SKILL.md, which the overview puts at under 5,000 tokens.
• Resources, loaded as needed: extra files are read only when referenced, and scripts are run, so only their output enters the context.

The format is not Claude-only. Agent Skills was published as an open standard, and the Agent Skills site↗ (opens in a new tab) lists the many agent products that read the same SKILL.md folders.

What an MCP server is, in one line

A program that publishes a list of tools, each with a name, a description and an input schema, which an assistant can call; a remote one also signs the assistant in and acts with the permissions of the person who connected it. The glossary entry has the rest.

Side by side

• What it adds: MCP adds capability, things Claude can now do. A skill adds procedure, how Claude should do something it already can.
• Where it runs: an MCP tool runs in the server, locally or on someone else’s infrastructure. A skill runs inside the agent’s own environment, reading files and running scripts there.
• What it can reach: an MCP server reaches whatever its operator gave it, under the identity of whoever signed in. A skill reaches only what the agent can already reach; it grants no new access by itself.
• Context cost: a connected server’s tool definitions are typically loaded into the model’s context up front, whether or not a tool is used, though some clients defer them until needed. Claude Code does by default: its tool search↗ (opens in a new tab) loads only tool names at session start and fetches the full definitions when Claude needs them. A skill costs its short description until it is triggered.
• Identity and revocation: a remote MCP connection has a token that can be scoped and revoked. A skill has no identity of its own; you remove it by deleting the folder.
• Sharing: an MCP server is shared by giving people its address. In Claude Code, a skill is shared by committing .claude/skills/<name>/SKILL.md to the repository.

When a skill is the right answer

• The job is a procedure: cutting a release, writing a migration, reviewing a pull request against your checklist.
• The output has a house style: report layouts, commit message formats, how a bug report must read.
• A deterministic script would do part of the job better than the model: validation, formatting, a calculation. The skill bundles it and Claude runs it.
• You keep pasting the same instructions into conversations. That is a skill waiting to be written.

In Claude Code, a skill can also be run directly as /name, and frontmatter such as disable-model-invocation keeps Claude from triggering a skill with side effects on its own. Anthropic’s Claude Code skills documentation↗ (opens in a new tab) covers the fields.

When MCP is the right answer

• The data lives in another system and Claude has no way in: a board, a CRM, an error tracker.
• The action needs a real identity: you need to know it was the assistant, acting for whom, and be able to cut it off.
• Permissions must be enforced by the system, not by instructions. A skill that says “do not delete tasks” is advice; a role that cannot delete tasks is a rule.
• The same tools should work in several assistants: Claude, ChatGPT, Cursor, Copilot.

Three questions that decide it

1. Can Claude already reach the thing? If not, you need an MCP server (or another way in) before any skill can help.
2. Does it matter who did it, and must you be able to switch it off? Then the access belongs in an MCP connection with its own token, not in instructions.
3. Is the problem that Claude does the job differently each time? Then write the steps down once, in a skill, and let it load when the job comes up.

If the answer to the first two is yes and the third is also yes, you want both, which is the common case for team tools.

Using them together

The two combine naturally: the MCP server gives the access, and the skill tells Claude how to use it well. Here is a skill for filing a bug on a fenbs board, using the board’s MCP tools.

---
name: file-a-bug
description: File a bug on the team's fenbs board. Use when the user reports something broken or asks to log a bug.
---

1. Call fenbs_search with the key words of the bug. If an open task matches, comment on it with fenbs_comment instead of filing a new one.
2. Otherwise call fenbs_create_item with kind "bug". Put what happens, what should happen and where (file:line or page) in note. Put the steps to fix, once known, in plan, not in note.
3. If fenbs_create_item answers created: false, read the matches it returns and follow its advice.
4. Tell the user the ref of the task you filed or commented on.

The skill holds your team’s rule about notes and plans; the server holds the tasks and decides what this caller may do. If the person who connected the assistant cannot add tasks, fenbs_create_item refuses, whatever the skill says, and the refusal names the permission that was missing. For the everyday rhythm of reading and updating a board from Claude Code, see the Claude Code task-tracking workflow.

Skills served over MCP

The line between the two is getting thinner. MCP now has an official Skills extension↗ (opens in a new tab), io.modelcontextprotocol/skills, which lets a server publish skills in the Agent Skills format through its resources, so the instructions for a service travel with the service. Its page notes that support in SDKs and host applications is still being implemented, so check your client before relying on it.

fenbs has a related idea of its own: AI context, short notes kept on the board that an assistant reads with fenbs_get_context before it starts. A skill is know-how that lives with the agent; AI context is know-how that lives with the work, so every assistant on the board reads the same notes.

A note on trust

Both are ways of letting outside content steer an agent, so both deserve the care you would give installing software. Anthropic advises using skills only from trusted sources and auditing every bundled file, because a skill can direct Claude to run tools and code. The same goes for MCP servers; see MCP security best practices.