MCP registry: discover, authorize, and version agent tools

An agent tool catalog is not a spreadsheet someone keeps updated. It is infrastructure. The MCP registry is the layer that has cataloged every published MCP server, registers who can see it, and states which version is active; it decides what exists before any gateway decides what passes through.

The blog has already covered the two neighboring layers. The MCP protocol defines how messages travel between a model and a tool. The MCP gateway defines what passes, with what policy, at what cost, and with what audit. Neither of these answers the question that arises before all of them: which tools exist, who can see them, and which version is serving whom.

This question is cheap to answer with 8 MCP servers. With 80, it becomes a catalog problem, and the catalog has metadata, policy, and a lifecycle. The bottleneck is no longer latency, but knowing what exists.

What is an MCP registry?

An MCP registry is a metadata catalog for MCP servers: name, verified owner, where the package is hosted, how to execute, and which tools each server publishes. It does not host code or traffic. It hosts the information that allows a client to discover and connect a server without a human pasting a URL into a configuration file.

The official Model Context Protocol registry entered preview on September 8, 2025, announced on the protocol's own blog with the signatures of its maintainers and Theodora Chu, MCP Product Manager at Anthropic. The launch text is direct about its intention: to be the single source of truth for public MCP servers, with the registry and the OpenAPI specification describing it published as open source.

Two decisions from this announcement are more important than the launch itself.

The first is the separation between metadata and package. npm, PyPI, and Docker Hub continue to host code and binaries. The registry hosts the pointer. A weather-mcp package resides on npm; the registry stores that a specific server, at a specific version, corresponds to that package. When someone asks why an installation failed, the answer could be in either place, and they have two different owners.

The second is that the official registry is not intended to be consumed directly by client applications. The documentation is explicit: it is designed for downstream aggregators, such as MCP server marketplaces, which pull metadata via a REST API at regular intervals (the example cited in the documentation itself is once per hour) and curate it. Client applications consume these other registries, which implement the same OpenAPI specification.

Here is the consequence that almost no one plans for. The public registry solves the discovery of what is public. It does not solve the discovery of what is yours.

Why the public registry does not solve your team's problem

The official registry does not accept private servers. The documentation addresses this case directly: servers accessible only to a restricted set of users, published on an internal network or in a private package registry, are not included. The recommendation for this context is to host your own private registry and place the servers there.

This is not a limitation that can be circumvented with creative configuration. It is by design. The public registry is a namespace and provenance mechanism for what is open; your internal catalog is something else, with a different owner, a different policy, and a different lifecycle.

From there, an enterprise's integration count becomes the real problem. A platform team running agents in production accumulates MCP servers from three distinct sources, and each source has a different trust regime:

• Public servers, installed from a package on npm, PyPI, or Docker Hub, with verifiable provenance through the official registry.
• Internal servers, written by the team itself, which expose enterprise systems and have no place in the public catalog.
• Third-party contracted servers, which run remotely, require OAuth, and bring their own review cycle.

Without a catalog, discovery happens in the dark. The agent discovers the tool that the developer pasted into its configuration file. There is no inventory, no declared owner, no scope policy. And then the question that stalls the architecture meeting arises: can this agent call the server that issues invoices?

Discovery scope: the same server, three answers

Here is the point that separates a catalog from a list. A catalog answers what exists in the general repository. A registry answers what exists for you, applying a visibility policy segregated by team, agent, and operational environment to protect critical tools from unauthorized access.

The metadata of a published MCP server is unique. Its visibility is not. The same database reading server appears for the financial analysis agent and disappears for the customer support agent, and the difference lies in the scope policy, not in the registration.

Tool permission is not agent permission, and this confusion is costly. Those who solved agent identity and traceability covered half the problem; the other half is the scope of publication and discovery at the MCP server level and the tool it exposes. Access permissions and traceability in AI agents answer who the agent is and what it did. The registry answers what it can find.

Authorizing a remote MCP server

Authorizing a remote MCP server is an OAuth 2.1 flow, and the protocol does not leave this to chance. When the transport is HTTP, the protected server acts as an OAuth resource server, and the client discovers the authorization server's metadata before any call. Local transport via stdio follows the opposite path: credentials come from the environment, and the specification recommends that this path should not follow the OAuth flow.

It is worth noting what is optional and what is not, because a lazy reading treats both as equal.

The subset is the interesting part. The specification states, in text, that it implements a selection of features from these standards to preserve security and interoperability without introducing unnecessary complexity. Translating this to operation: there is no "full OAuth" MCP server and another "without OAuth." There is a specific set of agreed capabilities, and it is against this that your catalog needs to register what each server requires.

The tool publication lifecycle

Publishing a tool in a catalog is a multi-step procedure, and each step leaves a record that someone will consult later. The cycle below follows what the official registry documentation requires from a publisher.

1. Verify the namespace. The server name follows a reverse DNS format and ties the origin to a verified account. With GitHub authentication, the name takes the form io.github.user/*; with domain authentication, the form com.example.*/*, and proof comes from a TXT record published in that domain's DNS.
2. Declare the metadata. The server.json carries the unique name, version, where the server is hosted, execution instructions, and discovery data. This is the file an aggregator will read.
3. Publish the version. The version is mandatory, must be unique per publication, and once published, the version and metadata cannot be changed. Correcting means publishing again.
4. Apply the scope. The internal catalog receives the entry with owner, team, environment, and exposed tools, and it is here that visibility ceases to be uniform.
5. Register the authorization policy. What that server requires to be called, and which agent identity can list it.
6. Consume and version. Clients and aggregators pull the metadata, and each consumer becomes dependent on a specific version. The technical debt begins exactly here.

Step 3 is where most architectures lose control, and the documentation explains why. The registry recommends semantic versioning but accepts any string format. When the published version does not parse as semantic, it is marked as "latest" anyway. And there is an explicit prohibition: strings that look like version ranges, such as ^1.2.3, ~1.2.3, 1.x, or 1.2.*, are rejected.

Notice what this means for your internal catalog. You can register 2025.11.25 and 2025.6.18 as valid versions, and the comparison between them ceases to be arithmetic. If one of the two does not parse, the tie-breaking criterion becomes the publication timestamp. A catalog that orders versions by string places 1.10.0 before 1.9.0.

How to version without breaking existing consumers

The registry rule is strict and worth internalizing: the published version does not change. Published metadata does not change. If a server needs to correct what it declared, it publishes a new version, and the previous one continues to exist in the history.

This protects the integrity of the catalog and transfers the problem to the consumer. Forty consumers written against v1 of a server do not migrate because v2 became available. They migrate when someone decides they migrate. And that decision needs a place to reside.

The protocol has a component that helps, and it is recent enough to go unnoticed. In the current revision, 2026-07-28, each request declares the version of the protocol it uses, and the server accepts or rejects requests on a per-request basis. If the server does not support the requested version, it responds with an error listing the versions it does support, and the client can try again with a mutual version. Negotiation is per call, not per session.

Along with this, a client that wants to choose the version beforehand can call a mandatory RPC that returns, in a single request, the supported versions, capabilities, and server identity. Calling it is optional. Knowing it exists is not.

The detail that closes the argument is this: an MCP server declares whether it will issue a notification when the list of available tools changes. In other words, tool discovery in MCP is dynamic by contract, not by convention. An agent connected to a server can see the set of tools grow or shrink during operation.

And this is precisely why a static configuration file is not a catalog. It is a snapshot. If the server changes the set of tools and your discovery policy does not keep up, the agent starts operating against an inventory that no longer corresponds to what exists.

Internal convention or managed catalog?

The real decision is not between buying a tool and buying nothing. It is between maintaining a convention that only works while the team is small, and operating a catalog with metadata, scope, and a version lifecycle. Both options are legitimate at different scales. Scale decides.

The honest reading of the table is that the left column is correct until the moment it ceases to be, and no one marks the date. The sign that the date has arrived has a name: when there is an integration that no one can explain where it came from, and an agent in production calls it.

Where this layer touches the economic model

The connection between catalog and cost is not obvious, and it is worth outlining. Each published tool is a call that can be repeated, and each repeated call is a token. Without a record of who consumes what, a month's inference bill is not attributable to any team, and the discussion about cost routing lacks a basis for allocation.

The same applies to capacity. A catalog that registers how many tools each server exposes and how many consumers call them allows comparing invocation volume between providers and adjusting the cost per task with data, not with estimates. The registry layer precedes routing, but it is what produces the inventory on which routing will operate.

Errors that appear after the first quarter

Three patterns appear in almost every operation that transitions from a pilot team to several, and none of them are tool errors. They are process errors that the tool merely reveals.

The first is treating the public registry as internal inventory. It does not accept private servers, and forcing it to accept them means publishing internal system metadata in an open catalog. The correct solution is to operate a private registry that implements the same OpenAPI specification, which also preserves client application support.

The second is publishing without an owner. Metadata without a declared owner is metadata that no one updates, and the deprecation of an ownerless tool happens by abandonment, not by decision. When the server dies, the agent that called it discovers this in production.

The third is confusing server version with remote API version. For a local server, the recommendation is to align the server version with the package version. For a remote server with a versioned API, the recommendation is to align with the API version. Mixing the two regimes produces a catalog where the same version string means two different things.

In the current revision, the protocol also marks features as deprecated without immediately removing them: a deprecated feature documents the migration path and remains in the specification for at least twelve months before becoming eligible for removal. Those operating an internal catalog need the same mechanism, with a declared timeframe. Without a timeframe, deprecation is merely an intention.

Frequently Asked Questions

What is an MCP registry? It is a metadata catalog for MCP servers. It stores the name, version, verified owner, where the package is hosted, and how to execute. It does not host code or traffic, and it exists so that a client can discover and connect servers without manual configuration.

Does the official registry accept private servers? No. The documentation explicitly recommends that those with internal servers, published on a private network or in a private package registry, host their own registry. The official registry is a provenance mechanism for what is public.

What is MCP authorization and when does it apply? It is the protocol's authorization flow, based on OAuth 2.1, and it is optional. When implemented over HTTP transport, the server acts as a resource server, and the client discovers the metadata before making a call. For stdio transport, the recommendation is to retrieve credentials from the environment.

What does dynamic tool discovery mean in MCP? A server can declare that it will notify clients when the list of available tools changes. Discovery is dynamic by specification contract, not by vendor convention. A static configuration file is a snapshot, not a catalog.

Can a published version be corrected? No. The version must be unique per publication, and once published, the version and metadata cannot be altered. Correcting requires publishing a new version. The registry rejects strings that resemble version ranges, such as ^1.2.3 and 1.2.*.

Is it possible to operate without a managed catalog? Yes, and it is the correct choice below a few dozen integrations. The cost appears when an integration has no explainable origin and an agent in production calls it. Internal convention does not fail due to scale, it fails due to a lack of declared ownership.

References and Further Reading

• The MCP Registry, official protocol documentation, accessed September 17, 2026: single source of truth, server.json format, reverse DNS namespace, scope for downstream aggregators, and the rule that does not admit private servers.
• Versioning Published MCP Servers, accessed September 17, 2026: immutability of the published version, recommendation for semantic versioning, and the prohibition of range strings.
• How to Authenticate When Publishing to the Official MCP Registry, accessed September 17, 2026: the name formats io.github.user/* and com.example.*/*, and authentication via TXT record in DNS.
• Authorization, specification in revision 2026-07-28, accessed September 17, 2026: OAuth 2.1 as the basis, the optional nature of authorization, and the norms of the implemented subset.
• Versioning, accessed September 17, 2026: the current revision, per-request negotiation, and the deprecation policy with a minimum twelve-month period.
• Tools, accessed September 17, 2026: the tools capability with listChanged, which makes discovery dynamic by contract.
• Introducing the MCP Registry, September 8, 2025: the announcement of the official registry launch in preview, with public and private sub-registries.

What to do on Monday

The order matters. It is the inverse of intuition. Before choosing a gateway, count how many MCP servers the company has, how many declared owners exist for them, and how many consumers call each version. This survey can be done in an afternoon and answers the question that no traffic decision answers.

If the number is small, an internal convention with a named owner per server will suffice. If the number exceeds a dozen, the registry layer has ceased to be documentation and has become infrastructure, and the practical difference is who responds when an agent calls a tool that no one knew existed.

It is precisely this transition that Nexforce Agents addresses with Nexforce Work: the catalog, permissions, and MCP connectors layer exists to function when operations move from a pilot team to several, with the list of available tools under control instead of under convention. The B2B AI agents running in production depend on this, and Nexforce Code consumes the same MCP servers as external tools.

The catalog is the part of the system that no one looks at until the day it is the only thing that explains what happened.