René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"SEP: Domains","articleBody":"## Proposal: Transition from Namespaces to Domains for Tool Classification in MCP\n\n\u003e The proposal is conceptually similar to https://github.com/modelcontextprotocol/modelcontextprotocol/issues/993 which you can assume as baseline for this one. Please check that one out. \n\nThis 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.\n\nThis 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. \n\nThis approach also requires a stronger commitment from MCP servers to ensure proper governance over their domains—covering onboarding, offboarding, and updates.\n\nWe 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.\n\n---\n\n## Rationale for Using Domains\n\nThe 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:\n\n- https://developer.apple.com/documentation/AppIntents/app-intent-domains  \n- https://www.amazon.science/blog/amazon-scientists-use-transfer-learning-to-accelerate-development-of-new-alexa-capabilities\n\nThese platforms require developers to select predefined domains, making the approach both familiar and intuitive for users and developers alike.\n\n---\n\n## Concerns with the Namespace Approach\n\nThe 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.\n\n---\n\n## Strategic Benefits of Adopting Domains\n\n- **Stronger conceptual alignment** between tools and their functional areas  \n- **Improved clarity and discoverability** for customers and developers  \n- **Enhanced backward compatibility** across MCP versions through stable, domain-aligned boundaries  \n- **Greater transparency** by avoiding over-parameterized tool groupings under generic namespaces  \n\n---\n\n## Maintaining Implementation at the Lower Level\n\nEven with domain enablement, tools remain visible and addressable at the lower level using the `[domain]_[tool]` structure. For example:\n\n```json\n\"servers\": {  \n  \"ado\": {  \n    \"type\": \"stdio\",  \n    \"command\": \"mcp-server-azuredevops\",  \n    \"id\": \"mseng\",\n    \"domains\": [\"workitems\", \"wiki\"]\n  }  \n}\n```\n\n---\n\n## Clarifying Tool Visibility and Domain Commitment\n\n- The **MCP protocol** is responsible for supporting domain registration and ensuring their visibility.  \n- The **MCP servers** are responsible for distributing domains, applying them meaningfully across tools, and maintaining consistency to enhance user experience across versions.  \n\n---\n\n## Allowing Customers to Hardcode Domains\n\nThis 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.\n\n---\n\n## Looking Ahead\n\nCurrently, 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.\n\n---\n\nI welcome your feedback and look forward to aligning on this direction.\n","author":{"url":"https://github.com/Novaes","@type":"Person","name":"Novaes"},"datePublished":"2025-07-31T23:45:24.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":3},"url":"https://github.com/1275/modelcontextprotocol/issues/1275"}