Claude Code gives you at least three ways to extend it — Skills, MCP servers, and slash commands — and they overlap just enough to be confusing. People reach for an MCP server when a Skill would do, build a Skill for something that needs a real connection, and never quite know where slash commands fit anymore.
Here's the clean answer, with a decision tree you can keep.
Accurate as of June 2026. Claude Code's extension model changed meaningfully in late 2025, so older guides may describe commands and skills as separate systems.
The one-line rule: MCP is connection, Skills is instruction. An MCP server gives Claude access to an external system. A Skill gives Claude a procedure for doing a task. Slash commands are no longer a separate thing — they merged into Skills, and a "command" is just a Skill you trigger manually by name.
- MCP server = connection. Reach a database, API, GitHub, or browser. Stateful, lives in a separate process.
- Skill = instruction. A repeatable procedure or convention. Cheap (~30-50 tokens at rest), lives in
.claude/skills/. - Slash command = a Skill you fire manually with
/name. The.claude/commands/folder is now a legacy path. - Use them together: MCP connects to the system, the Skill explains how to use it correctly.
- For short always-true rules, use CLAUDE.md — not a Skill.
⚡ The 10-second decision
Before the detail, the answer most people need:
- Need Claude to reach an external system (database, API, ticketing, browser)? → MCP server.
- Need Claude to follow a procedure (code review steps, commit rules, a generation workflow)? → Skill.
- Want to fire that procedure explicitly by name? → invoke the Skill as a slash command (
/my-skill). - Just stating a short, always-true project rule? → put it in CLAUDE.md, not a Skill.
That covers 90% of cases. The rest of this article is why, and where the edge cases live.
📊 Claude Skills vs MCP vs slash commands: the comparison
| MCP server | Skill | Slash command | |
|---|---|---|---|
| What it is | Standalone program exposing tools/data over a protocol | Folder with a SKILL.md (+ optional scripts) |
A Skill triggered manually by name |
| What it gives Claude | 🔌 Connection to external systems | 📋 Instruction on how to do a task | 📋 Same — on explicit demand |
| Invocation | Tools appear as /mcp__server__tool; the model calls them |
Auto (by description) or manual (/name) |
Manual only (/name) |
| Token cost at rest | High — tool defs can hit 50k+ (Tool Search cuts ~85%) | Tiny — ~30-50 tokens until triggered | Tiny |
| Lives in | A separate process (local or remote server) | .claude/skills/ (repo or ~/.claude/) |
.claude/commands/ (legacy) → now .claude/skills/ |
| State | Stateful — real runtime access | Stateless — markdown + scripts | Stateless |
| Best for | Databases, APIs, browsers, ticketing, observability | Workflows, conventions, code review, playbooks | Explicit, repeatable entry points |
The single most important row is "what it gives Claude." Connection vs. instruction is the whole distinction. Everything else follows from it.
🔌 MCP vs Skills: connection vs instruction
This is the pair people confuse most, so it gets the clearest analogy.
MCP hands Claude a hammer. A Skill explains how to drive nails with it. (The framing comes from Anthropic's own "Skills explained" writeup and is echoed across the 2026 developer guides.)
MCP — the Model Context Protocol — is about connectivity. An MCP server is a standalone program that exposes tools, resources, and prompts over a standardized protocol, and Claude Code acts as the client that calls them. This is how Claude reaches things that live outside a markdown file: your PostgreSQL database, the GitHub API, a Slack workspace, a headless browser, your observability stack. If Claude needs to access the system in the first place, that's MCP. (Full primer: MCP servers explained.)
A Skill is about procedure. It's a folder of instructions — a SKILL.md plus optional helper scripts — that Claude loads dynamically when relevant. It encodes how to do something: "when querying our database, always filter by date range first," "format reports with these formulas," "run the security review in this order." No server, no API, no runtime state. (Full primer: Claude Skills explained.)
The "use both" pattern
The cleanest mental model is to stack them:
MCP server → connects Claude to your Postgres database (the hammer)
Skill → "query orders: always filter by date range,
never SELECT *, cast money as decimal" (how to swing it)
MCP supplies the capability. The Skill supplies the judgment. Wire them together and Claude both can query your database and knows how to do it the way your team expects.
⌨️ Skills vs slash commands: they're the same thing now
Here's the part most older guides get wrong. In 2026, slash commands merged into the Skills system. They are no longer separate mechanisms.
The .claude/commands/ folder still works — it's supported as a legacy path — but the canonical location is now .claude/skills/ for project skills and ~/.claude/skills/ for global ones. A file you'd once have called a "custom slash command" is now just a Skill.
What actually changed is that Skills gained auto-invocation, which commands never had. There are now two modes:
- User-invocable — you type
/skill-nameand it runs. You control exactly when it fires. (This is the old "slash command" behavior.) - Auto-invocable — Claude reads the Skill's
descriptionfield and decides whether to invoke it based on the task at hand.
So the practical question isn't "Skill or command?" — it's "should this fire automatically, or only when I ask?"
- Want an explicit, repeatable terminal entry point you trigger by hand? Write the Skill to be manual (
/deploy-check,/changelog). That's your "slash command." - Want Claude to apply a richer workflow on its own when the context matches? Write a clear
descriptionand let it auto-invoke.
# .claude/skills/security-review/SKILL.md
---
name: security-review
description: >
Use when reviewing code that touches auth, secrets, or user input.
Auto-invoke on PRs labeled "security".
---
# the procedure Claude follows...
That description field is the whole game: write it for a human deciding relevance, because that's effectively what Claude does with it.
🌳 The decision tree
Pin this. It resolves nearly every "which one?" question.
What do you need Claude to do?
│
├─ Reach an external system (DB, API, GitHub, browser, tickets)?
│ └─ YES → MCP server (connection, stateful)
│
├─ Follow a repeatable procedure or convention?
│ ├─ Should Claude apply it automatically by context?
│ │ └─ YES → Skill, auto-invoked (write a good description)
│ └─ Fire it explicitly by name?
│ └─ YES → Skill, manual → your "slash command" (/name)
│
└─ State a short, always-true project rule?
└─ → CLAUDE.md (not a Skill)
🧩 Where CLAUDE.md, subagents, and hooks fit
To fully clear the fog, here are the three neighbors that round out Claude Code's extension model. You'll see them in the same conversations.
| Mechanism | What it's for | Reach for it when |
|---|---|---|
| CLAUDE.md | Short, always-true project conventions | The rule should apply to every turn, no triggering needed |
| Subagent | An isolated context window for a side task | A deep search or audit would clutter your main thread with noise you won't reuse |
| Hook | Deterministic scripts on lifecycle events | You need guaranteed behavior on file edits, tool calls, or session start — not "Claude usually remembers" |
The quick contrast: a Skill plays out inside the main thread so you can see and steer each step; a subagent runs off to the side and returns a summary; a hook fires deterministically whether the model likes it or not. For background on keeping all of this lean in context, see context engineering for AI coding agents.
🚫 Common mistakes
- Building an MCP server for static knowledge. If the information fits in a markdown file and doesn't need live access, it's a Skill. An MCP server for "our coding conventions" is over-engineering.
- Cramming procedures into MCP tool descriptions. Tool descriptions should say what a tool does, not encode your whole workflow. Put the workflow in a Skill.
- Connecting every MCP server you can find. Tool definitions are expensive in context — many connected servers can burn 50k+ tokens before you've done anything. Connect what you use; lean on Tool Search for the rest.
- Treating CLAUDE.md as a dumping ground. If a rule only applies sometimes, it belongs in an auto-invoked Skill with a precise
description, not in the always-loaded CLAUDE.md. - Still maintaining
.claude/commands/. It works, but new work should live in.claude/skills/. One system, two invocation modes.
Frequently Asked Questions
What is the difference between a Claude Skill and an MCP server?
MCP is connection; Skills is instruction. An MCP server gives Claude access to an external system (a database, an API, GitHub). A Skill gives Claude a procedure — how to do a task. Use MCP to reach a tool, a Skill to explain how to use it. They're complementary, not competing.
What is the difference between Claude Skills and slash commands?
As of 2026 they're the same mechanism — slash commands merged into the Skills system. The .claude/commands/ folder still works as a legacy path, but the canonical location is .claude/skills/. The practical difference is invocation: a "command" is a Skill you trigger manually by name, while a Skill can also auto-invoke when its description matches the task.
When should I use an MCP server instead of a Skill?
Use an MCP server when Claude needs stateful access to a system you can't put in a markdown file — a database, ticketing tool, browser, or live API. Use a Skill when you're encoding a repeatable procedure or convention that lives with your repo, like a code-review workflow or commit rules.
Do Skills and MCP servers cost the same in context tokens?
No. Skills are cheap — roughly 30-50 tokens each at rest, with the full body loaded only when triggered. MCP tool definitions can consume 50k+ tokens when many servers are connected, though Anthropic's Tool Search reduces that by about 85% via on-demand discovery.
Can I use Claude Skills and MCP together?
Yes, and you often should. A common pattern: an MCP server connects Claude to your PostgreSQL database, and a Skill tells Claude how to query it correctly — "always filter by date range first, never SELECT *." MCP supplies the connection, the Skill supplies the procedure.
🚀 What's Next
- 🧭 Memorize the rule: MCP is connection, Skills is instruction, commands are manual Skills. It settles most arguments.
- 📋 Write your first Skill: start with a manual one (
/changelog) then add adescriptionto make it auto-invoke — see Claude Skills explained. - 🔌 Connect your first MCP server: wire up GitHub or Postgres — see MCP servers explained.
- 🗂 Move legacy commands: migrate
.claude/commands/files into.claude/skills/and decide auto vs. manual for each. - 🧹 Keep it lean: audit how many MCP servers you actually call — token cost adds up fast.
Related reading: Claude Skills Explained: The Complete Guide · MCP Servers (Model Context Protocol) Explained · The CLAUDE.md Standard
Standardizing how your team extends Claude Code — and not sure where to draw the line between Skills, MCP, and CLAUDE.md? Get in touch; we help engineering teams set up AI tooling that's consistent, lean, and actually maintained.