Share your registry use cases

[tadasant]

Pre-submission Checklist

• I have verified that this discussion would not be more appropriate as an issue in a specific repository
• I have searched existing discussions to avoid duplicates

Discussion Topic

Please read #11 first.

As laid out there, the vision for the official metaregistry summarizes to the following:

1. We will deploy a single instance of a centralized registry that supports a public MCP server publication process and a publicly available REST API to read the data
2. We expect MCP client apps and/or MCP marketplaces to read this data and maintain some copy of the data that they augment and filter in various opinionated ways
3. We hope the publicly available REST API shape may be a shape we can have the ecosystem repurpose for use cases like private enterprise registry mirrors, easily stitching together results from multiple sources (example), etc.

It is for the last point that I wonder whether we are on track to serve that purpose, whether it's worth it, or maybe we just focus on the first two points and let the ecosystem figure out the third in a nonstandardized way (or perhaps build a standard separate from the centralized metaregistry? i.e. we drive a separate notion of "standardized API meant for closed ecosystems where the MCP client is the direct consumer").

I'd love to hear from folks who envision doing more with the official metaregistry than simply "surface all the MCP servers to my MCP client users": are we on track to fulfill your use case? Is this OpenAPI spec on track to do so?

[t1agob]

First of all, great work. I was thinking about building something similar the other day so I might as well contribute to it instead.

The scenario I was thinking of was to build a VS Code extension that would allow developers to simply use VS Code's command pallete to configure MCP servers without requiring them to edit VS Code settings file. This needs some kind of registry hosting all available MCP servers and an API that can be used to list all servers and then grab the correct configuration for each server.

I believe this is a perfect fit for that scenario.

[tadasant]

The VS Code team themselves is contributing significantly to the ongoing work in this repository - just a heads up in case they end up trampling your extension idea 😅

[thoorp]

If not done already, please add a public MCP server, in addition to REST API, for MCP Registry. Even with the basic search by name endpoint, a Registry MCP server will be LLM friendly to explore what’s out there.

As an example, https://modelcontextprotocol.io/mcp is a lovely idea. I use it for “definitive” source of information for my MCP questions.

[tadasant]

Tracking here: #24

Should be fairly trivial for someone to contribute something like this after we have the REST endpoints up and live. Maybe something to add to the official MCP reference servers.

[leefowlercu]

I'm working on a couple of different projects using your Registry API and exported Go Types for both the Registry API Responses and and the Go representation of server.json, ServerJSON.

The first is a Go SDK for the MCP Registry API: https://github.com/leefowlercu/go-mcp-registry

• Go language bindings for MCP Registry API services
• Currently supports the Servers service endpoints (/v0/servers and /v0/servers/{id})
• Will be updated to support the Auth service endpoints
• Includes helper methods to support common filtering actions (Get by Name, Get Latest Version by Name, Get Latest Active Version by Name, Get Version by Name)

The second is a CLI that will programmatically create Nomad Packs (like Helm Charts, but for Nomad) from specified MCP Servers: https://github.com/leefowlercu/nomad-mcp-pack

• Go utility that uses the information in ServerJSON to programmatically create a Nomad Pack directory or archive
• Uses information like Package Type and Transport definition to render Go Templates to create Pack files

Note that while I am a HashiCorp employee the projects are not sponsored by the company and are purely personal projects for myself and the community.

Cheers, and thanks for all your hard work on this project!

[thawkins]

I'm an enterprise user/admin

We would like to have an internal mcp registry, where both tool catalog and tool repo is made available via plugins to common developement tools. So developers can browse and install tools that we have curated and approved for use. and a way to make that the only way to deploy these tools.

[BobDickinson]

I have a common use case - MCP client apps that will integrate one or more registries to allow users to discover and install MCP servers from those registries. One of these is the TsAgent open source platform, and the other is our MCP ToolVault product (an MCP security product implemented as an MCP gateway).

My slightly less common use case is this (for ToolVault): Users install and manage MCP servers for their own environments or their enterprises in our central, secure MCP gateway. That gateway would then use the registry protocol to announce to all clients what MCP servers are available. In this way it acts kind of like an internal registry. It will show users an integrated view of available servers (metadata from the official or other upstream registry, but a single remote that points to the gateway with fixed configuration). By installing MCP ToolVault AS a registry in client apps, it allows them to see the set of approved, secure MCP servers managed by the gateway and install them in one click. And the client doesn't have to know anything about the fact that these are managed/proxied servers - for any client that supports the MCP registry protocol (assuming they allow entry of arbitrary registry endpoints), it will "just work".