The MCP registry, or where an agent gets its tools

The MCP registry, or where an agent gets its tools

The protocol describing how tools and data sources attach to language models spread widely enough to create a secondary problem: how do you know which servers exist and which is the right one.

The official registry answers that. It is a catalogue of server descriptions, maintained by the team behind the protocol itself, available publicly and through a programmatic interface. It launched in autumn 2025 and has since grown past twenty thousand entries.

Before going further, one distinction, since without it the whole text would mislead. The registry stores descriptions rather than code, and performs no security review. I expand on that in its own section, since it is the most important thing to understand.

Reverse names and verification

The naming mechanism is the best considered part here and solves a problem that in package catalogues is a source of serious abuse.

A server name takes the form of a reversed domain pointing at the publishing person or organisation. Before publishing anything under a given name you must prove you have a right to it.

The proof looks different depending on the name's kind. A name pointing at an account on a repository hosting service requires signing in with that account. A name pointing at a domain requires adding an entry to that domain's configuration, which only whoever administers it can do.

The effect is concrete. Nobody will publish a server under a name suggesting a well known company without controlling its domain. That cuts off the simplest route to impersonation, familiar from package catalogues where a name confusingly close to a popular library is an effective attack.

Understand the scope of that guarantee, though. Verification says the publisher controls a given name, and says nothing about what the server does. Those are two different things, and confusing them is the most common mistake when using catalogues like this.

Publishing your own server

The process is shorter than the number of concepts suggests and comes down to four steps.

You start with a description file, stating a name matching your verified domain or account, a description, how to launch it, and the required settings.

{
  "name": "com.mycompany/orders-server",
  "description": "Access to the orders system: status and history lookups.",
  "version": "1.0.0",
  "packages": [
    {
      "registryType": "npm",
      "identifier": "@mycompany/mcp-orders",
      "version": "1.0.0",
      "transport": {
        "type": "stdio"
      }
    }
  ]
}

The second step is a marker confirming the package in the package catalogue belongs to you. Without it somebody could point their description at your package and capture the trust attached to your name that way.

The third is signing in with the command line tool, where the sign in method depends on the name's kind. The fourth is publishing itself and checking the result through the registry's interface.

mcp-publisher login dns --domain mycompany.com --private-key "$PRIVATE_KEY"
mcp-publisher publish

Two things deserve thinking through before publishing. The first is the description: it reaches clients, and a model or a person decides from it whether to reach for this server. A sentence stating plainly what it serves and what it does not do is worth more than a feature list.

The second is versioning. The registry stores versions, so changing a server's behaviour without raising the version means users get something other than what they checked.

What the registry does not provide

This is the most important section in the whole text and the thing material about the protocol states less often than it should.

The registry stores server descriptions, not their code. Installing a server, you fetch it from the package catalogue or container image named in the description, and the registry merely says where it is.

There is no security review here. Nobody reads the code before an entry enters the catalogue, so a listing does not mean a server is safe, well written, or does what its description promises.

The consequence is graver than with an ordinary library. A server of this class receives access to tools, data, and often keys, and the model invokes it on its own, without your confirmation on every operation. A malicious or simply faulty server therefore has wide scope.

Three habits limit that risk and deserve adopting from the start. The first is checking the source: who publishes it, whether the code is public, and whether the repository looks maintained. The second is limiting permissions: a server needing access to one system should not receive a key covering all of them. The third is approving state changing operations rather than letting the model perform them alone.

Remember separately the content coming back from a server. A tool description and a call's result enter the model's context, so a server can influence what the model does next. That is a vector an ordinary library does not have.

That deserves expanding, because the difference is fundamental. An ordinary library executes the code you asked it to and nothing more. A server of this class returns text entering the model's reasoning directly, and the model treats that text as information rather than as data to ignore. A call result containing a sentence phrased as an instruction can therefore influence the next steps, including calling another tool.

This applies to servers written in good faith too, if they fetch content from outside. A server reading customer tickets or web pages passes the model content nobody controls, so treating everything returning from a tool as data rather than instructions is a rule worth adopting regardless of how much you trust the server itself.

Subregistries and company catalogues

The registry was designed as a base layer for others to build on, and that arrangement deserves knowing for enterprise deployments.

A subregistry pulls data from the main registry and adds rules of its own. It can filter out entries failing chosen criteria, run package scanning, or admit only servers approved by a security team.

For an organisation that is the right route. Rather than letting anyone attach any server from a public catalogue, you maintain your own list of admitted entries, and users see only that.

Catalogues run by tool and platform vendors play a similar role. They are often more convenient to use and narrower, since they hold entries vetted or built by that vendor.

Understand the relationship between them. The main registry is the data source, and the other catalogues are overlays with different rules. That means the same entry can look different in each, and an entry's absence from a company catalogue does not mean it does not exist.

How to choose a server from the catalogue

Since the catalogue holds tens of thousands of entries and none has passed review, choosing requires a method of your own. Five things to check in a few minutes.

The first is the publisher. The name points at a verified domain or account, so you can see immediately whether the server comes from the service's own maker or from a third party. That does not settle quality, while a server for a ticketing system published by that system's maker is a different proposition from the same server from an unknown account. Coming from the maker does not imply wider capability, though: the official Google Drive server is an early developer preview that reads files and creates new ones, but will not update an existing document, move a file, or change permissions.

The second is code availability. The overwhelming majority of entries have a public repository, and looking into it pays off, if only to see how many files it holds and when something last changed in it.

The third is the scope of permissions the server asks for. The description lists required settings, so a server asking for a key with full account access in order to read a task list is a warning sign regardless of who published it.

The fourth is the list of tools it exposes. A server offering three read operations is easy to assess, while one with forty operations, deletion and sending among them, deserves considerably more attention before attaching. The number alone does not settle it, though, since some servers let you trim it: the GitHub server holds dozens of tools but enables five toolsets by default and lets you go lower with one environment variable. So check not only how many tools a server has, but how many it turns on unasked.

The fifth is currency. The protocol changed over the past two years, so a server unchanged for a year may work correctly or may not support things you now expect.

For servers touching company data, add a sixth step: running it in isolation and checking where it actually sends traffic. That is ten minutes of work answering a question the description does not answer at all.

The registry and clients

The catalogue alone gives little until the tool you use daily can work with it, so that layer deserves understanding.

Some clients query the registry directly and let you add a server from the interface, without writing configuration by hand. Others use their own catalogues, built on the same data and supplemented with entries vetted by the vendor.

In both cases the end result is an entry in your tool's configuration, stating how to launch the server and what settings to pass it. The catalogue shortens the path to that entry rather than replacing it.

Know where that entry lives and what it holds, since keys and paths land there. In team work that file is often shared through a repository, so secrets should arrive through environment variables rather than be written in directly.

With tools like Cursor and code working assistants the configuration is often two levelled: one for the whole machine and one for the project. The latter is usually the right place for servers tied to a specific repository, since it disappears along with it and does not linger in the background while you work on something else.

The registry against the alternatives

The last row gets skipped and is usually the right answer for company systems. A server exposing your orders database must be written by you anyway, since nobody else knows its structure, and the tools for that are covered in the pieces on the protocol's toolkit and on FastMCP.

Common mistakes

The first is treating a registry listing as confirmation of safety. The registry stores descriptions and verifies names; it performs no code review.

The second is attaching a server with a key covering more systems than it needs. Narrow the permissions to one purpose.

The third is letting the model perform state changing operations on its own. Sending a message or modifying data should require confirmation.

The fourth is publishing without the marker confirming package ownership. Without it a description can point at somebody else's package, and the trust in your name gets used by another party.

The fifth is changing a server's behaviour without raising the version. Users then get something other than what they checked when attaching it.

The sixth is a description listing features rather than stating when to use the server. Models pick tools from descriptions, so it governs how accurately they are called.

FAQ

Does a registry listing mean a server is safe?

No. The registry stores server descriptions and verifies the right to a name; it performs no code review. Verification says the publisher controls a given domain or account, and nothing beyond that.

How does name verification work?

A name takes the form of a reversed domain pointing at the publisher. A name based on an account with a repository hosting service requires signing in with that account, and a domain based name requires adding an entry to that domain's configuration, which only its administrator can do.

What is needed to publish a server?

Preparing a description file with a name, a description, and how to launch it; adding a marker confirming package ownership; signing in with the command line tool in the way matching your name's kind; and publishing. The whole thing takes a quarter of an hour with a finished server.

What is a subregistry?

A catalogue built on data from the main registry, with its own rules for admitting entries. An organisation can that way expose only servers approved by a security team rather than allowing arbitrary ones to be attached.

Is writing your own server better than finding a ready one?

For access to an internal system usually yes, since nobody else knows its structure. For common integrations a ready server saves work, provided you check the source and limit the permissions.

The registry sits at its official address, and its description on the protocol's site.