MCP vs Agent Skills: When to Use Which (and Why You Need Both)

The framing "MCP vs Agent Skills" is everywhere right now, and it is the wrong frame. These are not competing standards. They answer different questions:

• MCP answers "what can this agent reach?" - live tools, data, and side effects.
• Agent Skills answer "how should this agent do the job?" - packaged procedure, conventions, and know-how.

You can have one without the other and get a bad agent either way. An agent with tools but no procedure improvises badly. An agent with procedure but no tools writes an excellent plan it cannot execute.

The strongest evidence that these compose rather than compete is that the MCP project itself is standardizing how skills ship over MCP. More on that below. First, the decision rule.

The Decision Rule#

If you remember one thing:

Build an MCP server when the agent needs to reach something outside its context. Write a Skill when the agent needs to know how to do something.

A quick sort test. Ask: does this thing change when the world changes, or when our process changes?

• Your ticket system's current open issues change when the world changes. That is MCP.
• Your team's rules for triaging a ticket change when your process changes. That is a Skill.

If the answer is "both," you need both, and they should be separate artifacts. That separation is the whole point.

What MCP Actually Is#

MCP is an open protocol using JSON-RPC 2.0 to connect LLM applications to external systems. The specification defines three roles: Hosts (the LLM application initiating connections), Clients (connectors inside the host), and Servers (services providing context and capabilities).

Servers offer three features to clients:

• Resources: context and data, for the user or the model to use
• Prompts: templated messages and workflows for users
• Tools: functions for the model to execute

The spec draws the analogy itself: MCP takes inspiration from the Language Server Protocol, standardizing how to integrate context and tools "into the ecosystem of AI applications" the way LSP standardized language support across editors.

Two things are worth knowing about the current state of the spec. The revision scheme is date-based (YYYY-MM-DD), incremented only when backwards-incompatible changes land. The 2026-07-28 revision moves the base protocol to stateless, self-contained requests with per-request capability negotiation, replacing the older stateful-connection model, and adds a mandatory server/discover RPC that returns supported versions, capabilities, and identity in one call. Clients declare their version per request via io.modelcontextprotocol/protocolVersion in _meta, or the MCP-Protocol-Version header on Streamable HTTP. If you are running against 2025-11-25 or earlier, check the backward-compatibility notes before upgrading.

The other thing: MCP now has an extensions track. Tasks (async long-running operations), MCP Apps (inline interactive UI), and, relevant here, Skills over MCP.

What Agent Skills Actually Are#

Anthropic's engineering write-up defines a Skill as "organized folders of instructions, scripts, and resources that agents can discover and load dynamically to perform better at specific tasks".

The format is deliberately unglamorous. A folder with a SKILL.md that "must start with YAML frontmatter that contains some required metadata: name and description." Additional files live alongside it and get referenced from the main file.

my-skill/
  SKILL.md          # frontmatter (name, description) + the procedure
  reference/
    api-notes.md    # loaded only if the task needs it
  scripts/
    validate.sh     # executed, not read into context

The design principle doing the work is progressive disclosure, which Anthropic calls "the core design principle that makes Agent Skills flexible and scalable," comparing it to "a well-organized manual that starts with a table of contents, then specific chapters, and finally a detailed appendix."

It runs in three tiers:

1. Metadata (name plus description) loaded into the system prompt at startup
2. Full SKILL.md content pulled in when the agent judges it relevant
3. Linked files accessed only as needed

The payoff claim is the interesting one: "agents with a filesystem and code execution tools don't need to read the entirety of a skill into their context window when working on a particular task. This means that the amount of context that can be bundled into a skill is effectively unbounded."

That is the asymmetry people miss. A skill can be enormous because most of it is never read. An MCP server's tool definitions, by contrast, historically all land in context up front. We dug into what happens when that assumption breaks in Skills Delivered Over MCP.

Anthropic is explicit about the relationship, too: skills "complement Model Context Protocol (MCP) servers by teaching agents more complex workflows that involve external tools and software."

The Standards Bodies Already Settled This#

If you want proof that "vs" is the wrong preposition, read the Skills Over MCP Working Group charter.

Its mission is defining how "agent skills - rich, structured instructions for agent workflows - are discovered, distributed, and consumed through MCP." It emerged from SEP-2076, "Agent Skills as a First-Class MCP Primitive", which asked exactly the question this article is about: do existing MCP primitives suffice, or does skills support need new conventions?

The group's current direction is SEP-2640, the Skills Extension, described as "a formal extension using existing Resources primitives." In other words: the answer they landed on is that skills ride on MCP's existing Resources primitive rather than becoming a fourth primitive alongside tools, resources, and prompts.

Some context on how seriously this is being taken. The WG was formed as an interest group in February 2026, converted to a full Working Group on 2026-04-16, and is co-led by Ola Hungerford (Nordstrom, MCP maintainer) and Peter Alexander (Anthropic, core maintainer). Participants include maintainers and engineers from Google, Databricks, GitHub, AWS, Bloomberg, Saxo Bank, Astronomer, and Stacklok. It meets weekly. Its stated long-term success criterion is "interoperable skill distribution across MCP servers and clients."

The charter also coordinates with a Primitive Grouping WG specifically on "progressive disclosure patterns," which tells you the context-cost problem is now a protocol-level concern rather than a client-side hack.

Worth noting what is explicitly out of scope: installable bundles packaging skills plus servers plus subagents plus configuration as one artifact. That is deferred to a broader packaging effort. So if you were hoping for a single install format this year, it is not on this group's roadmap. We wrote about where that pressure leads in Agent Skills Are Becoming Package Managers.

How They Compose: A Worked Example#

We run this pattern in production on this site, so I will use it rather than a hypothetical.

Our platform exposes one MCP endpoint. Early on it had a handful of tools. It now backs roughly 55 capabilities. If all 55 tool schemas loaded into every agent's context on connect, the endpoint would cost more in context than most tasks are worth before the agent does anything.

So the endpoint does not list 55 tools. Its tools/list exposes a lookup dispatcher: find_tools and use_tool. The agent searches for what it needs, then invokes it. The full catalog exists server-side; only the matched slice enters context. That is the same progressive-disclosure idea Anthropic applies to skill files, applied to tool schemas instead. The full write-up is in One Endpoint, Every Capability.

Skills flow through the same endpoint in three tiers that map exactly onto the Anthropic model:

• list_skills returns a lean index (name plus description, tier 1)
• get_skill returns the body and a file manifest (tier 2)
• get_skill_file returns one file on demand (tier 3)

Which makes the division of labor concrete. MCP is the transport and the live surface. Skills are the payload and the procedure. A skill in our library can point at a linked file hosted anywhere, and that file is fetched only when an agent asks for it - the pattern we described in Linked Context.

The lesson from running it: the moment you have more than about a dozen tools, "expose everything up front" stops being viable, and you are forced into progressive disclosure whether or not you have a name for it. SEP-2640 existing is that same realization at ecosystem scale.

Where Each One Fails#

The comparison is only useful if it includes failure modes.

MCP fails operationally. It is a running service. It goes down, it gets slow, it rate limits, it needs credentials rotated. The spec is direct about the risk surface: tools "represent arbitrary code execution and must be treated with appropriate caution," and tool descriptions "should be considered untrusted, unless obtained from a trusted server." Every MCP server you add is a dependency with an availability number and a blast radius. That is a real reason not to build one for something a script could do, which is the argument in CLIs Over MCPs.

Skills fail silently. A skill is text. Nothing breaks when it goes stale. It just quietly describes a process that no longer exists, and the agent follows it confidently into the wrong outcome. There is no health check for "this procedure is now wrong." The mitigation is treating skills like code with real exit criteria rather than accumulated lore, which is the case we made in Agent Skills Need Exit Criteria.

There is a second skills failure worth naming: skills do not compose into a graph on their own. The three-tier model gives you depth (metadata, body, files) but not lateral links between skills. We measured this against our own 36-skill repository in Wiki Skills.

Choosing, Concretely#

Reach for MCP when:

• The agent needs live state it cannot know from training or a file (current tickets, current balances, current deploy status)
• The action has real side effects that need auth and consent (opening a PR, sending a message, charging a card)
• Multiple different clients need the same capability and you do not want to copy logic into each
• You need per-call authorization and an audit trail

Reach for a Skill when:

• The knowledge is procedural and stable (how we format a changelog, our review checklist, our schema conventions)
• The content is large but rarely needed in full, so tiering saves real context
• You want it versioned in git, diffable, and reviewable in a PR
• The tools already exist and the agent is just using them badly

Reach for both when you are automating an actual workflow, which is most of the time. The MCP server exposes create_pull_request. The skill explains what a good PR looks like on your team, when to split one, and which checks must pass first. Neither one is sufficient. In headless and CI contexts, where nobody is watching to correct a bad improvisation, the skill layer matters more than people expect - see Codex Exec in CI.

The Practical Takeaway#

Stop asking which one wins. Ask which half of the problem you are solving.

Tools without procedure produce agents that do the wrong thing efficiently. Procedure without tools produces agents that describe the right thing uselessly. The MCP working group's answer, after months of debate across maintainers at a dozen companies, was to build skills on top of MCP's Resources primitive rather than pick a side. That is a good signal about how to architect your own stack.

The thing genuinely worth your attention is not the comparison. It is progressive disclosure. Both standards converged on it independently, and it is now a cross-cutting concern with a working group attached. Whatever you build, the question that will determine whether it scales is not "MCP or skills," it is "how much of this must be in context before the agent knows what it needs?"

Sources#

• Anthropic Engineering: Equipping agents for the real world with Agent Skills - skill definition, SKILL.md frontmatter, the three progressive-disclosure tiers, unbounded-context claim
• Model Context Protocol specification, revision 2026-07-28 - primitives, roles, stateless request model, extensions track
• MCP versioning policy - revision scheme and negotiation
• Skills Over MCP Working Group charter - mission, membership, scope, timeline
• SEP-2076: Agent Skills as a First-Class MCP Primitive
• SEP-2640: Skills Extension

Continue Reading#

• Skills Delivered Over MCP: Why Progressive Disclosure Is the Missing Piece of Both Standards - the argument this post's decision rule rests on
• One Endpoint, Every Capability - the reference architecture behind the worked example
• Wiki Skills: The Missing Graph Layer in Agent Context - what the three-tier model still does not give you
• Codex Exec in CI: The Practical Guide to Headless OpenAI Agents - why procedure matters more when nobody is watching
• CLIs Over MCPs: Why the Best AI Agent Tools Already Exist - when not to build a server at all
• Agent Skills Need Exit Criteria, Not More Prompt Lore - keeping the skill layer from rotting