Namespacing of MCP servers: reverse DNS or forward DNS?

[tadasant]

Pre-submission Checklist

• I have verified that this discussion would not be more appropriate as an issue in a specific repository
• I have searched existing discussions to avoid duplicates

Discussion Topic

We feel pretty good that DNS with TXT record verification is the right path forward for namespacing the name field of MCP servers in the centralized metaregistry.

An open question that @toby and I have been discussing: should we use reverse-DNS or forward-DNS?

If we use reverse-DNS, examples are:

• com.microsoft/playwright - Playwright MCP server owned by the microsoft.com domain owners
• io.github.microsoft/playwright - Playwright MCP server owned by the GitHub org microsoft
• io.github.tadasant/playwright - Playwright MCP server owned by the GitHub user tadasant

Forward-DNS would instead be: microsoft.com/playwright, microsoft.github.io/playwright, and tadasant.github.io/playwright

My take: I don't feel super strongly, but forward DNS feels like it would potentially cause confusion with web URL's. It would create the implicit expectation that I published something at https://tadasant.github.io/playwright, which I don't think is desirable. Reverse-DNS feels cleaner to me.

Curious to hear community opinions in support of one direction or the other.

[wong2]

Your concern makes a lot of sense, that it might cause a lot of confusion.

[xuechaos]

Forward-DNS is very similar to the URL, reverse-DNS is better, Some projects have the package name as the id that look like reverse DNS，are easy to understand.

[ariadng]

Reverse-DNS is much better, as it aligns with many namespace or package name conventions (e.g. Android and iOS apps).

[tadasant]

@patwhite asked in the CWG Discord:

@tadasant I gave a quick review to the registry with an eye on our discussions about namespacing, how are you thinking about this bud? I see you have a simple hierarchy around the server name, but I think that's sort of orthogonal to protocol level namespacing, but maybe I'm missing something? I do think the only real thing to align the namespace proposal with the registry here is aligning on a prefix character - if we want to use a @ or not, otherwise I think things just click together

My response:

I have seen folks discussing naming collisions in the context of loading Tools into context -- so far I am not aware of other compelling reasons to introduce namespacing. I think ⁠tool interfaces are a better solution thread for concerns like "grouping" tools.

That problem is being solved today hackily by clients who are prefixing the server "name" to all tools, like:

• sentry__get_issues
• github__get_issues

So what we need - and the registry can provide - is a guaranteed unique name for the sentry/github part of the tool call name, such that this hacky solution becomes reliable.

The registry's reverse-DNS name field for the server should be able to provide this, and maybe it's worth codifying this behavior into the spec. It's probably a one line addition like, Clients SHOULD prefix tool names with Server names when loading them into context

[patwhite]

I have seen folks discussing naming collisions in the context of loading Tools into context -- so far I am not aware of other compelling reasons to introduce namespacing. I think ⁠tool interfaces are a better solution thread for concerns like "grouping" tools.

So, this is great - namespacing is basically a generic form of a toolset that allows for grouping EVERYTHING, not just tools. So, you could implement a toolset with namespaces by only having tools in it, but with generic namespacing you have the option to expose tools, prompts, resources, and resources templates (and any future capabilities that get added).

[patwhite]

Here's the proposal btw: modelcontextprotocol/modelcontextprotocol#334

It's a very simple abstraction for grouping capabilities.

I don't think interfaces are related to this, toolsets more so. this is about grouping large deployments.