Research · 2026-05-05

MCP-of-MCPs: federating servers under one governed endpoint

design-docmcpg

The relay and trust design that lets MCPG proxy other MCP servers as one unified, audited tool list — including the invocation envelope that keeps identity intact across hops.

Teams do not have one MCP server; they have a drawer full. Federation is MCPG's answer to the drawer: upstream MCP servers — vendor tools, internal services, other gateways — appear as one governed tool list behind one endpoint, with the same identity, policy, and audit treatment as native backends.

The RFC series works through the problems that make this harder than "forward the JSON":

  • Namespace collisions. Two upstreams both export search. The relay applies stable, configurable prefixes so consumers see an unambiguous list and calls route deterministically.
  • Capability drift. Upstreams change their tool lists at runtime. The relay re-lists on notification, re-validates against policy, and never serves a tool the operator has not allowed through.
  • Identity across hops. The invocation envelope carries the original caller's identity and the gateway's attestation, so an upstream — or an auditor replaying the ledger — can distinguish "the gateway called this" from "Alice's agent called this through the gateway."
  • Trust boundaries. Each upstream gets an explicit trust level; policy can allow a tool from one federation partner and deny the same name from another.

The consequence for operators is the useful one: adding a new MCP server to your fleet is a config entry, not a new deployment — and every call through it lands in the same tamper-evident audit trail as everything else. One URL for agents; one drawer, finally organized, for you.

Canonical: mcpg repo · docs/rfcs-archive/mcpg-proxy/ (relay protocol + invocation envelope series)