Claude Skills vs MCP: Which One Do You Actually Need?

If you're weighing Claude skills vs MCP, here's the answer up front: skills teach your agent how to do things, MCP connects your agent to things. A skill is procedural knowledge — your deploy runbook, your code review checklist, your framework conventions — packaged as markdown the agent reads when it's relevant. An MCP server is connectivity — a live process that lets the agent query your database, read your issue tracker, or drive a browser. One is knowledge, the other is plumbing. They don't compete; they cover different failure modes.

The confusion is understandable. Both extend what Claude Code can do, both get "installed," and both show up in the same conversations about agent setup. But the MCP vs skills question resolves quickly once you look at what each mechanism actually puts into the model's context window — and when. That's what this post walks through, with the token math that usually settles the argument.

Claude skills vs MCP: they solve different problems

A skill is a folder with a SKILL.md file at its root — instructions, optionally alongside scripts, templates, and reference docs. It's static content. The agent reads a one-line description of every available skill, and only pulls in the full body when a task matches. If you've never read what agent skills are, start there; the short version is that they're versioned, shareable instruction packages.

An MCP server is a program that speaks the Model Context Protocol. It exposes tools (functions the agent can call) and resources (data the agent can read). When Claude Code connects to one, the server's tool definitions — names, descriptions, and JSON schemas — load into the context window so the model knows what it can call. Our MCP server explainer covers the protocol in depth.

Here's the side-by-side:

If a row in that table made your decision for you, you're done. If not, the next two sections make the split concrete.

What skills do best: procedural knowledge and workflows

Skills shine wherever the answer is "we do it like this, every time." Things like:

• Runbooks: the exact sequence for a production deploy, a database migration, or an incident postmortem
• Conventions: how API routes are structured, what a good test looks like in your codebase, naming and error-handling rules
• Workflows: your PR review procedure, your release checklist, how to scaffold a new service
• Domain knowledge: the quirks of your billing system, the invariants your data model must hold

None of that requires a live connection to anything. It's knowledge that changes rarely, applies broadly, and would otherwise live in a wiki nobody reads. A minimal skill looks like this:

---
name: deploy-runbook
description: Step-by-step production deploy procedure, including rollback
---

## Production deploy

1. Run the pre-deploy checklist in checklist.md
2. Build: `pnpm build` — abort on any type error
3. Deploy the worker, then verify /healthz returns 200
4. If verification fails, roll back with the command in rollback.md

Because skills are just files, they get the whole software lifecycle for free: they diff cleanly in code review, they version, and they roll back. Skills on localskills.sh can also be multi-file packages — docs, scripts, and templates in one folder, up to 100 MB and 500 files per version — so the runbook can ship with its checklist and rollback script instead of linking to them.

The other thing skills do that MCP can't: they work across tools. One published skill installs into Claude Code (.claude/skills/), Cursor (.cursor/rules), Windsurf (.windsurf/rules/), and other assistants in their native formats. An MCP server only helps clients that speak MCP and are configured to connect to it.

What MCP does best: live data and external tool access

Skills can't tell your agent what's in your database right now, which Sentry issues fired overnight, or what a rendered page actually looks like. That's MCP's territory:

• Live queries: read your Postgres schema, run a SQL query, inspect production data
• External systems: create a Linear ticket, comment on a GitHub PR, fetch a Figma frame
• Stateful tools: drive a browser, run code in a sandbox, tail logs
• Auth boundaries: MCP servers handle OAuth and API keys, so the agent acts with scoped credentials instead of you pasting secrets into prompts

Wiring one into Claude Code is a few lines of config:

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"]
    }
  }
}

Our Claude Code MCP guide walks through the full setup, transports, and permissions.

When to use MCP

The test for when to use MCP is simple: does the task require information or side effects that don't exist in your repo? If the agent needs to fetch something current or do something in another system, no amount of markdown will substitute. If the agent just needs to know something stable — a procedure, a convention, a standard — an MCP server is the wrong tool, and you'll pay for it in context.

Which brings us to the numbers.

Token cost: Claude skills vs MCP by the numbers

This is where the skills vs MCP servers comparison stops being philosophical. The two mechanisms have opposite cost curves.

MCP cost scales with what you install. Every connected server injects all of its tool definitions into context at session start — name, description, and a full JSON schema per tool. Exact sizes vary by server, but a typical tool definition lands in the hundreds of tokens once the schema is included. Run the rough math on a realistic setup:

• 4 servers × 15 tools each = 60 tool definitions
• 60 tools × ~500 tokens ≈ ~30,000 tokens consumed before you type your first prompt

That's context spent whether or not you call a single tool that session — and it crowds out the thing you actually care about, which is your code. We dug into this failure mode in too many MCP tools: the token bloat problem.

Skill cost scales with what you use. Skills load progressively: at session start the agent only sees each skill's metadata — its name and one-line description, a few dozen tokens each. The full SKILL.md body enters context only when the task actually matches. So:

• 40 installed skills × ~40 tokens of metadata ≈ ~1,600 tokens idle
• One relevant skill triggered ≈ a few hundred to a few thousand more, for exactly the task at hand

The asymmetry matters more as your setup grows. Installing your 41st skill costs a rounding error. Connecting your 5th MCP server can cost more context than an entire skill library. That doesn't make MCP bad — it makes MCP something you should provision deliberately, keeping only the servers whose live data you genuinely need, while procedural knowledge moves into skills where it's nearly free.

Five questions to pick the right one

Run any candidate through these in order:

1. Does the agent need data that isn't in the repo? Current tickets, production rows, live docs, rendered pages → MCP. Everything the repo and your head already contain → keep reading.
2. Would you write it in an onboarding doc for a new hire? Conventions, procedures, "here's how we do X" → that's a skill. New hires don't need a protocol; they need instructions.
3. Does the agent need to take actions in an external system? Creating issues, posting comments, executing queries → MCP. Generating code and files locally → skill.
4. How often does it change? Stable knowledge belongs in a versioned skill. Data that's stale within hours must come through a live connection.
5. Is your context window already crowded? Audit what each connected server costs versus how often you call it. If a server exists to answer questions a markdown file could answer, replace it with a skill and reclaim the tokens.

If you ended up with "both" for different parts of the same workflow, that's not a tie to break — that's the correct architecture.

Using skills and MCP together

Agent skills vs MCP isn't an either/or decision in a mature setup. The strongest pattern uses them as layers: MCP fetches, skills decide.

Concrete example: a debugging workflow. An observability MCP server pulls the stack trace and recent logs — live data no skill could contain. A debugging skill then supplies the procedure: reproduce first, bisect the change, check the error against known failure classes, write a regression test before fixing. The MCP server gives the agent eyes; the skill gives it judgment. Either one alone gets you half a workflow.

The two also compose at the distribution layer. localskills.sh is a registry for skills — publish once, install everywhere:

localskills install acme/deploy-runbook --target claude cursor windsurf

And it exposes an MCP server of its own, so agents can search and install skills over MCP with OAuth and scoped access — an MCP server whose job is delivering skills. Connectivity carrying knowledge, which is exactly the division of labor this whole comparison points to.

So: audit your MCP servers against question five, move the procedural knowledge into skills, and keep the live connections that earn their tokens. Your context window — and your agent's focus — will be noticeably better for it.

---

Ready to move your team's know-how into versioned, installable skills? Create a free localskills.sh account and publish your first skill in minutes.

npm install -g @localskills/cli
localskills login
localskills install your-org/your-first-skill