The three layers of agent capability: Skills, MCP, Tools

--- title: "Agent capabilities now ship in three layers. Most registries index only one." date: 2026-05-18 summary: "Anthropic shipped Agent Skills in October 2025. Seven months later, every major coding agent reads the SKILL.md format. The result is a third layer in the agent capability stack — separate from MCP, separate from tool calls — that almost no public registry indexes today." slug: agent-capability-three-layers author: "Damiën Semler" hero_glyph: doc-stack --- [Anthropic shipped Agent Skills](https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills) on October 16, 2025. Seven months later, every major coding agent on the market reads the same SKILL.md format: Claude Code, OpenAI Codex CLI, Cursor, Gemini CLI, GitHub Copilot in agent mode, Cline, Roo Code, and AAIF's [own goose](https://agenstry.com/blog/goose-local-first-trust-model). The cross-tool consensus on the file format happened faster than the consensus on MCP did. What it produced is a layer in the agent stack that is structurally distinct from MCP — and that almost no public registry indexes today. The change is bigger than another file format. Agent capabilities now ship in three architecturally separate layers, each with its own trust properties and each with its own discovery problem. Most registries operate on one of the three layers. Consumers integrating across multiple agents are stitching the picture together themselves. ## The three layers, drawn out The functional split underneath the diagram is what matters operationally. Skills shape *what the agent does*; MCP determines *what it can reach*; Tools are *the atomic actions it can take*. A useful frame is to read top-to-bottom: a Skill loaded at the top of the prompt tells the agent how to approach a task, MCP servers configured into the agent's environment give it the connectivity it needs to execute, and Tools are the callable surface the reasoning loop ends up invoking. The frame is recent. The [Anthropic announcement post](https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills) introduced the progressive-disclosure design that lets thousands of Skills coexist without exhausting the context window. The [cross-vendor adoption that followed](https://duet.so/guides/agent-skills-101-tools-vs-mcp-vs-skills) made the SKILL.md file format a de facto cross-tool standard inside seven months. That standardization happened with no central foundation, no formal RFC, and no signing requirement; the format spread the way [AGENTS.md did](https://agenstry.com/blog/agents-md-convention-not-contract), via adoption velocity alone. ## Why three layers and not one A reasonable question is why the agent ecosystem needed to split this into three layers rather than collapsing everything into MCP. The answer is structural and shows up clearly in the token economics. An MCP server's tool schemas have to live in the agent's prompt for the agent to know what they can do. At 10–50 tools per server and typically 100–500 tokens of schema per tool, an agent connected to even a dozen MCP servers can spend 50,000+ tokens of context on schema alone before answering its first prompt. Skills are designed around that limit. Only the name and description (30–50 tokens) stay in the prompt; the full Skill content loads only when the description matches the task at hand. The architectural insight is that *procedural knowledge does not need to be always-resident the way schemas do*. Tools, the bottom layer, are the atomic actions an agent invokes. They are downstream of MCP (the protocol that exposes them) and downstream of Skills (the procedural instructions that tell the agent when to call them). Indexing tools at population scale would be a fourth registry problem, and most ecosystems don't try. ## What this means for registries The discovery question changes shape across the three layers. The public registries [we surveyed earlier](https://agenstry.com/blog/mcp-discovery-fragmentation) (Glama, PulseMCP, Smithery, the official AAIF registry, GitHub's MCP registry, AWS's preview) operate on the middle layer. They list MCP servers. They do not, as a class, list Skills. A consumer asking the obvious next question, *which Skills exist for my agent?*, has fewer answers. The Anthropic skills repository on [GitHub](https://github.com/anthropics/skills) lists a small set of public Skills. The cross-tool ecosystem has aggregator sites that mirror them. None of those operate at the scale of the MCP registries, and none yet publishes the kind of behavioral probe data [Agenstry publishes](https://agenstry.com) for MCP servers. This is not a complaint about Skills. The Skills layer is younger, less mature, and structurally simpler than MCP: a Skill is a Markdown file plus optional resources, not a running server. A Skill cannot crash, fail to respond, or expose a [DNS-rebinding vulnerability](https://agenstry.com/blog/google-mcp-origin-validation-seven-months). The probe a registry would run against a Skill looks different: syntactic validation of the SKILL.md, evidence that the procedural guidance matches the task description, and a provenance trail for who contributed which version. Different probes. Same shape of work. The interesting registry-design question is whether Skills, MCP servers, and Tools belong in *one* federated index with three sub-surfaces, or in *three* independently governed registries that compose at consumer integration time. Both architectures have analogues in the Linux distribution world (packages, repositories, and version metadata), and both have served different needs. The agent ecosystem will pick one of those shapes within the next year because the consumer-side composition cost gets unbearable if it doesn't. ## What we're watching Three things, observable in the next two quarters: 1. **Whether the [AAIF MCP Registry](https://github.com/modelcontextprotocol/registry) extends to index Skills.** A single foundation registry covering both is the obvious move, given that MCP and Skills are now both AAIF-adjacent concerns. Whether the AAIF governance treats Skills as in-scope will signal how the foundation views the three-layer stack. 2. **Whether a public conformance probe emerges for Skills.** The probe surface is smaller than for MCP (no transport, no auth, no runtime), but the trust questions ("did the project author sign this?", "does the procedural guidance match the code it claims to apply to?") are real. The first registry to publish probe data for Skills at population scale will set the template. 3. **Whether Plugin distribution becomes the actual top-of-stack convention.** The Plugin layer above Skills/MCP/Tools is the packaging primitive that lets a team ship a bundle of all three together. If Plugin registries (like the GitHub MCP Registry's plugin extensions) become the canonical install surface, the discovery problem moves up one more level and the three-layer model becomes a four-layer story. The headline number on MCP is the server count. The quieter number is the Skill count, and the registry layer that connects the two is the work the next year of agent infrastructure will resolve. A consumer reading "this agent can do X" is reading off some combination of all three layers. Today, the consumer has to know which. ## Sources - [Equipping agents for the real world with Agent Skills](https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills) — Anthropic, October 16, 2025. - [anthropics/skills on GitHub](https://github.com/anthropics/skills) — public Agent Skills repository, accessed May 2026. - [Agent Skills vs Tools vs MCP: The Complete Guide (2026)](https://duet.so/guides/agent-skills-101-tools-vs-mcp-vs-skills) — Duet.so, 2026. - [Building agents that reach production systems with MCP](https://claude.com/blog/building-agents-that-reach-production-systems-with-mcp) — Claude.com / Anthropic, 2026. - [Model Context Protocol Registry repository](https://github.com/modelcontextprotocol/registry) — modelcontextprotocol/registry, accessed May 2026.