MCP federation in 2026: solved enough to use, not solved enough to forget
In 2024, “federated MCP” usually meant custom glue. If you needed one client to work across many MCP servers, you built naming rules, auth handoffs, and routing yourself.
By mid-2026, that pain is less visible. Not because federation is finished, but because the routine part of it moved into other layers: clients got better at not loading everything up front, gateways became a normal product category, and the MCP spec absorbed core authorization behavior. The problem did not disappear. It moved down the stack.
TL;DR
- The day-to-day problem of running multiple MCP servers is mostly handled by gateways, client behavior, and newer MCP auth rules rather than bespoke federation code.
- The June 18, 2025 MCP spec revision moved key auth behavior into the protocol, including OAuth resource server treatment and RFC 8707 resource indicators. Source: MCP changelog.
- Gateway tooling matured fast. An April 2026 ecosystem survey evaluated 17 aggregator/gateway tools and found flat aggregation, namespacing, single endpoints, and centralized auth/RBAC to be the converged category baseline. Source: Hey It Works survey.
- The hard part is still open: authorization propagation, session semantics through intermediaries, identity federation, and true nested federation are all explicitly still being worked through on the official roadmap or in ecosystem analysis. Sources: MCP roadmap, SEP-1933.
MCP federation is the problem of making many MCP servers usable through one client workflow without forcing the client to manage each server separately.
An MCP gateway is an intermediary that presents a single MCP-facing endpoint while aggregating, routing, or governing access to multiple MCP servers.
MCP Server Cards are a planned standard for exposing structured server metadata from a .well-known URL so browsers, crawlers, and registries can discover capabilities without connecting first, according to the MCP roadmap.
Why MCP federation feels easier now
Three changes explain most of the shift.
First, the spec took over more auth responsibility. The 2025-06-18 MCP changelog says MCP now classifies servers as OAuth resource servers and adds protected resource metadata so clients can discover the corresponding authorization server. The same revision also requires clients to implement resource indicators from RFC 8707 to prevent malicious servers from obtaining access tokens. The earlier 2025-03-26 revision had already brought Streamable HTTP and an OAuth 2.1 baseline.
That matters because “federation” used to hide a lot of auth improvisation. Once the protocol says more clearly what the client, server, and auth layers should do, fewer teams need custom side agreements.
Second, gateways became ordinary. An April 2026 ecosystem survey evaluated 17 aggregator/gateway tools: agentgateway, Bifrost, Cloudflare MCP Server Portals, IBM ContextForge, Kong, MCP-Gateway, MCP Mesh, mcp-proxy, MCPJungle, MCProxy, MCPX, MetaMCP, Microsoft MCP Gateway, Obot, Portkey AI Gateway, Supergateway, and Unla. The survey’s useful conclusion is not who “won.” It is that a category exists now. The baseline pattern has converged around flat aggregation, tool namespacing, one endpoint, and centralized auth or RBAC. One evidence caveat: that convergence claim rests on ecosystem survey data, not an official interoperability benchmark.
Third, clients and gateways stopped treating every tool definition as mandatory up-front context. At scale, tool metadata itself became a context-management problem. The practical answer has been lazy or deferred loading of tool descriptions, both in gateways and in clients. That is the same family of issue discussed in KV-Cache & Context Engineering: too much static context harms efficiency even before the model does useful work.
MCP gateway patterns that are now routine
The clearest sign of maturity is that gateway behavior has become predictable at the simple end.
If your goal is “run multiple MCP servers behind one endpoint,” you usually do not need a federation architecture project anymore. You choose a gateway or aggregator, decide how tool names should be namespaced, and plug it into your auth model.
The survey cited above puts it directly: the ecosystem has converged on “flat aggregation with RBAC — good for enterprise governance.” That is a narrower statement than “federation is solved,” but it is enough to change implementation choices.
A concrete example: agentgateway automatically namespaces tools with server-name prefixes across federated servers — and in its federation tutorial, adding another server touches only the gateway config while the client keeps pointing at the same endpoint. That is exactly the kind of work teams hand-built early on. When two upstream servers expose the same tool name, the gateway resolves the collision by prefixing — a representative (illustrative) gateway-exposed tool list:
// Upstream A: "github-service" · Upstream B: "local-fs"
// Gateway-exposed tools:
[
{ "name": "github-service_read_file", "description": "Read file contents from the GitHub repository..." },
{ "name": "local-fs_read_file", "description": "Read file contents from the local workspace..." }
]So the practical guidance in 2026 is simple:
- Use a gateway for flat aggregation.
- Let the current MCP auth model do its job.
- Avoid eager tool injection where possible.
That handles a large share of real deployments.
Authorization propagation is still open
This is the part people discover late if they assume the gateway layer solved everything.
The official MCP roadmap, last updated 2026-03-05, is explicit under Enterprise Readiness:
"Gateway and proxy patterns: well-defined behavior when a client does not connect directly to a server but routes through an intermediary. This may include authorization propagation, session semantics, and what the gateway is allowed to see."
That is the unresolved core. Once a gateway sits in the path, basic OAuth correctness is not the only question. You also need a consistent answer to these questions:
- Whose identity is the downstream server actually seeing?
- Which scopes or entitlements survive the hop?
- What may the intermediary inspect, transform, cache, or log?
- How should clients reason about trust boundaries across that hop?
The roadmap adds another important line:
"We expect an Enterprise WG to form to own this. Much of the output will likely land as extensions rather than core specification changes."
That means the standards story is honest about scope. Not every federation concern will become one universal core rule.
Ecosystem reporting also points in the same direction. The A2A-MCP roadmap analysis reports identity-propagation failures as the top reported integration blocker in 2025 enterprise pilots. That is not an official roadmap claim, so treat it as ecosystem analysis, not protocol authority. Still, it lines up with the official gap.
Identity federation is in-flight, not shipped
The strongest signal that federation's hard core is still being standardized is that the word itself now names an open proposal. Under Security & Authorization — an "on the horizon" item, not yet a top priority — the roadmap records: "Sponsored work is already underway: SEP-1932 (DPoP) and SEP-1933 (Workload Identity Federation)." For enterprise-managed auth, the roadmap points at SSO-integrated flows via Cross-App Access as the paved path away from static client secrets.
In-flight is the operative phrase: these are proposals with sponsors, not shipped protocol. If your design assumes a workload in one trust domain can act against an MCP server in another with standards-defined identity, you are building on a SEP, not a spec.
Session semantics and nested federation remain hard
Auth is not the only unresolved systems problem.
Under Transport Evolution and Scalability, the roadmap states:
"Scalable session handling: define how sessions are created, resumed, and migrated so that server restarts and scale-out events are transparent to connected clients."
That is a classic distributed-systems issue. A simple single-instance server can pretend sessions are local. A real deployment behind load balancers cannot. If an MCP client connects through a gateway to a fleet of servers, session creation, resumption, and migration stop being implementation details. They become interoperability concerns.
Then there is true federation rather than flat aggregation. The April 2026 survey says this plainly:
"No tool provides all of: (a) a clean three-level hierarchy with 1:many endpoint-to-namespace, (b) first-class nested/federated aggregation, (c) per-client tool visibility as a distinct dimension, and (d) lightweight self-hosted deployment."
That quote is the most precise short description of what remains unsolved. Flat aggregation is a product category. Trees and meshes are still open design space.
So if your topology is “many servers behind one gateway,” you are in mature territory. If your topology is “gateways behind gateways, with per-client visibility and inherited identity rules,” you are still near the edge.
MCP Registry, server.json, and discovery
Discovery is improving, but it is not finished either.
The official MCP Registry has been in preview since 2025-09-08. Its repository describes a standardized server.json format with a unique name such as io.github.user/server-name, plus package or location details, execution instructions, and discovery metadata. Sources: registry about, registry repo.
This matters for federation because discovery used to be one more custom layer. Standard metadata reduces the amount of out-of-band setup needed for tools, gateways, and registries to understand what a server is.
But the registry is not GA. The registry repository says API freeze for v0.1 landed on 2025-10-24, with v1 GA still pending. So the right mental model is “official and useful, still settling.”
The roadmap also points to the next discovery layer: Server Cards. These are meant to expose structured metadata from a .well-known URL so external systems can inspect capability metadata before opening a live MCP connection. That fits the same pattern as the rest of federation in 2026: less hidden custom glue, more standard surface area.
What to do if you are integrating MCP today
Use a boring design first.
If you need one client to access multiple MCP servers, deploy a gateway. Prefer flat aggregation unless you have a concrete reason not to. Use namespacing, centralized auth, and deferred tool loading. Treat identity propagation through intermediaries as a design risk, not an implementation footnote.
Also separate three concerns that early MCP deployments often collapsed into one:
- aggregation of tools
- authentication and authorization
- session continuity across distributed infrastructure
The protocol now helps more with the second. The ecosystem helps more with the first. The third is still visibly under construction.
That distinction saves time because it keeps you from expecting a gateway purchase to solve a standards problem.
Common questions
What is MCP federation?
MCP federation is the problem of making many MCP servers appear usable through one client workflow, usually through aggregation, routing, namespacing, shared auth, and discovery across multiple servers.
What is an MCP gateway?
An MCP gateway is an intermediary that sits between clients and multiple MCP servers, exposing a single endpoint while handling tasks like tool aggregation, namespacing, and centralized auth or RBAC.
How do I run multiple MCP servers?
In 2026, the usual approach is not to hand-roll federation. You deploy an MCP gateway or aggregator, rely on the current MCP auth model, and use lazy or deferred tool loading to avoid flooding the client context.
Is MCP federation a solved problem?
Only the everyday layer is mostly solved. Flat aggregation, single endpoints, and centralized auth are widely available, but authorization propagation, session semantics, nested federation, and identity federation are still open work on the roadmap.
What is the MCP Registry / server.json?
The MCP Registry is the official registry, in preview since 2025-09-08, for standardized MCP server metadata. Its server.json format describes identity, package or location, execution instructions, and discovery metadata.
What is authorization propagation in MCP?
Authorization propagation is the transfer of the original client's identity and permissions through one or more gateways to the final MCP server, so downstream services can enforce the right permissions. It is still open work on the MCP roadmap.
Related
If you are deploying MCP in production, memory is usually not the gateway problem. It is a cross-cutting service behind whatever gateway you choose. Mnemoverse exposes that layer through its MCP server docs.
Mnemoverse is a persistent-memory API for AI agents. Free key: console.mnemoverse.com · Docs: Getting Started