Field notes

MCP servers vs skills: which one do you actually need?

Every conversation about extending a coding agent eventually hits the same fork: should this be an MCP server or a skill? The two get lumped together as “ways to make Claude do more”, and that framing causes real mistakes: MCP servers installed to teach workflows, skills written to fake API access. They solve different problems, and once you see the line between them, the choice is usually obvious.

The short version: MCP gives your agent access it doesn’t have. Skills give it knowledge it doesn’t have. A skill can’t connect you to your issue tracker, and an MCP server can’t teach the agent your deployment checklist.

What each one actually is

MCP (Model Context Protocol) is an open standard for connecting AI applications to external systems. The official docs describe it as “a USB-C port for AI applications”. An MCP server is a program (local over stdio, or remote over HTTP) that exposes three kinds of primitives to the agent: tools (executable functions like running a query or creating an issue), resources (data sources like file contents and records), and prompts (reusable templates). Under the hood it’s JSON-RPC with capability negotiation, and each tool ships a name, description, and JSON schema that the model reads to decide how to call it.

MCP stopped being an Anthropic project in December 2025, when it was donated to the Linux Foundation’s newly formed Agentic AI Foundation, co-founded by Anthropic, Block, and OpenAI, with Google, Microsoft, and AWS behind it. At donation time there were over 10,000 active public MCP servers and 97M+ monthly SDK downloads. It is, for practical purposes, the standard for agent connectivity: ChatGPT, Cursor, Gemini, and Copilot all speak it.

A skill is almost embarrassingly simpler: a folder with a SKILL.md file in it. YAML frontmatter (a name and a description) plus a Markdown body of instructions, optionally alongside scripts/, references/, and assets/ directories. No server, no protocol, no process. The agent reads the description at startup, and loads the full instructions only when a task matches.

Skills went through the same standardization arc as MCP, just faster: announced by Anthropic in October 2025, published as an open standard at agentskills.io that December. The client list now includes OpenAI Codex, Gemini CLI, GitHub Copilot, Cursor, and a few dozen others.

If you’ve read my post on Claude Code agents, the pattern rhymes: these are both mechanisms for packaging capability, and the interesting decisions are about context.

The context-window math

Here’s the part that should actually drive your decision, because the two have wildly different cost profiles.

MCP tools are (traditionally) paid for upfront. Every connected server’s tool definitions historically loaded into context at session start, whether you used them or not. Anthropic’s own engineering team flagged the problem: tool definitions “occupy more context window space, increasing response time and costs”, and intermediate results flow through the model repeatedly. Their code-execution-with-MCP experiment is the famous number: an agent workflow that cost 150,000 tokens as direct tool calls dropped to 2,000 tokens when restructured, a 98.7% reduction. Claude Code has since mitigated this with tool search (only names load at startup; full definitions load on demand), but a fat MCP server is still a real tax. GitHub’s official server ships 70+ tools; Notion’s docs literally tell you to watch /context.

Skills are lazy by design. The spec calls it progressive disclosure, in three levels:

  • Level 1 is the name and description: ~100 tokens per skill, always loaded. This is the entire standing cost.
  • Level 2 is the full SKILL.md body: under 5,000 tokens recommended, loaded only when the skill triggers.
  • Level 3 covers bundled scripts and reference files: effectively unlimited, because scripts are executed, not read. A skill can ship a 500-line Python script and the agent runs it without a single line entering context. Only the output comes back.

That third level is the underrated one. A skill isn’t just a saved prompt; it’s a place to put deterministic code for the steps that don’t need a model at all. As Anthropic puts it, because code is deterministic, “this workflow is consistent and repeatable”.

One honest caveat: skills aren’t free once triggered. The loaded body stays in context for the rest of the session. Lazy loading, not free loading.

So which one do you need?

The rule of thumb straight from the Claude Code docs, which matches my experience exactly:

  • Reach for MCP when you keep copying data into the chat from another system: an issue tracker, a monitoring dashboard, a database. That’s an access problem. No amount of instructions will give the agent your Sentry stack traces.
  • Reach for a skill when you keep pasting the same instructions: a checklist, a multi-step procedure, a set of conventions. Or when a section of your CLAUDE.md has quietly grown from facts into a procedure. That’s a knowledge problem, and running a server to solve it is wasteful.

Some sharper tests for the gray areas:

  • Does it need auth? If the capability requires OAuth, an API key, or a live connection, it’s MCP. Skills have no auth story; they’re files.
  • Would it work offline? If yes, it’s probably a skill. Formatting conventions, migration recipes, review checklists, code generators: none of these need a server.
  • Is the “integration” really just an API you could curl? Then consider a skill with a script. A scripts/fetch-report.sh costs zero standing tokens; the equivalent MCP server costs tool definitions in every session. For simple, stable, low-frequency calls, the skill wins.
  • Do you need the model to compose operations dynamically? Querying, filtering, cross-referencing live data in ways you can’t predict: that’s what MCP’s tool schemas are for.

The pattern that actually wins: skills on top of MCP

The framing “MCP vs skills” undersells the good news: they compose, and the combination is better than either alone.

MCP connects the agent to a system, but it says nothing about how to use it well. Your GitHub MCP server exposes create_pull_request; it doesn’t know your team requires linked issues, a changelog entry, and a specific label taxonomy. That’s procedure, which is skill territory. Anthropic describes skills as complementing MCP precisely by “teaching agents more complex workflows that involve external tools”, and in Claude Code a skill’s allowed-tools frontmatter can pre-approve specific MCP tools, so the workflow doesn’t even generate permission prompts.

So the working pattern in 2026 looks like this:

  1. Pin one MCP server per external system you genuinely need live access to, and be stingy. Each one has a context cost and an attack surface.
  2. Write thin skills that orchestrate those tools into your actual workflows: “triage a Sentry issue” (skill) uses the Sentry server (MCP); “cut a release” (skill) uses the GitHub server (MCP).
  3. Push deterministic steps into skill scripts so the model spends its context on judgment, not plumbing.

It’s the same division of labor you’d apply to a new team member: access badges and documentation are different things, and giving someone one when they need the other has never once worked.

Sources