Repository navigation
Drop the name-based validation of Remote.url (just validate it is a URL) #494
Description
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.
Expected behavior
This should successfully publish.
Reacted by Pavel Shklovsky, Ivan Biruk, Danny Roosevelt, Babbage, Vincent Emonet, Matouš Dzivjak, Moshe Grunwald and Anton Risch
Activity
tadasant commentedon Sep 24, 2025
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):
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:
com.companyname.servers/my-mcpbut the server might be hosted atmcp.companyname/mcpio.githubnamespace. 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.urlto 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 differentnames for the sameRemote.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 thename: com.github/mcpserver and not thename: com.spamdomain/githubMCP server? But I think centralized registry is the wrong way to solve this: we should make aGET 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 thenameof the server hosted there.tl;dr I think we should just drop this
name-based validation ofRemote.urlaltogether (leaving it as a simple URL validation field). What do you think @modelcontextprotocol/registry-wg ?domantas-jurkus-dcd commentedon Sep 26, 2025
@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 commentedon Sep 26, 2025
This isn't an security problem per se. If you trust
com.microsoft/mcp-server(thename), it's up to microsoft.com to not point a URL another domain; they're still in control.TheBestMoshe commentedon Sep 26, 2025
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
.comwhile 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 commentedon Nov 7, 2025
Sorry for the delay here, must have slipped through my GitHub notifs!
Yes I am supportive of this change @tadasant
rdimitrov commentedon Nov 10, 2025
+1 from me too 👍
tadasant commentedon Nov 11, 2025
👍 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
[-]Domain mismatch when publishing with Github.[/-][+]Drop the name-based validation of Remote.url[/+][-]Drop the name-based validation of Remote.url[/-][+]Drop the name-based validation of Remote.url (just validate it is a URL)[/+]joelverhagen commentedon Nov 14, 2025
@tadasant, I can submit a PR for this.
joelverhagen commentedon Nov 14, 2025
I have opened a PR to resolve this issue as well as a similar issue for
websiteUrl.#769
Remove namespace match validation for websiteUrl and remote URL (#769)
jonathanhefner commentedon Nov 17, 2025
Fixed by #769.
Remove namespace match validation for websiteUrl and remote URL (mode…