Claude Skills vs MCP: When I Reach for Each

I get asked some version of “should this be a skill or an MCP server?” almost weekly now. The answer fits in a sentence: a skill is knowledge, an MCP server is a connection. A skill teaches the model a method it can follow on its own. An MCP server hands the model a live wire into a system — GitHub, Postgres, your CRM, an internal API — that it physically cannot reach without one.

If the work is “follow this procedure the way we do it here,” that's a skill. If the work is “go read this database and open a pull request,” that needs MCP. The trap is that a lot of tasks sound like they need a server when they only need instructions. That confusion costs you real money, because the two are priced completely differently the moment your session starts.

Here's the part the “what is a skill” explainers skip. Skills and MCP servers don't just do different jobs — they hit your context window at completely different times and sizes.

A skill uses progressive disclosure. At session start the model sees only each skill's name and one-line description — roughly 30 to 100 tokens apiece. The full SKILL.md body only loads when the model decides the skill is relevant. I run dozens of skills at once and the always-on cost is a rounding error: fifty skills is around 2,500 tokens of overhead, most of which the model never expands.

MCP servers work the opposite way. Every connected server injects the full schema of every tool it exposes at startup — no waiting to be asked. A well-documented tool runs 200 to 800 tokens of schema, and servers commonly ship dozens of tools. The measured reality:

Read that last row again. Seven servers can hand a third of your context window to tool definitions before the user says anything. That's context you paid for and can't use, on every single turn, whether or not any of those tools get called. I dug into this exact overhead in what MCP servers really cost in tokens, and it changed how I architect every agent since.

Reach for a skill when the task is a method, a convention, or a checklist the model can carry out with tools it already has:

• How your team writes a migration, ships a release, or formats a report.
• A repeatable content or QA workflow — the steps, the guardrails, the house style.
• Domain knowledge the model should apply consistently without you re-prompting it every session.

Reach for an MCP server when the model has to touch something outside itself:

• Read or write a real database (Postgres, Supabase) with live data.
• Act on an external service behind auth — GitHub PRs, Linear issues, Sentry, your own API.
• Pull fresh state the model has no other way to see at run time.

The single question that settles almost every case: does this need to touch a system outside the model?Yes means MCP. No means skill. A skill can hold every instruction for calling an API, but it can't make the network request — that's the line.

My production setup looks lopsided on purpose: a large library of skills and a deliberately small set of MCP servers.Skills are cheap, so I write one for anything I'd otherwise have to explain twice. Servers are expensive, so each one has to earn its slot in the context budget.

Then I let the two compose. A skill documents exactly which MCP tools to call, in what order, with what checks — and the model reads the skill, then executes through the MCP connection. The skill carries the how and when at near-zero standing cost; the server provides the execute only for the systems that genuinely need it. This is the same “keep the expensive thing on a short leash” discipline I use for cost controls on autopilot agent loops.

If you're stuck with servers you can't drop, don't just eat the tax. Anthropic's Tool Search tool loads tool definitions on demand instead of injecting every schema at startup — about an 85% token reduction in their numbers. Their code-execution-with-MCP approach goes further, taking one setup from roughly 150,000 tokens down to about 2,000. If your client supports either, turn it on — it's free context back.

People reach for an MCP server as the default and end up with five or six pinned “just in case,” then wonder why the agent feels dumber and pricier than it should. It's not dumber — it's starting every turn with a third of its working memory already spent on tool schemas it may never call. Cut the servers it doesn't truly need, move the methodology into skills, and the same model suddenly has room to think.

The flip side is real too: don't try to fake connectivity with a skill. A skill can describe your API perfectly and the model still can't reach it without a server or a tool. Knowledge isn't access. Match the tool to the job — knowledge to skills, access to MCP — and both problems disappear.

• Skill = knowledge (how to do it). MCP = connection (reach a system it can't otherwise touch).
• The deciding question: does it need to touch something outside the model? Yes → MCP. No → skill.
• Skills are near-free until used (~30–100 tokens each). MCP servers load full tool schemas upfront — 5 servers can cost ~55k tokens before you type.
• Run many skills, few servers. Let skills orchestrate the servers you do keep.
• Can't drop a server? Use Tool Search or code execution to stop loading every schema at startup.
• Knowledge isn't access — a skill can't make the network call. Match the tool to the job.

If you want the deeper token math, the companion piece is the MCP context tax, and for orchestrating the servers you keep, see how I run dozens of subagents with dynamic workflows. If you're deciding between the Agent SDK and raw API around all this, I covered that in Claude Agent SDK vs the raw Anthropic API.