MCP Federation: One Endpoint, Many Servers, Explained

Short answer: MCP federation is the pattern where one MCP endpoint speaks on behalf of many MCP servers. Your agent connects once; behind that single connection, a federating service merges the tool catalogs of every upstream server into one namespaced list, brokers authentication per upstream, and routes each call to the right backend. The agent never knows or cares where a tool actually lives.

The word gets used loosely, so let's pin down what federation actually involves, and what separates it from a mere proxy.

The four jobs of a federating endpoint

Merging catalogs with namespaces. Every upstream server brings its own tools, and many of them share names: every SaaS product has a search, a list, a get. Federation resolves the collisions by namespacing, typically service__tool: github__create_issue sits next to crm__search_contacts in one flat list. The naming convention sounds like a detail. It is the difference between an agent that picks the right search and one that guesses among five.

Brokering auth per upstream. Each upstream server has its own idea of authentication: OAuth here, an API key there, nothing for public tools. The federation layer holds those credentials (encrypted, ideally per secret) and attaches the right one to each routed call. The agent authenticates once, to the endpoint, and never touches the upstream secrets at all. This is where federation quietly becomes a security feature: the alternative is credentials scattered across every client config, which we have [complained about at length](/blog/stop-pasting-api-keys).

Routing and translating. A call to crm__search_contacts gets unwrapped, sent to the CRM's server with the right credentials, and the result flows back under the federated name. Good federation also smooths over differences between upstream server generations and transports, so one modern endpoint can front a mixed fleet.

Reflecting change at runtime. Connect a new upstream, disconnect an old one, and the federated tools list changes accordingly. MCP has a mechanism for exactly this (the list-changed notification), so a client can learn mid-session that new tools exist. Your agent's capabilities become a property of your connection set, not of a config file that requires editing and restarting.

Federation vs a plain proxy

A proxy forwards traffic to one destination; it is a pipe with a different address. Federation is a many-to-one composition with its own catalog, its own auth brokering, and its own routing decisions. The test: does the middle layer present a merged tools list under namespaces, and can it route two calls in the same session to two different backends? If yes, it federates. If it just relays a single server, it is a proxy, whatever the marketing says.

There is a subtlety worth knowing: from the client's perspective, a federating endpoint is itself just an MCP server. That is the elegance of the pattern. The protocol composes, so one server can be a doorway to twenty. The client-side view of this is covered in [MCP gateway vs MCP server](/blog/mcp-gateway-vs-mcp-server).

What federation buys you, concretely

• One connection per client instead of N. Ten servers times three clients is thirty configs without federation, three with it.
• Central add and remove. A new tool arrives for every agent at once; a revoked tool disappears everywhere at once. Nobody edits JSON on a Tuesday night.
• One choke point for policy. Because every call passes through the federation layer, that layer can enforce scopes, log an [audit trail](/blog/ai-agent-audit-trail), and apply limits. You cannot bolt that onto twenty direct connections.
• A place to fix the token problem. A merged catalog is also a controllable catalog: the federation layer decides what the agent's tools list looks like, which is the structural lever against schema bloat we described in [the context tax](/blog/the-context-tax).

Where federation runs in practice

The component that does all this is usually called an MCP gateway, and the full picture of that product category (what it adds beyond federation: vaults, audit, memory) lives in [what is an MCP gateway](/blog/what-is-an-mcp-gateway). Federation is the core mechanism; the gateway is the product built around it.

For the record and with the obvious bias: [Tulimoa's gateway](/gateway) federates your connected servers behind one endpoint with exactly this shape, namespaced tools, brokered OAuth, a runtime-updating catalog, and a memory layer on top. Early beta, not self-serve yet.

Frequently asked questions

Is MCP federation part of the MCP spec?

The spec provides the building blocks (servers, clients, tool lists, list-changed notifications) but does not define federation as a feature. Federation is an architecture pattern built with those blocks: a server that is also a client of many other servers.

Does federation add latency?

One extra hop, typically small next to the upstream call itself and tiny next to model inference time. In exchange you drop whole rounds of failed calls, because namespacing reduces wrong-tool picks. Net latency in real workflows usually improves.

How is federation different from just connecting multiple servers in my client?

Connecting five servers in the client gives you five separate connections, five auth flows, and a merged-by-accident tool list with name collisions, per client, per machine. Federation does the merging once, server-side, with namespaces, shared auth handling, and central control.