Support Federation Between MCP Registry Instances

[WPrintz]

Problem

In enterprise environments with multiple teams or lines of business (LOBs), there's a need for hierarchical registry management:

• A central platform team manages enterprise-approved MCPs and Agents
• Individual LOBs/teams need their own registries for team-specific tools
• Teams want to selectively import only the approved MCPs/Agents they need from the parent registry

Currently, federation only supports external registries like Anthropic's MCP Registry and Workday ASOR, but not other MCP Gateway Registry instances.

Use Case

┌─────────────────────────────────────────────────────────┐
│           Enterprise MCP Registry (Platform Team)        │
│         - All approved MCPs and Agents                   │
│         - Enterprise governance and policies             │
└──────────────┬────────────────────┬─────────────────────┘
               │                    │
               ▼                    ▼
┌──────────────────────┐  ┌──────────────────────┐
│   LOB1 MCP Registry  │  │   LOB2 MCP Registry  │
│  - Subset of parent  │  │  - Subset of parent  │
│  - Team-specific     │  │  - Team-specific     │
│    tools only        │  │    tools only        │
└──────────────────────┘  └──────────────────────┘

Benefits

1. Reduced context overload - Teams only see the tools relevant to their work
2. Avoid tool confusion - Prevents agents from being confused by multiple tools with similar names across the enterprise
3. Governance at scale - Central team controls what's approved; LOBs control what they consume
4. Autonomy with guardrails - Teams can add their own tools while inheriting approved enterprise tools

Proposed Solution

Enable MCP Registry-to-Registry federation:

1. Configure parent registry as a federation source (similar to Anthropic/ASOR federation)
2. Selective import - Allow child registries to choose which MCPs/Agents to federate
3. Sync options - Support manual or scheduled synchronization
4. Visual tagging - Show federated servers with source registry identifier (e.g., ENTERPRISE tag)

Technical Considerations

• Authentication between registry instances
• Handling conflicts when same server exists in multiple sources
• Propagating updates from parent to child registries
• Access control for which child registries can federate from parent