Add MCP server "domains"

[Novaes]

Add domains

GitHub issue number

#386

Associated Risks

Replace by possible risks this pull request can bring you might have thought of

✅ PR Checklist

• I have read the contribution guidelines
• I have read the code of conduct guidelines
• Title of the pull request is clear and informative.
• 👌 Code hygiene
• 🔭 Telemetry added, updated, or N/A -- N/A: tracking domain enabling will be a follow up
• 📄 Documentation added, updated, or N/A -- N/A: we aligned PM handling it
• 🛡️ Automated tests added, or N/A

🧪 How did you test it?

Unit test added
Local run -- todo add tests images here

Context

SEP-993 is moving to Groups and Tags
We have been discussing with interested parties and authors, Groups is quite loosely coupled, which can be categorized with:

• Semantic Groups
• Functional Groups

It makes sense for Groups and Tags proposal be as generic as possible. With domains we introduce a semantic group which in terms of implementation is just syntax sugar for groups, but it carries more governance on MCP servers around those.

Some open questions when Groups go to prod:

• Some other edge case behaviors: e.g. behavior for someone defining domains and groups
• Standard way to expose and catalog those domains (give viz at Microsoft for them)

Important

• Not all MCP servers necessarily require to have domains. For instance, if your groups are organized around functional roles rather than strict semantic boundaries, it may be reasonable not to enforce domain governance.
• For those servers that do require domain structuring, this capability is supported through the Groups and Tags SEP. Domains are syntax sugar for groups, which appear to be the de-facto implementation approach at the protocol level.

More info on protocol alignment: Tool Filtering with groups and Tags

More info: SEP-1300: Tool Filtering with Groups and Tags · Issue #1300 · modelcontextprotocol/modelcontextprotocol

Client-side filtering of tools: Agent fetches all the tools with no filtering, organizes them by groups and tags within the host application, then provides the appropriate tools to the LLM when needed via whatever means, e.g., semantic search.

Server-side filtering of tools: Agent presents a list of groups to the LLM. When the LLM decides it needs a tool but doesn't have an appropriate one in its context, it may request the list of tools in a particular group or set of groups.

[github-actions]

Dependency Review

✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.

Scanned Files

None