All posts
· 9 min read ·

Agent capabilities now ship in three layers. Most registries index only one.

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.

Anthropic shipped 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. 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 three layers of agent capability: Skills, MCP, Tools A stacked architecture diagram. Skills sit at the top as procedural knowledge: markdown files with YAML frontmatter, loaded progressively. MCP sits in the middle as connectivity: external tool servers reached via protocol. Tools sit at the bottom as the atomic callable functions an agent invokes. Each layer is annotated with what it provides, what it costs in context tokens, and what proves something about its trust properties. AGENT CAPABILITY STACK · LATE 2025 → 2026 Skills procedural knowledge · "how to do the job" SKILL.md · YAML frontmatter · progressive disclosure 30–50 tokens metadata · full content loaded on trigger LEVEL 1 · TOP cross-tool consensus MCP connectivity · "what the agent can reach" JSON-RPC over stdio/HTTP · tool schemas, resources, prompts tool schemas can consume 50,000+ tokens of context LEVEL 2 · MIDDLE 10,000+ servers indexed Tools atomic callable functions · "the actions themselves" function calls invoked by the agent's reasoning loop LEVEL 3 · BOTTOM

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 introduced the progressive-disclosure design that lets thousands of Skills coexist without exhausting the context window. The cross-vendor adoption that followed 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, 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 (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 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 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. 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 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

← Back to blog Agenstry