Skip to content

Enforce requirement: remote URL's in official registry must match reverse-DNS namespace #180

Closed

Description

@tadasant

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.

Activity

  1. domdomegg commented on Aug 19, 2025

    @domdomegg
    Member

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

  2. domdomegg commented on Aug 21, 2025

    @domdomegg
    Member

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

  3. tadasant commented on Aug 21, 2025

    @tadasant
    MemberAuthor

    By default I'd be in favor of this

    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.

  4. self-assigned this
    on Aug 26, 2025
  5. added a commit that references this issue on Aug 26, 2025
    923b2e0
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

go-live blockerThis issue is one we need to address prior to initial go-liveimplementation workShovel-ready to write code

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions