MCP Federation: ein Endpunkt, viele Server, erklärt
Die kurze Antwort: MCP Federation ist das Muster, bei dem ein MCP-Endpunkt im Namen vieler MCP-Server spricht. Dein Agent verbindet sich einmal; hinter dieser einen Verbindung verschmilzt ein föderierender Dienst die Tool-Kataloge aller Upstream-Server zu einer namespaced Liste, vermittelt die Authentifizierung pro Upstream und routet jeden Aufruf zum richtigen Backend. Der Agent weiß nie, wo ein Tool wirklich lebt, und es muss ihn auch nicht kümmern.
Das Wort wird locker benutzt, also nageln wir fest, was Federation wirklich beinhaltet, und was sie von einem bloßen Proxy trennt.
Die vier Jobs eines föderierenden Endpunkts
Kataloge verschmelzen, mit Namespaces. Jeder Upstream-Server bringt eigene Tools mit, und viele teilen sich Namen: Jedes SaaS-Produkt hat ein search, ein list, ein get. Federation löst die Kollisionen per Namespace, typischerweise service__tool: github__create_issue steht neben crm__search_contacts in einer flachen Liste. Die Namenskonvention klingt nach Detail. Sie ist der Unterschied zwischen einem Agenten, der das richtige search wählt, und einem, der unter fünfen rät.
Auth pro Upstream vermitteln. Jeder Upstream-Server hat seine eigene Vorstellung von Authentifizierung: hier OAuth, dort ein API-Key, nichts bei öffentlichen Tools. Die Federations-Schicht hält diese Zugangsdaten (verschlüsselt, idealerweise pro Geheimnis) und hängt jedem gerouteten Aufruf die richtigen an. Der Agent authentifiziert sich einmal, beim Endpunkt, und berührt die Upstream-Geheimnisse überhaupt nicht. Hier wird Federation still zum Sicherheits-Feature: Die Alternative sind Zugangsdaten, verstreut über jede Client-Config, worüber wir uns [ausführlich beschwert haben](/de/blog/stop-pasting-api-keys).
Routen und übersetzen. Ein Aufruf von crm__search_contacts wird ausgepackt, mit den richtigen Zugangsdaten an den Server des CRM geschickt, und das Ergebnis fließt unter dem föderierten Namen zurück. Gute Federation glättet auch Unterschiede zwischen Server-Generationen und Transports, sodass ein moderner Endpunkt eine gemischte Flotte vertreten kann.
Änderungen zur Laufzeit spiegeln. Verbinde einen neuen Upstream, trenn einen alten, und die föderierte Tool-Liste ändert sich entsprechend. MCP hat genau dafür einen Mechanismus (die list-changed-Notification), ein Client kann also mitten in der Session erfahren, dass neue Tools existieren. Die Fähigkeiten deines Agenten werden eine Eigenschaft deines Verbindungs-Sets, nicht einer Konfigdatei, die Editieren und Neustarten verlangt.
Federation vs. einfacher Proxy
Ein Proxy leitet Verkehr an ein Ziel weiter; er ist ein Rohr mit anderer Adresse. Federation ist eine Viele-zu-eins-Komposition mit eigenem Katalog, eigener Auth-Vermittlung und eigenen Routing-Entscheidungen. Der Test: Präsentiert die Mittelschicht eine verschmolzene Tool-Liste unter Namespaces, und kann sie zwei Aufrufe derselben Session an zwei verschiedene Backends routen? Wenn ja, föderiert sie. Wenn sie nur einen einzelnen Server durchreicht, ist sie ein Proxy, egal was das Marketing sagt.
Eine Feinheit lohnt das Wissen: Aus Sicht des Clients ist ein föderierender Endpunkt selbst nur ein MCP-Server. Das ist die Eleganz des Musters. Das Protokoll komponiert, ein Server kann eine Tür zu zwanzig sein. Die Client-Sicht darauf steht in [MCP Gateway vs. MCP-Server](/de/blog/mcp-gateway-vs-mcp-server).
Was Federation dir konkret kauft
- Eine Verbindung pro Client statt N. Zehn Server mal drei Clients sind dreißig Configs ohne Federation, drei mit ihr.
- Zentrales Hinzufügen und Entfernen. Ein neues Tool kommt für alle Agenten gleichzeitig an; ein widerrufenes verschwindet überall gleichzeitig. Niemand editiert an einem Dienstagabend JSON.
- Ein Engpass für Regeln. Weil jeder Aufruf durch die Federations-Schicht läuft, kann diese Schicht Scopes durchsetzen, einen [Audit-Trail](/de/blog/ai-agent-audit-trail) schreiben und Limits anwenden. Auf zwanzig Direktverbindungen kannst du das nicht nachrüsten.
- Ein Ort, an dem sich das Token-Problem lösen lässt. Ein verschmolzener Katalog ist auch ein steuerbarer Katalog: Die Federations-Schicht entscheidet, wie die Tool-Liste des Agenten aussieht, und das ist der strukturelle Hebel gegen Schema-Aufblähung aus [der Context Tax](/de/blog/the-context-tax).
Wo Federation in der Praxis läuft
Die Komponente, die all das tut, heißt üblicherweise MCP Gateway, und das volle Bild dieser Produktkategorie (was sie über Federation hinaus ergänzt: Vaults, Audit, Memory) steht in [Was ist ein MCP Gateway?](/de/blog/what-is-an-mcp-gateway). Federation ist der Kern-Mechanismus; das Gateway ist das Produkt drumherum.
Fürs Protokoll und mit offensichtlicher Voreingenommenheit: [Tulimoas Gateway](/de/gateway) föderiert deine verbundenen Server hinter einem Endpunkt in genau dieser Form, namespaced Tools, vermitteltes OAuth, ein Katalog, der sich zur Laufzeit aktualisiert, und eine Memory-Schicht obendrauf. Frühe Beta, noch nicht self-serve.
Häufige Fragen
Ist MCP Federation Teil der MCP-Spezifikation?
Die Spezifikation liefert die Bausteine (Server, Clients, Tool-Listen, list-changed-Notifications), definiert Federation aber nicht als Feature. Federation ist ein Architektur-Muster aus diesen Bausteinen: ein Server, der zugleich Client vieler anderer Server ist.
Fügt Federation Latenz hinzu?
Einen zusätzlichen Hop, typischerweise klein neben dem Upstream-Aufruf selbst und winzig neben der Inferenz-Zeit des Modells. Im Tausch entfallen ganze Runden gescheiterter Aufrufe, weil Namespacing falsche Tool-Wahlen reduziert. Die Netto-Latenz realer Workflows wird meist besser.
Was unterscheidet Federation davon, einfach mehrere Server im Client zu verbinden?
Fünf Server im Client sind fünf getrennte Verbindungen, fünf Auth-Flows und eine zufällig zusammengewürfelte Tool-Liste mit Namenskollisionen, pro Client, pro Maschine. Federation verschmilzt einmal, serverseitig, mit Namespaces, gemeinsamer Auth-Behandlung und zentraler Kontrolle.