MCP vs Agent Skills: Reach vs. Know-How (2026)

Almost every “MCP vs Skills” article on the web rests on two premises that are now factually false: that MCP is Anthropic’s protocol, and that Skills are a Claude-only feature. Both flipped. Here is the corrected picture, the context math that makes the choice non-arbitrary, and a one-sentence decision rule you can actually apply.

The two premises that flipped

Search “MCP vs Skills” and you will get a dozen articles built on the same two-sentence foundation: MCP is the open, vendor-neutral standard; Skills are Anthropic’s proprietary convenience feature. Both halves are now wrong, and you can kill them with two primary-source links.

MCP is not Anthropic’s protocol anymore. Anthropic introduced and open-sourced it in November 2024, but on December 9, 2025 it donated MCP to the Agentic AI Foundation — described in the announcement as a directed fund under the Linux Foundation, co-founded by Anthropic, Block and OpenAI, with support from Google, Microsoft, AWS, Cloudflare and Bloomberg. MCP joins Block’s goose and OpenAI’s AGENTS.md as founding projects. Maintainers keep full autonomy over technical direction, and the SEP process is unchanged. If you are writing “Anthropic’s MCP” in 2026, you are describing a governance structure that no longer exists.

Skills are not Claude-only. The Agent Skills format was developed by Anthropic and then released as an open standard with its own published specification at agentskills.io, governed on GitHub with a skills-ref reference validator you can run against your own folder. The client showcase includes direct Anthropic competitors: OpenAI Codex, Google Gemini CLI, GitHub Copilot, VS Code, Cursor, JetBrains Junie, Block’s goose, OpenCode, OpenHands, Mistral Vibe, Amp, Letta and more. The lock-in objection is dead.

So the honest framing is not “which one wins.” Both are open standards under multi-vendor governance, and they solve orthogonal problems. The rest of this article is about what those problems actually are. If you want the mechanics of authoring one, we cover that separately in Claude Code skills; if you are still deciding whether you need a protocol at all, start with MCP vs a plain API.

What each one actually is

MCP is a connection layer. The docs call it an open-source standard for connecting AI applications to external systems, and offer the analogy of a USB-C port for AI applications — with a nod to the Language Server Protocol as prior art, which is the more instructive comparison. Architecturally it is client-server: a host application creates one client per server. The data layer is JSON-RPC 2.0 with lifecycle management and capability negotiation via an initialize request; the transport layer is either stdio for local servers or Streamable HTTP for remote ones. Servers expose three primitives: Tools (functions the model invokes), Resources (data that provides context) and Prompts (reusable templates). The current protocol revision is 2025-11-25 — worth stating plainly, because most published articles, and most models’ training data, still name an older one.

Agent Skills are a procedure layer. A skill is a directory containing a required SKILL.md (YAML frontmatter plus Markdown instructions) and optional scripts/, references/ and assets/ subdirectories. The open spec requires exactly two frontmatter fields, name and description, and offers four optional ones: license, compatibility, metadata, and the experimental allowed-tools. That is the entire portable surface. There is no network call in it, no schema negotiation, no transport. It is instructions the model reads off a filesystem.

The cleanest primary-source proof that these are not redundant comes from MCP’s own architecture page, which states that MCP focuses solely on the protocol for context exchange and does not dictate how AI applications use LLMs or manage the provided context. The protocol deliberately declines to specify procedure. That declination is the Skills-shaped hole.

The context math nobody runs

Here is the part that turns a taste debate into an engineering one, and the reason the two are not substitutes. The loading behavior is asymmetric.

MCP tool definitions load eagerly. Every connected server’s tool schemas sit in your context window from startup — before the model has read a single word of your request. Anthropic’s engineering post on code execution with MCP is blunt about the cost: tool definitions occupy context window space, increasing response time and costs, and agents connected to thousands of tools will process hundreds of thousands of tokens before reading a request. The documented fix in that post moves from 150,000 tokens to 2,000 tokens — a 98.7% saving — by presenting servers as code APIs the agent imports on demand rather than as tool definitions loaded up front.

That number gets misquoted constantly, so be precise: it is one illustrative scenario involving an agent wired to very many tools. It is not a benchmark, and “MCP costs 150k tokens” is not a sentence the source supports. The directional point is what matters.

Skills load lazily. Progressive disclosure is a three-level model with published figures: Level 1 metadata (name plus description) loads at startup at roughly 100 tokens per skill; Level 2, the SKILL.md body, loads only once the skill is triggered, with an authoring recommendation of under 5,000 tokens; Level 3 bundled resources cost nothing until read. Anthropic states that until a Skill is triggered, only its name and description occupy context, and that there is no context penalty for bundled content that is not used. Treat the 5k figure as authoring guidance, not an enforced cap.

One underrated consequence: when a skill’s script runs through bash, only its output enters context — the script’s code never does. A bundled 300-line validator costs you the words “Validation passed.”

The rule that falls out is short enough to remember: every MCP server you add taxes every conversation; every Skill you add taxes almost nothing until it fires. That is why bolting on a fifth MCP server quietly degrades an agent while adding a fifth Skill mostly does not. It is also why context engineering is the discipline that sits underneath this entire comparison — MCP scales in breadth at a per-tool context tax, Skills scale in depth at near-zero idle cost.

The decision rule

One sentence, and it resolves nearly every case:

MCP answers “can the agent reach this system?” Skills answer “does the agent know how to do this well?”

A Skill cannot call anything no tool exposes. An MCP server cannot teach taste. The diagnostic that operationalizes it: delete the thing and ask what breaks. If the agent becomes unable to act, you needed MCP. If it merely acts badly — wrong order, wrong conventions, forgets the migration step, formats the report differently every time — you needed a Skill. And if it acts fine but floods your window with logs you will never re-read, you needed neither: you needed a subagent.

Worked example. You want an agent that reviews pull requests against your team’s conventions. It cannot read your PRs at all → that is a reach problem, and you need an MCP server (or an equivalent tool). It reads them fine but reviews like a generic linter, ignoring the three architectural rules your team actually cares about → that is a know-how problem, and you need a Skill. It reviews well but drags 4,000 lines of diff into your main thread → that is a budget problem, and you need a subagent, which the docs describe as running in its own context window and returning only the summary. Notice that all three can be true at once. They usually are.

The four-way table (and why it collapses)

Most comparison tables on this topic have a column that should not exist. In Claude Code, custom commands have been merged into skills: a file at .claude/commands/deploy.md and a skill at .claude/skills/deploy/SKILL.md both create /deploy and work the same way. Existing .claude/commands/ files keep working, and if a skill and a command share a name, the skill wins. A slash command is not a rival primitive — it is a skill you invoke manually, which is precisely what disable-model-invocation: true expresses.

One caveat the table cannot carry: Claude Code extends the open standard with fields that are not in it — when_to_use, argument-hint, disable-model-invocation, user-invocable, context: fork, agent, hooks, model and others. The docs say as much, describing invocation control, subagent execution and dynamic context injection as extensions. Portability claims apply to the spec’s six fields, not to these. The name field is itself a good example of why you should name your source: the agentskills.io spec requires it and demands it match the parent directory; Anthropic’s platform docs require it and forbid the reserved words anthropic and claude; Claude Code does not require it at all, defaulting to the directory name. “Skills require a name field” is true in two of three places.

How they stack

The best argument against the “vs” framing is not an argument. It is a config file. Claude Code subagent frontmatter contains both a skills field — skills to preload into the subagent’s context at startup, with the full skill content injected rather than only the description — and an mcpServers field, where each entry is either the name of an already-configured server or an inline definition. One file, both primitives, side by side:

---
name: release-auditor
description: Audits a release branch against our deploy checklist.
skills:
  - deploy-checklist
mcpServers:
  - github
---

The Skill supplies the know-how. The MCP server supplies the reach. The subagent supplies the context isolation. Nothing here is competing.

Anthropic’s own on-record position is thinner than people assume, and worth quoting accurately rather than overstating: in the Agent Skills engineering post, the company says it will explore how Skills can complement MCP servers by teaching agents more complex workflows involving external tools and software. That is the only mention of MCP in the post — and the Skills launch announcement from October 16, 2025 does not mention MCP at all. The “complements, not competitors” framing was invented by the community, not by the vendor. It happens to be correct, but it rests on architecture and on config files like the one above, not on a proclamation.

If you are assembling this stack for the first time, the ordering that tends to work is: get reach first, then teach procedure, then isolate. Our Claude Code guide covers the setup path, AGENTS.md covers the project-level facts that should not become a skill, and hooks cover the deterministic checks that should not be left to a model’s judgment at all.

Where the rule breaks

The decision rule has one genuine failure mode, and no article segments by it: Skills behave differently depending on where they run.

• Claude API: Skills run in a sandboxed container with no network access and no runtime package installation, pre-configured dependencies only. Here the question answers itself — a Skill physically cannot reach an external system, so reach is MCP’s job by construction. Skills also require the code execution tool and the skills-2025-10-02 beta header.
• Claude Code: Skills have full network access — the same access as any other program on the user’s computer. The boundary genuinely blurs here, and a Skill with a bundled script can do things you might otherwise have written a server for.
• claude.ai: Network access varies with user and admin settings.

Two related constraints: custom Skills do not sync across surfaces (a skill uploaded to claude.ai must be uploaded separately to the API; Claude Code skills are filesystem-based and separate from both), and sharing scope differs — claude.ai skills are individual to each user with no centralized admin management, API skills are workspace-wide.

Finally, a symmetry worth stating because “it’s just markdown” is a dangerous intuition: neither primitive is a security boundary. Anthropic tells you to use Skills only from trusted sources and to treat adding one like installing software, warning that a malicious Skill can direct Claude to invoke tools or execute code in ways that do not match its stated purpose, with skills that fetch external URLs called out as particular risk since fetched content may carry malicious instructions. The MCP spec says the mirror image: tool descriptions and annotations should be considered untrusted unless they come from a trusted server, and tools represent arbitrary code execution. Both execute code. Both need trust in the source.

One more piece of hygiene, since auth is the most stale section in every existing article on this topic: authorization in MCP is optional, and it applies to HTTP-based transports. Implementations using stdio should not follow the auth spec and should retrieve credentials from the environment instead. So “MCP servers authenticate via OAuth” is wrong as a blanket claim — remote HTTP servers should use OAuth 2.1, local stdio servers use env vars. And when a remote server does authorize, Dynamic Client Registration is no longer the headline mechanism: as of the 2025-11-25 revision, OAuth Client ID Metadata Documents are the recommended approach for clients and servers with no prior relationship, with DCR demoted to a MAY and explicitly retained for backwards compatibility with earlier versions of the spec.

As of July 2026, this is the accurate picture. It is also a topic that churns roughly twice a year — the protocol revision, the adoption figures and the Claude Code field list have all moved within the last twelve months. Check /specification/versioning before you quote a version number, including ours.

FAQ