Why this question keeps coming up
Skills and MCP both get pitched the same way: "give Claude new capabilities." Both live in folders or config files. Both show up in the same setup guides, sometimes in the same sentence. So when you actually sit down to build something, you hit the same wall: I want Claude to do X — do I build a Skill or wire up an MCP server? Most explanations describe what each thing is without helping you decide between them. This post is the decision guide I wish existed: a clear flowchart, plus the parts other guides skip — cost and complexity trade-offs, when you need both at once, and what actually breaks when you pick the wrong one.
What a Skill actually is
A Skill is a folder. Inside it: a markdown file with instructions, maybe a script, maybe some reference files. When Claude decides a Skill is relevant to what you're asking, it reads the instructions and follows them. That's it — no server running, no network call, no auth flow. It's packaged know-how sitting next to the conversation, not a connection to anything outside it.
Concrete example: a write-release-notes Skill. Inside the folder you'd have a template for how release notes should be formatted, a short style guide ("no exclamation points, group by feature not by commit"), and a script that takes raw git log output and cleans it up. Claude reads the template and style guide, runs the script on the log data you paste in, and produces notes that match your team's format every time.
The point of a Skill isn't giving Claude something new to reach — it's teaching Claude how to do a repeatable task using stuff it already has access to.
What MCP actually is
MCP (Model Context Protocol) is how Claude talks to a running server that's connected to something live outside the conversation — a database, an API, a SaaS tool, your filesystem, a browser. Unlike a Skill, this requires real infrastructure: a server process has to be running, there's often an auth token involved, and every call is an actual network request to a system that can change.
Concrete example: a Postgres MCP server that lets Claude run real queries against your production database and see current data — not a snapshot from training, not something you pasted in, the actual current state. Or a GitHub MCP server that lets Claude open a real pull request, one that shows up in your repo and that your teammates can review.
The point of MCP is giving Claude access to something that lives outside the conversation and needs to stay current — data that changes, actions that have real-world effects, systems Claude can't see unless it connects to them directly.
The real difference: packaged knowledge vs. live access
Here's the test I actually use. A Skill answers "how do I do this task well, every time" — that's procedure, formatting, judgment calls you've made before and want repeated. MCP answers "what's happening right now, out there" or "what do I need to change, out there." One is about consistency. The other is about currency and action.
So ask: does this task only need information I can hand Claude directly — files, past examples, written instructions — and does that information stay the same between runs? If yes, it's a Skill. Does the task need data that changes (this week's numbers, current inventory, an open ticket queue) or does it need to actually do something in another system (send, create, delete, deploy)? If yes, it's MCP.
There's a security angle too, and it's not a minor one. A Skill runs inside Claude's existing sandbox — no new permissions, no credentials, nothing it couldn't already touch. An MCP server is a different animal: it needs an auth token, it needs network access, and you're deciding how much you trust that server's code with real credentials to a real system. Installing a Skill is low-stakes. Installing an MCP server is a trust decision you should treat like installing software, because that's what it is.
The decision flowchart
Sixty seconds, three questions:
1. Does this task need LIVE data or need to DO something
in another system (query, create, send, change)?
NO → Build a Skill. Stop here.
YES → Go to 2.
2. Does an MCP server already exist for this system?
(Check an MCP directory/registry first — Postgres, GitHub,
Slack, and most major SaaS tools already have one.)
ONE-OFF, never doing this again → Just do it manually,
or ask Claude to make a single tool call. Don't build
infrastructure for a task you'll run once.
RECURRING, used across sessions or by a team → Use or
build an MCP server. Go to 3.
3. On top of that live data, does the task also need
consistent formatting, judgment, or a repeatable process?
NO → MCP alone is enough.
YES → Build a Skill that calls the MCP tool. The MCP
server fetches the current data; the Skill tells
Claude how to shape, judge, and present it.
Most real workflows land on step 3. The live data and the packaged judgment aren't competing — they're two different layers doing two different jobs.
Side-by-side examples
- Writing commit messages in your team's style → Skill. Your style rules don't change between commits. No live system involved.
- Checking current AWS costs → MCP. The number is different every time you ask — there's nothing to "package," it has to be fetched live.
- Filling out a standard client onboarding doc → Skill. The template and required fields are fixed. You're handing Claude a form and asking it to fill it in the same way each time, not connecting to a live system.
- Creating a Linear ticket from a bug report → MCP. This is an action with a real-world effect — a ticket has to actually appear in Linear, assigned and visible to your team. A Skill can't reach outside the conversation to do that.
- Summarizing a PDF using your company's specific rubric → Skill. The rubric is static knowledge you already have. The PDF gets pasted in or attached — nothing about this needs a live connection, it needs consistent judgment applied the same way every time.
Notice the pattern: every Skill example involves something you could hand Claude on a piece of paper. Every MCP example involves something that changes, or something that needs to happen somewhere else.
When you need both
Most of the flowchart treats Skills and MCP as an either/or choice. In practice, the best setups use both at once. An MCP server connects Claude to your CRM — live contact records, deal stages, last-touch dates. A Skill sits on top of it and says: when you draft a follow-up email from this data, use this greeting, keep it under 150 words, mention the last thing we discussed, sign off the way I sign off. The MCP server fetches; the Skill writes.
This split also solves a problem people don't see coming: MCP server bloat. It's tempting to cram formatting rules into a tool's description field, since that's the only text Claude sees when deciding to call it. Don't. Tool descriptions should describe what the tool does, not how you want the output styled. Keep the plumbing in the server and the judgment in the Skill. You'll end up with a smaller, more stable server and a Skill file you can edit in thirty seconds without redeploying anything.
Trade-offs and what can go wrong
MCP has real costs. Someone has to run the server, rotate auth tokens, and watch for rate limits. Latency is real too — every live call adds a round trip. And if the server has write access, a bug or a bad prompt can create, change, or delete something in a real system. That's not hypothetical; it's the whole point of giving it write access.
Skills have the opposite failure mode: they go stale. A Skill is frozen knowledge. If your onboarding process changes and nobody updates the Skill file, Claude will keep confidently following the old process. Nothing warns you.
The most common mistake I see: someone builds an MCP server for a task that was really just a formatting problem. A day of engineering — auth, deployment, testing — for something a 10-minute Skill file would've solved. Before building infrastructure, ask whether the data actually needs to be live, or whether you just haven't written the instructions down yet.
And sometimes neither is the answer. A one-off task with a good prompt in the chat is fine. Not everything needs to be packaged.
Try this today
Pick one task you already do with Claude more than twice a week — a specific report format, a recurring doc type, a summary you always structure the same way. Write a one-page Skill: a markdown file with clear instructions, one good example, and a template if you have one. Use it for a week before you even think about MCP.
Only reach for MCP when you hit an actual wall — Claude needs to see or change something live, and no amount of instructions fixes that.
One line to remember: Skills teach, MCP connects. Start with teaching. It's cheaper, and it's usually enough.