Repository navigation
MCP Endpoints #24
Description
Activity
For the use cases and scope for which we are designing, REST makes more sense. I agree that at some point, having some sort of spec for how an registry implementation should expose itself via MCP could be helpful, but by default I'd say there's nothing stopping someone from just building an MCP server bridge and using that. We can bake it into the core architecture if there is meaningful need to do so down the line.
Reacted by Jonathan HefnerHow about extending https://modelcontextprotocol.io/mcp ?
+1 for supporting the HTTP MCP protocol. I would very much like my AI coding assistant to be able to suggest relevant MCP servers when I'm building an agent, by connecting to the MCP registry APIs as MCP tools.
Having further developed thoughts on this: I actually now don't think we should implement this. I'm open to being convinced otherwise, but here is my reasoning --
The target end-consumers of the MCP Registry are subregistries. It is not MCP Clients directly, nor agents (wielding MCP clients). The MCP Registry is a technical infrastructure building block that centralizes publication of MCP server versions and metadata for subregistries to ingest and mirror, but is not architected (or resourced) to solve "discovery" for potentially millions of end-users and all kinds of verticals and user personas. That is why we fan out the final discovery layer to the notion of subregistries.
Exposing MCP endpoints would be contrary to this design goal - it would encourage direct usage by MCP end-users of the MCP Registry. Maintenance practicalities aside, the UX of agentically trying to parse "a centralized registry that has all millions of MCP server versions ever built" is not going to go well - so I'm not convinced this is something that would be practical to use, even if we committed to maintaining it.
Reacted by Jonathan HefnerBuilding an MCP endpoint here will be tricky, but there are literally zero maintainer published real world reference MCP examples, especially not one of this complexity. This is the perfect place to start tackling the hard problems of MCP in a reference implementation, and teach people how they should build complex endpoints where you can't just enumerate everything and stick it into context.
This is also generally useful (see the other comment here), and would aid with registry adoption if clients add it automatically.
- added a commit that references this issue
on Dec 5, 2025 Closing this one out. In-thread, maintainer consensus (tadasant Sept 14) landed on this not being a first-party thing to build: the target consumers of the registry are subregistries rather than MCP clients directly, so an MCP-over-the-registry surface doesn't fit the scope here.
Happily, the community has already built this: there's an MCP Registry Remote MCP Server and an MCP Server for MCP Registry both listed in docs/community-projects.md. Either covers the use case in the original ask.
Is your feature request related to a problem? Please describe.
The registry should really expose MCP endpoints, both as a general principal that MCP first makes a lot of sense, but almost more specifically because hosts / models will definitely want to interact with this.
Describe the solution you'd like
MCP Endpoints - this needs to be horizontally scalable so I'll selfishly suggest https://github.com/Traego/scaled-mcp
Describe alternatives you've considered
REST is fine, but I think MCP should be default for new projects within this overall spec.