Motivations for an industry standard registry API...

[markweitzel]

Pre-submission Checklist

• I have verified this would not be more appropriate as a feature request in a specific repository
• I have searched existing discussions to avoid duplicates

Your Idea

Hi Everyone,
By way of intros, I'm one of the product architects/managers at Microsoft & am currently responsible for a few things--our tooling for M365 Agents, Azure API Center, and I also run a cross org team that focuses on Platform Engineering. It's super exciting to finally see the hard work of this team become "alive and kicking!!". Now that we've got the first version out the door, I'd thought it would be good to start a conversation about motivations for leveraging an industry standard registry api and also share some of the experimentation we've been doing. So here goes...

Motivations

There are several compelling use cases for us that make having an industry standard registry API that can be used for different "types" of registries. One of the assumptions that my teams are working under is that we'll have a community of MCP servers--some of those will be public, some private to an organization, and maybe some "semi-private", e.g. an industry org. Similarly, we will also have the same scenarios for agents and models as well. And of course, we've got this same challenge today with registries of OpenAPI. And there are lots of orgs that have built custom registries that they want to adapt to play in this new AI ecosystem.

One of the core capabilities of API Center--and similar products--is enabling centralized governance for organizations, often via platform engineering teams. So a user will "register" an API (or MCP server) in APIC and then assign access, manage auth, add metadata, etc. An industry standard registry API will accelerate the development of an ecosystem by enabling vendors to quickly add registries that contain new types, e.g. agents (or adapt to a registry by adding a new type). But a standard API ALSO enables developers to have a single, consistent way to contribute to multiple registries. And from a tooling perspective, devs building tools, e.g. CLIs, VS Code plugins, can code to a consistent interface--regardless of the type of registry and who provides it.

Another use case is references within enties in a registry as well as between entities in different registries. From a governance perspective, admins might want to know ahead of time, what MCP servers (and/or OpenAPIs) an agent uses (or is allowed to use). If agent registry(s) and an MCP registry(s) all use a standard way to cross reference each other, then LLMs, tooling, etc. all become more powerful.

Some initial experimentation

One potential industry standard that a few of us have been exploring is the xRegistry project at CNCF. This is interesting for a few reasons, not the least of which is that, being a CNCF project, it's vendor neutral. And, like what we are trying to accomplish here, xRegistry is a meta registry that is driven by schemas. It's intention is to be just a registry API and allow implementors to define the schemas that its implementations will contain.

And although it just started the incubation process, xRegistry has been under development for a few years--so there's lots of prior art that went into its development. In fact, the event stream pipeline features in Azure Fabric ("Real-Time Intelligence") have taken a hard dependency on xRegistry already, and the Azure Messaging team is basing these on a yet-unannounced Azure service, the "messaging catalog", that will be deeply integrated with Event Grid, Event Hubs, and Service Bus.

So in the spirit of learning by doing, the xreg team has stood up an experimental MCP based xRegistry. You can also use curl or http client to get the raw json: GET https://mcpxreg.org/registry/mcpproviders/CodeLogicIncEngineering

Note: The data that's in the xreg-mcp experiment was pulled from the repo, so it doesn't exactly match the seed data that you get when you spin up the docker/mongo one we have now. This is why {id} for the xreg is based on name & our seed has an {id} that is a GUID. The web page is a simple web page on top of the a static website that uses the xregistry api. The way it's implemented it is that it's based on files in the git repo https://github.com/clemensv/xregistry-mcp/tree/master/registry/mcpproviders. Whenever a new pull request is merged into main, a github action fires and rebuilds and republishes the web site. Obviously, commercial offerings would have more robust governance etc. but we thought this might be a very easy way for folks to get started with an MCP registry of their own using git and files.

(The experimental agents xRegistry is here GET https://clemensv.github.io/xregistry-a2a/registry. We've not built out much here yet, but it's built the same as the mcp reg, e.g. using the xRegistry project tooling, has the same github action publish flow etc.)

I know this was a bit of a long post, so thanks for taking the time to read it. And thanks for taking the time to consider these ideas. I'm looking forward to the discussion and your feedback!

Scope

• Protocol Specification
• SDK Features
• Documentation
• Developer Experience
• Other

[tadasant]

Thank you @markweitzel for raising this!

First at a high level: I am interested in hearing from folks who think there is an existing registry/discovery standard we should be considering with the official MCP registry development. Besides xRegistry as proposed in this thread, one that has been brought up in the past is World of Things here (that particular pitch was to rebase the entirety of MCP on WoT, which is a tougher sell; in our case here, a REST API to expose structured service metadata feels like something where meaningful prior art and tooling is more likely to exist).

A potentially obvious one I think is worth a look is the OCI Distribution Spec.

Reasons these explorations interest me:

1. Has someone already solved generalizable and downstream registry-like concerns that can enable us to dodge reinventing the wheel here?
2. Is there a mature ecosystem of tooling (e.g. CLI tools, tools that enable creation and management of mirror registry deployments) around it?

Examples where point 1 might be helpful:

• For ideas like complex search, tagging, and filtering: we are not planning on implementing these in the official MCP registry. However, those features are clearly something someone consuming our registry may want to tack on to our data in an opinionated way. If an extensible schema exists (which the official registry has just chosen not to implement), our consumers may choose to mirror our data and then augment it, and then expose it to downstream consumers adherent to the overall registry specification.
• Similarly, needs like "sorting signals" may come up, even if we don't want to bake that data directly into the official registry
• Again for "marketing data" - we don't want that data provided in the official registry, but it does make sense that an MCP client consumer would be interested in consuming it, thus modeling for it is valuable

Examples for point 2 are self-evident (we are soon going to be building out a CLI for publishing server metadata ... there may soon be third party registries trying to reimplement our API shapes with net new solutions in a variety of different languages and tech stacks).

Of course, we are capable of just powering through these needs as they come up. The thinking here is that maybe we can save a few thousand hours of time and adopt something that will just work for us out of the box (and perhaps has resourcing available elsewhere where it can continue to evolve and improve).

If we do decide something is worth adopting, I do want to allow for the possibility that we may not bake it into an initial launch here (instead doing our best to align well-enough that a future migration or major version shift is not too painful). MCP is still very immature as an ecosystem, and I think there is value in keeping things moving forward so we can support the ecosystem in fleshing out use cases and value creation (as opposed to potentially killing its momentum and then it never makes it to be a sustainable piece of the tech ecosystem).

---

All that said, some initial thoughts on xRegistry as I start to look through the spec --

This document is a helpful starting point for anyone looking for a place to get started.

A Registry Service exposes Resources and their metadata, for the purpose of enabling discovery of those Resources for either end-user consumption or automation and tooling.

The abstract checks out... sounds like what we are building. Resources = mcp.json (or probably soon renamed to: server.json) files representing an MCP server.

many Resource models share a common pattern of grouping Resources and can optionally support versioning of those Resources ... Groups, as the name implies, is a mechanism by which related Resources are arranged together under a single collection - the Group. The reason for the grouping is not defined by this specification, so the owners of the Registry can choose to define (or enforce) any pattern they wish. In this sense, a Group is similar to a "directory" on a filesystem.

We're not doing a whole lot of "grouping" in our from-scratch registry to date. I think you @markweitzel are right to say that, if anything, the Group is the "provider". That would probably equate to how we have been thinking at the reverse-DNS part of an MCP server name to date. So a provider (Group) in our current model is very simply a string like com.microsoft for a Microsoft-owned MCP server, or io.modelcontextprotocol for an official MCP reference server.

Indeed, a core value of the Registry here is that MCP servers should be versioned, so it's nice that a core value prop of xRegistry is the version the Resources.

One of the goals of xRegistry is to be as broadly supported as possible. Requiring all xRegistry endpoints to support the full range of APIs defined in this specification might not be feasible in all cases. In particular, there might be cases where someone wishes to host a read-only xRegistry server to only expose their documents (and metadata) and therefore the write operations or advanced features (such as inlining or filtering) might not be needed. In those cases, simple file serving HTTP servers, such as blob stores, ought to be sufficient, and in those cases requiring support for query parameters and other advanced features (that could require code) might not always be possible.

I like this principle -- makes it sound like it could be a fit for our simplified, barebones centralized official Registry, and allow third parties/private implementations to dig into the more complex and opinionated pieces.

---

I'm not sure I will have more time to dig in this week, but so far the top open questions on my mind are:

• Besides xRegistry, what should be on the table for consideration? OCI Distribution?
• xRegistry has some adoption but is not a super mature project; how much risk would be taking on by adopting it?
• What's the path to getting an ROI on some of the specific goals I mentioned above ("point 1" and "point 2") w.r.t. to clear needs I think we will need for MCP specifically?
• Is there a way we could de-risk the stakes of this proposal and, say, put us on a track that we can make this decision over a longer time horizon, without either meaningfully slowing down development as-is but also designing in a way that a future migration won't be too difficult if we build confidence this is a good direction to pursue?

(I know you have started to address some of these in your initial comment, just flagging as summary points for others invested in the MCP ecosystem to consider and provide their opinions on)

[clemensv]

On grouping: We introduced groups as a mandatory first level in xRegistry because every multi-party registry eventually needs both namespacing and some sort of access control mechanism and a way to pick up related sets of resources for sharing. The groups allow you, for instance, to create an access control boundary around a set of resources (here: server definitions), limiting write access to owners. Forming namespaces obviously helps with disambiguating resources.

In eventing/messaging, we use groups as contracts for streams. A resource can appear in multiple groups via xref, meaning you can "borrow" resources from other groups in a group; for eventing streaming where you have a group of 5 message types coming into a filter but only 2 coming out, you express that with a new group that references the 2 remaining types.

That way, you could also form groups of MCP servers that are not organized by owner. The naming convention for the group names, which the extension model spec would define, would have to reflect such a distinction. We've allowed '@' as a separator for this purpose, e.g.

• contoso.com (holds all of Contoso's MCP servers)
• [email protected] (holds all of Contoso's productivity MCP servers)
• [email protected] (holds all of Contoso's knowledge MCP servers)

In the productivity@* and knowledge@* groups there would be xref entries pointing at entries in contoso.com. From an access control perspective, only an admin of contoso.com can edit the core metadata. An admin of knowledge@* manages membership (and could arguably also have local definitions, but clients can distinguish those).

For federation, we imagine that registries can simply "#include" other registries as read-only, with the ability to shadow content for local variation. contoso.com provides an authoritative registry of all their MCP servers (and other resources) for external parties to consume, and fabrikam.com that offers contoso.com to their internal agent apps will reference that registry into their own, which then becomes transparently integrated for upstream consumers. If fabrikam.com wants to override an entry, they can shadow it.