DRAFT RFC - Supported URI Schemes for Server

[evalstate]

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

• Servers can define their own custom URI schemes.
• (Best Practice) - When implementing resource support: ...Document your custom URI schemes
• ...implementations are always free to use additional, custom URI schemes

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

• [ ] Bug fix (non-breaking change which fixes an issue)
• [X] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to change)
• [] Documentation update

Checklist

• [X] I have read the MCP Documentation
• [X] My code follows the repository's style guidelines
• [ ] New and existing tests pass locally
• [ ] I have added appropriate error handling
• [ ] I have added or updated documentation as needed

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:

• https://www.schemastore.org/json/
• https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml
• PyPi / NPM
• The @modelcontextprotocol/registry project itself.

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.

[connor4312]

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...

It is only intended to be used for schemes that the author has good reason to believe will be widely adopted

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 :)

[tadasant]

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.

[domdomegg]

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.