Proposal: Transition from Namespaces to Domains for Tool Classification in MCP

The proposal is conceptually similar to #993 which you can assume as baseline for this one. Please check that one out.

This shift would establish a stronger commitment at the MCP server level, where domains are explicitly registered, shared with user experience in mind. Simultaneously, we would preserve lower-level granularity for tools (maintaining the [domain]_[tool] structure) that enhances clarity and modularity for the flow. This also supports a move away from current namespace implementations that group tools through parameterization, which can obscure their purpose and reduce transparency.

This proposal is a refines our naming —specifically, transitioning from the use of namespaces to a more semantically grounded structure based on domains. While the current namespace implementation is clearly valuable, there is an opportunity to sharpen the conceptual model and align more closely with industry standards and user expectations.

This approach also requires a stronger commitment from MCP servers to ensure proper governance over their domains—covering onboarding, offboarding, and updates.

We aim to release this structure in azure-devops/mcp for early adopters, with the goal of demonstrating tangible improvements in customer experience aligned with the proposed protocol standard. This will also help clarify the two levels of abstraction: tools and prompts remain unchanged, while domains introduce an additional layer of semantic organization.

Rationale for Using Domains

The structure used in https://github.com/microsoft/azure-devops-mcp, where tools follow the [domain]_[tool] format, aligns with established industry practices. This mirrors how domains are used in natural language processing (NLP) systems. For example:

• https://developer.apple.com/documentation/AppIntents/app-intent-domains
• https://www.amazon.science/blog/amazon-scientists-use-transfer-learning-to-accelerate-development-of-new-alexa-capabilities

These platforms require developers to select predefined domains, making the approach both familiar and intuitive for users and developers alike.

Concerns with the Namespace Approach

The term “namespace” often implies a dynamic, loosely coupled structure that may not clearly reflect a product’s purpose or stability. From a customer perspective, it can feel abstract and disconnected from the assistant or agent experience. It also lacks the semantic clarity that “domain” provides when describing areas of knowledge or functionality.

Strategic Benefits of Adopting Domains

• Stronger conceptual alignment between tools and their functional areas
• Improved clarity and discoverability for customers and developers
• Enhanced backward compatibility across MCP versions through stable, domain-aligned boundaries
• Greater transparency by avoiding over-parameterized tool groupings under generic namespaces

Maintaining Implementation at the Lower Level

Even with domain enablement, tools remain visible and addressable at the lower level using the [domain]_[tool] structure. For example:

"servers": {  
  "ado": {  
    "type": "stdio",  
    "command": "mcp-server-azuredevops",  
    "id": "mseng",
    "domains": ["workitems", "wiki"]
  }  
}

Clarifying Tool Visibility and Domain Commitment

• The MCP protocol is responsible for supporting domain registration and ensuring their visibility.
• The MCP servers are responsible for distributing domains, applying them meaningfully across tools, and maintaining consistency to enhance user experience across versions.

Allowing Customers to Hardcode Domains

This capability is essential for production environments, particularly as more MCPs approach GA. It ensures predictability for workflow-specific applications that rely on fixed domain references.

Looking Ahead

Currently, domain enablement is handled manually by servers. In the future, LLMs should be capable of automatically discovering domains and enabling tools based on their descriptions—further simplifying configuration and improving scalability.

I welcome your feedback and look forward to aligning on this direction.