Servers, skills, and agents: how the three registries fit together

Three building blocks, one stack

If you have followed VaultPlane for a while, you have seen the catalog grow in three waves. First came MCP servers (3,400+ of them). Then Claude skills (12,000+). Then open-source agents. They look like three independent catalogs, but they are not. They are three layers of the same stack, and reading them together is what makes a registry useful.

The short version:

• MCP servers are capabilities. What an agent can do.
• Skills are know-how. How to do it well.
• Agents are runtimes. Who is doing it.

Once you see them in those terms, the composition story falls out naturally.

MCP servers: the verbs

An MCP server is a tool an agent can call. A GitHub MCP server adds the verbs open a pull request, comment on an issue, search code. A Postgres MCP server adds run a query, describe a schema. Each server exposes a typed interface, declares the permissions it needs, and runs as a separate process the agent talks to over a standard protocol.

This is the capability layer. Without servers, an agent can only generate text. With servers, it can act.

We have written about this layer at length: What is MCP? covers the protocol, and How MCP servers work covers the runtime model.

Skills: the playbooks

A Claude skill is a SKILL.md file that tells Claude how to handle a specific kind of task. It does not add a new verb. It tells Claude how to use the verbs it already has to produce a good result: a clean PDF, a well-structured PRD, a deployment that follows the team's conventions.

Skills are the know-how layer. They are why two agents with the same servers can produce very different results: one of them has been given the recipes, the other is improvising.

A worked example: Anthropic's skill-creator walks Claude through drafting, evaluating, and benchmarking a new skill. It does not add any new tool. It adds a workflow Claude follows. See What are Claude skills? for the deeper dive.

Agents: the runtimes

An agent is the thing that actually runs. A LangGraph state machine, an AutoGen team, a CrewAI crew, a custom loop built on the Anthropic SDK. Each agent has a goal, a control flow, and a set of capabilities it draws on. Some are highly autonomous (BabyAGI plans its own steps), some stay on rails (a chatbot that only answers from a knowledge base).

This is the who layer. Browse them at /agents.

How they compose

When you open an agent on VaultPlane, the detail page shows a Composition section. That section lists three things:

1. The models the agent uses.
2. The MCP servers it binds to (its tools).
3. The skills it expects to be available.

That is the composition graph in concrete form. An agent is not a self-contained artifact. It is a recipe that depends on servers and skills, and those servers and skills can be swapped, audited, and governed independently.

Example: the Anthropic cookbook MCP agent demonstrates how to wire an agent to MCP servers and apply the MCP builder skill. Open the server detail page for any popular MCP server and you will see an Agents that use this server section listing which agents in the registry actually call it. Open a skill detail page and you see Agents that adopt this skill. The graph is queryable in both directions.

Why having all three in one registry matters

Without the composition graph, picking a tool is a leap of faith. You install an MCP server because the README looks good. You ship a skill because it sounded useful. You fork an agent without knowing what it depends on.

With the composition graph, the questions get sharper:

• Who actually uses this server in production-grade agents? Look at the agents linked from the server's page. If the answer is "nobody yet," that is a signal.
• Is this skill paired with anything I trust? If a skill is adopted by a verified agent, that tells you something the README cannot.
• If I run this agent, what surface area am I really opening? Read off the servers in its composition and check their trust scores.

That is the control plane loop. Definition (this registry) plus enforcement (the Gateway) is how a team decides what is allowed and then makes the policy stick at runtime.

Where we are today

We are early on the composition graph. The 10 hand-curated agents have full compositions. The 73 community-imported agents have framework-default models, and a hand-picked set of them link back to the skills they demonstrate. Most of the long tail is still single-node: an agent listed by itself, with no edges out.

That changes one of two ways. Either the agent's README declares its dependencies explicitly (and we parse them on import), or the community contributes the edges. The goal is that every agent in the registry eventually has a composition that tells you, in one glance, what it needs and what it adopts.

The three registries are most useful together. Servers without skills is improvisation. Skills without servers is theory. Agents without either is a demo. The composition graph is what turns the catalog into a control plane.