Drop the name-based validation of Remote.url (just validate it is a URL)

[ashubham]

Describe the bug
When trying to run

mcp-publisher publish

We get this error:

Publishing to https://registry.modelcontextprotocol.io...
Error: publish failed: server returned status 400: 
{"title":"Bad Request","status":400,"detail":"Failed to publish server",
"errors":[
  {"message":"remote URL https://agent.thoughtspot.app/mcp does not match namespace 
      io.github.thoughtspot/mcp-server: remote URL host agent.thoughtspot.app does not match 
      publisher domain thoughtspot.github.io"
  }
]}

While the docs clearly state that when io.github.companyname scheme is used, any remote URL is allowed, as long as authenticated to github.

https://github.com/modelcontextprotocol/registry/blob/main/docs/guides/publishing/publish-server.md#url-validation-requirements

Expected behavior
This should successfully publish.

[tadasant]

Thank you for raising this!

For context, I think this is currently a mistake in the docs (i.e. implementation is as-intended, docs are incorrect):

For io.github.username/* namespaces: No URL restrictions (but you must authenticate via GitHub)

As designed, our goal was to prevent people from submitting Remote.url's they do not control. So we required that your namespace verification match up with the Remote URL.

However, thinking through this further, I see several issues with that goal:

• Someone might namespace their MCP servers like com.companyname.servers/my-mcp but the server might be hosted at mcp.companyname/mcp
• If you're using a third party hosting service, you can't align
• As you (@ashubham) are pointing out, there is demand for being able to point to a server from an io.github namespace. And because we don't allow name mutability (only by creating an entirely new server), this is pretty prohibitive for you.

So I think I'm convinced we should drop this requirement altogether. Just allow people to set Remote.url to any valid URL they want; no need for alignment with the reverse DNS namespace. In theory, that could lead to people spamming the registry with many entries under different names for the same Remote.url, but in practice I think sub-registries will be good at filtering this kind of thing out, and there will be little/no incentive to spamming in this way.

One use case I still feel weird about: if I find a URL in the wild, like https://api.githubcopilot.com/mcp/, how do I know the correct Registry metadata for it is the name: com.github/mcp server and not the name: com.spamdomain/github MCP server? But I think centralized registry is the wrong way to solve this: we should make a GET https://api.githubcopilot.com/mcp/ or .well-known-adjacent type flow possible where you can query the URL directly (or start the MCP initialization process) to properly identify the name of the server hosted there.

---

tl;dr I think we should just drop this name-based validation of Remote.url altogether (leaving it as a simple URL validation field). What do you think @modelcontextprotocol/registry-wg ?

[domantas-jurkus-dcd]

@tadasant just to add: https://smithery.ai/ is a popular MCP server host service, it would be handy to be able to point to MCP servers hosted on there.

But the attack vector would remain: a malicious users could potentially point to any server as their own. Not sure how sub-registries would fix that.

[tadasant]

But the attack vector would remain: a malicious users could potentially point to any server as their own. Not sure how sub-registries would fix that.

This isn't an security problem per se. If you trust com.microsoft/mcp-server (the name), it's up to microsoft.com to not point a URL another domain; they're still in control.

[TheBestMoshe]

Just want to add a +1 to allowing other server domains that don't match the host in the reverse dns name.

I want to keep all user generated content (including MCP servers, which return data controlled by end users) off of my primary domain. The primary domain is a .com while mcp servers are served from .net.

If we want to solve the spam problem, then perhaps there can also be domain verification for the server hostnames? As in, each hostname in the server list also needs to be validated.

[domdomegg]

Sorry for the delay here, must have slipped through my GitHub notifs!

tl;dr I think we should just drop this name-based validation of Remote.url altogether (leaving it as a simple URL validation field). What do you think @.modelcontextprotocol/registry-wg ?

Yes I am supportive of this change @tadasant

[rdimitrov]

+1 from me too 👍

[tadasant]

👍 would accept a PR (making the change as described in my prior comment) from anyone if someone wants to jump on this

@TheBestMoshe @domantas-jurkus-dcd @ashubham

[joelverhagen]

@tadasant, I can submit a PR for this.

[joelverhagen]

I have opened a PR to resolve this issue as well as a similar issue for websiteUrl.
#769

[jonathanhefner]

Fixed by #769.