DRAFT RFC - Supported URI Schemes for Server #30
Conversation
Work in progress . This commit adds the core registry service implementation with methods to: - Retrieve all registry entries - List entries with cursor-based pagination - Fetch specific server details by ID
…pi_v0 Init world. Basic registry API server <WIP>
…eadme-cleanup Update README to reflect binary name change
…ridharavinash/seed Add count to server response and fix Makefile paths
…retrieval is validated
…pi-docs Add Swagger API documentation and handlers for v0
Contains about 300+ initial servers that can be used to seed a mongoDB
We need to work in multiple orgs with different private repos, this is a temporary solution until we make the main repo public.
…blishing - Added authentication service and GitHub OAuth integration. - Introduced new authentication methods and structures in the model. - Updated the API to handle authentication during the publishing process. - Created handlers for starting and checking the status of the OAuth flow. - Enhanced the publish handler to validate authentication credentials. - Updated configuration to include GitHub OAuth settings. - Added tests for the OAuth flow and publishing with authentication. - Updated documentation to reflect changes in the API and authentication process.
…e argument descriptions
…cation and update documentation
…b application and improve error handling
…ecks and introducing dynamic auth method determination
First (incomplete) cut of OpenAPI spec for registry API. To be continued in separate issues.
|
Can you share user/client flow(s) that would be served by these changes? From the client (VS Code) perspective, for any kind of interoperability I would likely namespace URIs to include the MCP server they originate from, transforming any URIs passed to and from the server, so as to direct things to the right places. But I'm also not clear on how I would use these so I don't know if that's sufficient for the use case you have in mind...
This is not something we can assume people will follow. Anyone can publish to the registry and everyone tends to think their project is important :) |
|
FWIW just to leave a brief comment for now: I think this is a great frontier for the registry to expand into after it has some initial traction. I think I would defer it until we've got the basics up and running. |
|
I sincerely apologize for the disruption. This PR was accidentally closed due to a git history rewrite mistake. The PR has been recreated as #245 with all the original content preserved. Please continue any discussions or reviews on the new PR: #245 Again, I apologize for the inconvenience this has caused. |
This draft adds a list of URI schemes supported by the MCP Server.
It is only intended to be used for schemes that the author has good reason to believe will be widely adopted, or there is serious risk of interoperability issues unless the namespace is publicly declared.
When the registry is extended to Host/Client applications, this will allow Clients to offer extended features based on shared support for any particular scheme.
This has been opened for review and discussion on the utility and practical aspects of the idea.
Motivation and Context
The User Guide and Specification state that
This change enables MCP Server authors, and eventually MCP Client/Host authors to discover, choose and improve interoperability by sharing common resource usage patterns and SDKs.
Types of changes
Checklist
Additional context
It is expected that this should be a lightweight, community led effort but with enough oversight that vexatious usage is discouraged. Restricting documentation URLs to the hosting party or "known good" hosting locations would be expected.
Existing registries that may provide some inspiration:
There's an argument that the @modelcontextprotocol/registry would be a good candidate itself for publishing a Resource URI scheme to allow standardised registry-read operations.