You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Enforce requirement: remote URL's in official registry must match reverse-DNS namespace #180
This means that if you have an MCP server for which you want to declare a remotes entry at e.g. subdomain.microsoft.com/mcp, your MCP server must be in the namespace com.microsoft.subdomain.
Secondarily, this requirement enables enforcement that if someone else has published a remote server at that URL, you cannot also do so (no duplicates). This prevents spam attempts to list the same server many times.
E.g. I want to publish an MCP at my-cool-server.vercel.app/thing-mcp from a GitHub repository github.com/username/thing-mcp. It might be easier for me to set up GitHub OIDC etc. publishing, and to not have to manage extra secrets and host extra stuff in my vercel app. Seems overly restrictive to not publish to username.github.io/thing-mcp
Case 2: wanting a higher level domain
Microsoft wants to publish an MCP at some-azure-service.prod.mcp.azure.microsoft.com, but really would like to publish in the namespace com.microsoft or maybe com.microsoft.azure, given then all their MCPs would be under their namespace.
This will also likely be painful for subregistries because then it's harder to give companies consistent identities.
(alternative approach: put in this requirement for the go-live - it's an easy validation to do! then remove it if people complain / do actually find it overly constraining, because doing it this way would be a non-breaking change)
alternative approach: put in this requirement for the go-live - it's an easy validation to do! then remove it if people complain / do actually find it overly constraining, because doing it this way would be a non-breaking change)
I agree it's not ideal. But I also don't can't think offhand how else we can reliably prevent duplicate listings without building some separate verification system. When I look up a remote_url in the registry, I want to be able to know which metadata entry is the canonical one.
Maybe eventually this somehow coalesces with .well-known work and it's validated that way as an alternative to reverse-DNS alignment here.
Activity
domdomegg commentedon Aug 19, 2025
I worry this might be quite limiting - e.g.:
Case 1: GitHub based
E.g. I want to publish an MCP at my-cool-server.vercel.app/thing-mcp from a GitHub repository github.com/username/thing-mcp. It might be easier for me to set up GitHub OIDC etc. publishing, and to not have to manage extra secrets and host extra stuff in my vercel app. Seems overly restrictive to not publish to
username.github.io/thing-mcpCase 2: wanting a higher level domain
Microsoft wants to publish an MCP at some-azure-service.prod.mcp.azure.microsoft.com, but really would like to publish in the namespace com.microsoft or maybe com.microsoft.azure, given then all their MCPs would be under their namespace.
This will also likely be painful for subregistries because then it's harder to give companies consistent identities.
domdomegg commentedon Aug 21, 2025
(alternative approach: put in this requirement for the go-live - it's an easy validation to do! then remove it if people complain / do actually find it overly constraining, because doing it this way would be a non-breaking change)
tadasant commentedon Aug 21, 2025
By default I'd be in favor of this
I agree it's not ideal. But I also don't can't think offhand how else we can reliably prevent duplicate listings without building some separate verification system. When I look up a remote_url in the registry, I want to be able to know which metadata entry is the canonical one.
Maybe eventually this somehow coalesces with .well-known work and it's validated that way as an alternative to reverse-DNS alignment here.
feat: implement DNS namespace validation and remote URL uniqueness ch…
feat: implement DNS namespace validation and remote URL uniqueness ch…
Allow remote URLs to be shared across server names (#1806)