Skip to content

Platform Independent Registry Service #65

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
kidehen opened this issue May 22, 2025 · 7 comments
Closed

Platform Independent Registry Service #65

kidehen opened this issue May 22, 2025 · 7 comments
Labels
enhancement New feature or request

Comments

@kidehen
Copy link

kidehen commented May 22, 2025

Problem: Registry Service Platform Dependency

MongoDB (or any specific database platform) should not be a prerequisite for implementing a registry.

Solution: Platform-Independent Registry Service

Service descriptions should be provided in a structured format, such as JSON. Servers can expose these descriptions using an open protocol—such as MCP itself—enabling platform-independent access to their managed snapshots of these JSON-based service descriptions.

Alternative Approach

Service descriptions can also be retrieved from GitHub repositories or discovered via web crawling. This is possible when web pages embed MCP server discovery relationship links as Plain Old Semantic HTML (POSH) metadata.

@kidehen kidehen added the enhancement New feature or request label May 22, 2025
@tadasant
Copy link
Contributor

MongoDB (or any specific database platform) should not be a prerequisite for implementing a registry.

There is no requirement to use a specific database when implementing a registry implementation that conforms to our proposed registry API. But maybe I'm not following what you are implying here?

Service descriptions should be provided in a structured format, such as JSON.

We are providing it as examples + and OpenAPI schema. Is that what you are looking for?

I think at some point we should more formally define the difference between the centralized official registry and the schema we expect other implementations of the registry to adhere to. I think it probably still makes sense to do this with OpenAPI, but open to further feedback and thinking on this (would OpenAPI fall short in some way?).

Service descriptions can also be retrieved from GitHub repositories or discovered via web crawling.

This is orthogonal to the registry work (I believe we should continue to work on .well-known separate from the registry work).

@kidehen
Copy link
Author

kidehen commented May 26, 2025

There is no requirement to use a specific database when implementing a registry implementation that conforms to our proposed registry API. But maybe I'm not following what you are implying here?

My issue is related to these prerequisites that include MongoDB

@tadasant
Copy link
Contributor

There is no requirement to use a specific database when implementing a registry implementation that conforms to our proposed registry API. But maybe I'm not following what you are implying here?

My issue is related to these prerequisites that include MongoDB

It is not clear to me why this is a problem. We are not designing for community members to stand up alternative versions of this same codebase:

Reusability of infrastructure, implementation detail decisions: While we expect the ecosystem to reuse the shapes (such as OpenAPI shape, mcp.json shape) associated with this work, we are not designing for reuse of the underlying implementation details and infrastructure. As such, we will not provide instructions on "how to serve your own instance of this metaregistry".

@kidehen
Copy link
Author

kidehen commented May 26, 2025

You solve my problem by pointing me to the starting point for a registry initiative that doesn't include a designated DBMS as a prerequisite. That's all I need really. It might be that I started off at the wrong point. :)

@tadasant
Copy link
Contributor

It sounds like you are asking for guidance on how to stand up your own MCP server registry implementation?

It is fair that you are trying to build a third party registry (we encourage this), however it is out of scope of the official modelcontextprotocol/registry project to provide implementation guidance.

That may be a good use case to find other community members interested in the same idea via the unofficial community working groups - indeed there was some interest in this kind of idea there.

I'm going to close this issue as something we are not planning to do in this repository at this time. If there is some traction for the idea in the community working groups, could make sense to reconsider down the line.

@kidehen
Copy link
Author

kidehen commented May 27, 2025

It sounds like you are asking for guidance on how to stand up your own MCP server registry implementation?

Nope.

It is fair that you are trying to build a third party registry (we encourage this), however it is out of scope of the official modelcontextprotocol/registry project to provide implementation guidance.

Again, I just want to know that an official repository doesn't mandate a specific DBMS platform via its prerequisites. Naturally, if that's the case, simply say so.

I hope my issue is now crystal clear i.e., the official repository is either DBMS-specific or it isn't.

One more thing:
It might also be that what I've raised my concerns about is a reference implementation of an MCP repository, if so just confirm that to be the case.

My goal here is clarity.

@tadasant
Copy link
Contributor

There is a discussion here where we can consolidate community recommendations on what should be the datastore for the official registry.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants