Skip to content

DRAFT RFC - Supported URI Schemes for Server #30

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

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

evalstate
Copy link

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)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)
  • [] Documentation update

Checklist

  • I have read the MCP Documentation
  • 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:

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.

@evalstate evalstate closed this May 9, 2025
@evalstate evalstate reopened this May 9, 2025
@connor4312
Copy link
Collaborator

connor4312 commented May 13, 2025

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
Copy link
Contributor

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.

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

Successfully merging this pull request may close these issues.

4 participants