Hier ist das Entscheidende an MCP-Proxys, das die meisten Architekturdiagramme stillschweigend auslassen: Sie merken erst, dass Sie einen brauchen, wenn Sie sechs Backend-MCP-Server, drei verschiedene Transporttypen, keine zentrale Authentifizierungsdurchsetzung verwalten und zunehmend das Gefühl haben, dass irgendwo in der Kette zur falschen Zeit das Falsche für den falschen Agenten offengelegt wird.
Die NSA-Cybersicherheitsleitlinie zu MCP vom Mai 2026 formuliert es klar: Das Protokoll läuft bereits produktiv in Unternehmens-, Finanz-, Rechts- und Softwareentwicklungsumgebungen. In vielen dieser Implementierungen fehlt die Authentifizierung vollständig. Mehrere verfügen über keinerlei rollenbasierte Durchsetzung. Die Sicherheitsdiskussion ist über die Theorie hinaus. Eine Proxy-Schicht ist keine akademische Empfehlung mehr. Sie ist das, was Sie zwischen Ihren Agenten und alles setzen, worauf er zugreifen kann.
Dieser Artikel erklärt, was ein MCP-Proxy tatsächlich ist, wo direkte Verbindungen scheitern, wie Routing- und Delegierungsmechanismen funktionieren und wann ein Proxy nicht mehr optional ist.
Der Teil, den die meisten Teams erst nach dem ersten Vorfall lernen
- Ein MCP-Proxy delegiert an Backend-Server – er enthält keine Tool-Logik und ersetzt diese nicht.
- Transportkonflikte zwischen Clients und Backends bleiben bis zum Verbindungsaufbau unsichtbar; ein Proxy überbrückt sie.
- Ohne Proxy gibt es keinen zentralen Durchsetzungspunkt für Authentifizierung, Richtlinien oder Audits in Ihrem MCP-Server-Stack.
Was ein MCP-Proxy tatsächlich ist
Ein MCP-Proxy ist ein zwischengeschalteter MCP-Server. Er befindet sich zwischen einem Client und einem oder mehreren Backend-MCP-Servern, empfängt Anfragen nach Tools, Ressourcen und Prompts und leitet diese Anfragen an das Backend weiter, dem die jeweilige Funktion tatsächlich gehört. Anschließend gibt er das Ergebnis an den Client zurück. Der Proxy enthält keine eigene Tool-Logik.
Dieser letzte Satz ist entscheidend. Es geht um Delegierung, nicht um Hosting.
Diese Unterscheidung ist wichtig, weil MCP-Proxys häufig mit generischen HTTP-Proxys wie Nginx oder HAProxy verwechselt werden. Diese Tools leiten HTTP-Datenverkehr weiter, indem sie URLs und Header prüfen. Sie verstehen keine MCP-Protokollsemantik, kennen keine Tool-Namespaces, können keine Funktionen mehrerer Server zu einer einheitlichen Oberfläche zusammenführen und keine MCP-Transporte zwischen Client und Backend überbrücken. Sie gleichzusetzen, führt sofort zu falschen Architekturentscheidungen.
Ein MCP-Proxy spricht auf beiden Seiten nativ das Model Context Protocol. Für den Client sieht er wie ein einzelner MCP-Server aus, der einen vollständigen Funktionsumfang bereitstellt. Für die Backends verhält er sich wie ein Client, der Anfragen stellt. Der Client muss weder wissen, wie viele Server sich hinter dem Proxy befinden, noch welche Transporte sie verwenden. Genau diese Unsichtbarkeit ist der Zweck.
Warum direkte MCP-Server-Verbindungen unter realen Workloads scheitern
Direkte Verbindungen funktionieren gut, wenn Sie einen Client, einen Server, passende Transporte haben und niemand fragt, wer welche Anfrage gestellt hat. Das beschreibt den Laptop eines Entwicklers an einem Dienstagnachmittag. Es beschreibt keine produktive KI-Implementierung.
Wenn Sie skalieren – mehr Clients, mehr Backend-Server, heterogene Umgebungen –, vervielfachen sich die Probleme schnell. Jeder Client benötigt eine eigene Verbindungskonfiguration für jeden Server. Jeder Server stellt seinen Transport direkt bereit, wodurch ein Backend, das nur stdio spricht, plötzlich für einen webbasierten Client erreichbar sein muss, der nur HTTP unterstützt. Es gibt keinen zentralen Punkt, an dem Sie fragen können: „Wer darf was aufrufen?“ Jede Serverbereitstellung hat ihre eigene Authentifizierungsgeschichte oder, häufiger, überhaupt keine.
Der NSA-Bericht ist diesbezüglich konkret: Bei vielen MCP-Bereitstellungen fehlt die rollenbasierte Zugriffskontrolle vollständig, und das Protokoll verfügt derzeit über keinen nativen Mechanismus zum Austausch von RBAC-Berechtigungen bei der Instanziierung. Die Schwachstelle ist nicht spekulativ. Öffentliche Forschungslabore haben funktionierende Exploits veröffentlicht, die beliebige Codeausführung und Token-Replay gegen Server demonstrieren, die ohne vorgeschaltete Durchsetzungsschicht laufen.
Damit beginnt üblicherweise das Ticket.
Das Problem nicht kompatibler Transporte: stdio, SSE und Streamable HTTP
MCP unterstützt mehrere Transporte: stdio für die Kommunikation lokaler Prozesse, SSE für Server-Sent-Event-Streams und Streamable HTTP für zustandslose HTTP-Interaktionen. Das Problem besteht darin, dass Clients und Backend-Server oft unterschiedliche Varianten sprechen und dieser Konflikt vollständig unsichtbar bleibt, bis jemand tatsächlich versucht, sie zu verbinden.
Ein IDE-Plugin erwartet möglicherweise Kommunikation über stdio. Der benötigte Backend-MCP-Server läuft jedoch als Remote-Service über Streamable HTTP. Ohne eine Zwischeninstanz kommt diese Verbindung nicht zustande. Nicht langsam, nicht schlecht. Gar nicht.
Stellen Sie es sich wie ein Reiseadapterproblem vor. Der Stecker ist vorhanden. Die Steckdose ist vorhanden. Strom gibt es auf beiden Seiten. Doch ohne Adapter fließt nichts. Ein MCP-Proxy ist dieser Adapter für MCP-Transporte: Er akzeptiert eine eingehende Verbindung über den Transport, den der Client spricht, und leitet sie über den Transport weiter, den der jeweilige Server spricht. Die Übersetzung ist für beide Seiten unsichtbar.
Was passiert, wenn Sie Anfragen über mehrere Backend-Server weiterleiten
Stellen Sie sich vor, Ihr Agent benötigt Tools von vier unterschiedlichen Backend-MCP-Servern: einen für Kalenderzugriff, einen für CRM-Daten, einen für interne Dokumentation und einen für Codeausführung. Ohne Proxy benötigt der Client vier separate Verbindungskonfigurationen, vier separate Authentifizierungseinrichtungen und direkten Zugriff auf vier verschiedene Serveradressen und Transporte.
Sobald Sie in einer Produktivumgebung Anfragen über mehrere Server weiterleiten müssen, wird daraus Konfigurationsschuld, die sich jedes Mal verstärkt, wenn jemand ein neues Tool hinzufügt. Projekte wie der mcp-proxy von tbxark adressieren genau das: Sie bündeln mehrere Server hinter einem einzigen HTTP-Einstiegspunkt, sodass der Client einen Backend-Server statt vier sieht. Die Client-Konfiguration ändert sich nicht, wenn Sie ein fünftes Backend hinzufügen. Stattdessen absorbiert der Proxy diese Änderung.
Dadurch wird das Fan-out-Problem beherrschbar.
So funktioniert ein MCP-Proxy: Anfrage-Routing und Funktionsdelegierung
Die Mechanik sollte präzise verstanden werden, denn das Verhalten des Proxys wirkt unterschiedlich – abhängig davon, auf welcher Seite Sie stehen.
Aus Sicht des Clients sieht der MCP-Proxy-Server wie ein gewöhnlicher MCP-Server aus. Der Client verbindet sich, handelt Funktionen aus und sendet Anfragen wie üblich. Er hat keine Sicht darauf, was danach geschieht.
Danach passiert Folgendes: Der Proxy empfängt die Anfrage, ermittelt, welcher Backend-MCP-Server die angeforderte Funktion besitzt – anhand des Tool-Namens, der Ressourcen-URI oder der Prompt-Kennung –, und leitet die Anfrage über den passenden Transport an dieses Backend weiter. Wenn das Backend antwortet, gibt der Proxy das Ergebnis an den Client zurück. Der Proxy führt keine eigene Logik aus. Er schreibt die Tool-Ausgabe nicht um. Er delegiert transparent.
Der Schritt der Funktionsauflösung ist der Punkt, an dem der Proxy seine zusätzliche Komplexität rechtfertigt. Wenn ein Client ein Tool namens „search_docs“ aufrufen möchte, muss der Proxy wissen, welches Backend dieses Tool besitzt. Dafür muss der Proxy ein internes Register führen, welche Tools, Ressourcen und Prompts auf welchen Backends liegen. Er erstellt dieses Register, indem er jedes Backend während der Initialisierung abfragt und die Ergebnisse zwischenspeichert. Wenn eine neue Tool-Anfrage eingeht, löst der Proxy sie anhand des Registers auf und routet entsprechend.
Dieses Register macht den Proxy auch zu mehr als einem einfachen Relay. Er kann Richtlinien bereits zum Zeitpunkt der Auflösung durchsetzen: Anfragen nach Tools ablehnen, die nicht auf der Whitelist stehen, Funktionen von Backends entfernen, bevor sie bestimmten Clients bereitgestellt werden, oder vor der Weiterleitung Authentifizierungskontext ergänzen. Die Routing-Schicht ist zugleich die Durchsetzungsschicht.
Tools, Prompts und Ressourcen an einem einzigen Endpunkt bündeln
Aus Sicht des Clients stellt der Proxy eine einheitliche Funktionsoberfläche bereit. Wenn der Client abfragt, welche Tools verfügbar sind, antwortet der Proxy mit der kombinierten Menge aller Backends. Der Client sieht einen MCP-Client-Verbindungspunkt, einen Endpunkt und eine ausgehandelte Funktionsliste. Er weiß nicht – und muss nicht wissen –, dass „search_docs“ von einem Backend-Server und „create_ticket“ von einem anderen stammt.
Dieses Muster eines einzigen Proxy-Endpunkts macht IDEs und Agent-Frameworks in Multi-Backend-Umgebungen praktikabel. Claude Desktop, Cursor oder jeder MCP-fähige Agent benötigt nur eine konfigurierte Verbindung. Sie fügen einen Backend-Server hinzu, aktualisieren das Proxy-Register, und jeder verbundene Client erhält sofort Zugriff auf die neuen Tools. Keine Neukonfiguration von Clients. Keine neuen Verbindungszugangsdaten, die verteilt werden müssen.
Das Backend ist hier plural und unsichtbar. Die Oberfläche, mit der der Client interagiert, bleibt immer singular.
Transportüberbrückung und Sitzungsisolation zwischen Client und Backend
Der Proxy verwaltet für jede Seite einen separaten Verbindungsstatus. Ein Client verbindet sich über zustandsloses HTTP, und der Proxy hält diese Sitzung. Wenn der Proxy an ein Backend weiterleitet, das eine zustandsbehaftete persistente Verbindung erwartet, verwaltet er diese Verbindung unabhängig. Die Sitzung des Clients und die Sitzung des Backends sind voneinander isoliert.
Die Sitzungsisolation ist aus einem leicht zu übersehenden Grund wichtig: Ohne sie kann Status aus der Sitzung eines Clients in die eines anderen gelangen. Wenn zwei Agenten mit demselben Proxy verbunden sind und einer von ihnen einen teilweisen Ausführungsstatus in einem gemeinsamen Backend hat, muss dieser Status für den anderen unsichtbar sein. Das Sitzungsmanagement des Proxys setzt diese Grenze durch.
Ein konkretes Beispiel: Ein Client verbindet sich über SSE, der Proxy akzeptiert diesen zustandsbehafteten Stream und leitet einzelne Tool-Anfragen über zustandsloses HTTP an Remote-MCP-Server weiter. Das Backend sieht niemals die persistente SSE-Verbindung. Der Client sieht niemals die Zustandslosigkeit pro Anfrage. Der Proxy überbrückt beides und hält die Kontexte sauber.
Authentifizierung, Autorisierung und Governance: Hier verdient der Proxy seinen Platz
Hier wird das Architekturargument konkret.
In einem Modell direkter Verbindungen werden Authentifizierung und Autorisierung an jedem einzelnen Server behandelt – oder eben nicht behandelt. Wenn Sie sechs Backends haben, haben Sie sechs Authentifizierungskonfigurationen, sechs Probleme bei der Verwaltung von Zugangsdaten und sechs Stellen, an denen eine Fehlkonfiguration etwas offenlegen kann, das nicht offengelegt werden sollte. Es gibt keinen zentralen Ort für die Frage: „Darf dieser Aufrufer dieses Tool verwenden?“
Ein Proxy verändert das vollständig. Jeder Tool-Aufruf, jede Ressourcenanfrage und jede Prompt-Ausführung durchläuft den Proxy, bevor sie ein Backend erreicht. Das macht den Proxy zum natürlichen Durchsetzungspunkt für Ihren gesamten Stack aus Zugangsdaten und Richtlinien. Statt Authentifizierungslogik über Backends zu verteilen, zentralisieren Sie sie. Der Proxy validiert Identitäten, prüft Berechtigungen und leitet nur Anfragen weiter, die den Richtlinien entsprechen. Backends müssen nichts über die Identität des Aufrufers wissen. Der Proxy hat diese Entscheidung bereits getroffen.
Das RSAC-2026-Debriefing der Coalition for Secure AI fasst die Frage zusammen, die in der Community immer wieder aufkam: „Wer stellt diese Anfrage? Woher weiß ich das? Was geschieht, wenn ein Agent im Namen eines Nutzers über mehrere Hops hinweg handelt?“ Ein Proxy, der Sicherheitseinstellungen auf Enterprise-Niveau zentralisiert, ist die direkte Antwort auf alle drei Fragen. Er bietet die Transparenz und Kontrolle, die Authentifizierungsarrangements pro Server strukturell nicht bieten können.
Die Einschätzung der NSA zur MCP-Autorisierungsspezifikation ist ebenso direkt: Dem Protokoll fehlt ein nativer RBAC-Austausch bei der Instanziierung. Ein Proxy behebt diese Lücke im Protokoll nicht. Er fügt jedoch die Durchsetzungsschicht darüber hinzu – und genau das benötigen produktive Bereitstellungen jetzt.
💡 Wissenswert:
Teams gehen oft davon aus, dass das System sicher ist, weil jeder MCP-Server über eine eigene Authentifizierung verfügt. Doch ohne Proxy gibt es keinen Durchsetzungspunkt, der verhindern kann, dass ein Agent in derselben Schleife einen Server auf der Whitelist und einen Server außerhalb der Whitelist aufruft. Die Authentifizierung einzelner Server verhindert das nicht. Nur eine Schicht, die kontrolliert, welche Server im selben Agentenkontext koexistieren können, kann dies verhindern – und ein Proxy ist diese Schicht. Ein bösartiger MCP-Server, der zur Umgebung hinzugefügt wird, wird sofort aufrufbar, sobald keine Schicht das Register prüft.
Authentifizierung und Autorisierung auf Protokollebene
Ein Proxy fängt jeden Tool-Aufruf ab, bevor er ein Backend erreicht. Dieser Abfangpunkt ist der Ort, an dem die Authentifizierungs- und Autorisierungslogik in einer gut gesteuerten MCP-Bereitstellung angesiedelt ist. Token-Validierung, Identitätsnachweise, OAuth-Flows, Prüfung von Berechtigungsbereichen – all das läuft im Proxy, bevor auch nur eine einzige Anfrage weitergeleitet wird.
In der Praxis sieht das so aus: Ein Client sendet eine Tool-Anfrage mit einem Authentifizierungs-Token. Der Proxy validiert das Token, ordnet die Identität des Aufrufers einem Berechtigungssatz zu, prüft, ob diese Identität das angeforderte Tool aufrufen darf, und leitet die Anfrage dann entweder weiter oder lehnt sie ab. Wenn das Backend andere Zugangsdaten benötigt – etwa ein Service-Konto oder einen API-Schlüssel mit eingeschränktem Umfang –, tauscht der Proxy Token an dieser Grenze aus. Die Zugangsdaten des Clients erreichen das Backend niemals direkt.
Jede weitergeleitete Anfrage wird protokolliert: Identität des Aufrufers, Tool-Name, Zeitstempel und Ergebnisstatus. Dieser Audit-Trail ist genau das, wonach Sicherheitsteams fragen und was sie in Architekturen mit direkten Verbindungen selten erhalten, weil niemand daran gedacht hat, ihn vor dem Produktivbetrieb hinzuzufügen.
MCP-Server-Whitelisting und Richtliniendurchsetzung implementieren
Whitelisting ist das einfachste Governance-Muster und das, dessen frühe Implementierung sich am meisten lohnt. Der Proxy führt ein Register genehmigter Backend-MCP-Server. Anfragen, die für einen Server bestimmt sind, der nicht in diesem Register steht, werden vor der Weiterleitung abgelehnt. Ein Agent kann kein Backend aufrufen, das nicht in der genehmigten Liste erscheint – unabhängig davon, welche Tools dieses Backend anbietet.
MCP-Governance auf diese Weise zu implementieren bedeutet, dass die organisatorische Aufsicht in der Proxy-Konfiguration lebt und nicht über einzelne Agent-Konfigurationen verstreut ist. Wenn Sicherheitsteams fragen: „Auf welche MCP-Server können unsere Agenten zugreifen?“, lautet die Antwort: „Auf alles, was in der Proxy-Whitelist steht.“ Das ist auditierbar. Es lässt sich ändern, ohne jeden Agenten neu zu konfigurieren. Und es ist die grundlegende Kontrolle, um die Risikoklasse zu vermeiden, bei der ein neuer, nicht geprüfter Server ohne Prüfung in die Tool-Schleife gelangt.
Das Enterprise-MCP-Proxy-Muster geht noch weiter: Tool-Scoping pro Nutzer oder Rolle, Ratenlimits für bestimmte Tool-Kategorien und ausgehende Filterung von Antworten, bevor diese den Agenten erreichen. Die Sicherheitsrisiken bei MCP bestehen nicht nur zum Zeitpunkt der Authentifizierung. Sie liegen auch in der Ausgabekette, und der Proxy ist der Ort, an dem Sie auch diese abfangen. Die Authentifizierung kontrolliert, was aufgerufen wird. Die Ausgabefilter kontrollieren, was zurückkommt.
Vier Muster, bei denen ein MCP-Proxy ein echtes Architekturproblem löst
Das sind keine Nutzenversprechen. Jedes dieser Muster ist ein Fehlermodus, den der Proxy verhindert.
Sicherheits- und Governance-Schicht für Unternehmen
Ein Security-Engineering-Team betreibt Agent-Workflows über CRM-, interne Dokumentations- und Codeausführungs-Backends hinweg und hat keinen zentralen Punkt, um zu prüfen, welcher Agent welches Tool mit welcher Identität und zu welchem Zeitpunkt aufgerufen hat. Jedes Backend betreibt seine eigene Authentifizierung – oder gar keine. Der Proxy wird zum einzigen Durchsetzungspunkt: Jede Anfrage läuft durch ihn, die Identität wird validiert, der Umfang wird geprüft und das vollständige Aufrufprotokoll erfasst. Ohne ihn bedeutet Incident Response nach einem Tool-Poisoning-Ereignis, den Ausführungsverlauf aus sechs verschiedenen Serverprotokollen zu rekonstruieren, sofern diese überhaupt existieren. Die Bereitstellung einer Governance-Schicht entscheidet hier zwischen „Wir können untersuchen, was passiert ist“ und „Wir können es nicht“.
Aggregations-Hub für heterogene MCP-Server
Ein RevOps-Team, das Cursor nutzt, benötigt Zugriff auf Tools eines Kalenderservers, eines CRM-Servers und einer internen Wissensdatenbank. Ohne Proxy benötigt Cursor drei separate Serverkonfigurationen, drei Sätze an Zugangsdaten, und das Team muss jeden Agent-Client aktualisieren, sobald sich ein Backend ändert. Mit einem Proxy, der alle drei hinter einem einzigen HTTP-Einstiegspunkt bündelt, bleibt die Client-Konfiguration stabil. Fügen Sie dem Proxy-Register ein viertes Backend hinzu, und jeder verbundene Agent verfügt sofort darüber. In Latenode entspricht dies der Nutzung des integrierten MCP Server Builder, um kontrollierte Funktionen als einheitliche lokale MCP-Server-Oberfläche für Clients wie Claude Desktop bereitzustellen, während Latenodes automatische OAuth-Verwaltung die Zugangsdaten für die zugrunde liegenden Ressourcenserver-Verbindungen handhabt. Eine saubere Client-Konfiguration, gesteuerter Zugriff und das Preismodell pro Ausführung halten die Abrechnung einfach, während die Anzahl der Backends wächst.
Transportüberbrückung zwischen nicht kompatiblen Clients und Backends
Ein Backend-MCP-Server, der lokal als stdio-Prozess ausgeführt werden soll, muss einen webbasierten Agent-Client bedienen, der Streamable HTTP spricht. Diese beiden Komponenten sind nicht direkt verbindbar. Ein Proxy akzeptiert die HTTP-Verbindung des Clients und leitet sie an den stdio-Prozess des Backends weiter. Das Backend wird nicht verschoben. Der Client ändert sich nicht. Der Proxy absorbiert die Inkompatibilität. Teams, die MCP-Server schrittweise bereitstellen, stoßen ständig darauf: Ein für die lokale Entwicklung gebauter Server muss plötzlich Remote-Agenten bedienen. Der Proxy löst dies, ohne dass der Server neu geschrieben werden muss.
Funktionen mit benutzerdefinierter Authentifizierung, Ratenlimits und Analysen neu bereitstellen
Ein KI-Plattformteam möchte externen Entwicklern eine Teilmenge interner MCP-Tools bereitstellen, ohne die Backend-Server direkt offenzulegen. Eine produktive MCP-Proxy-Schicht sitzt davor, erzwingt API-Key-Authentifizierung, wendet Ratenlimits je Aufrufer an, entfernt interne Metadaten aus Antworten und protokolliert jeden Aufruf für Analysen und Abrechnung. Ohne diese Schicht bedeutet die externe Bereitstellung von MCP-Funktionen, die Backend-Infrastruktur direkt offenzulegen. Der Proxy ist der Ort, an dem Sie die öffentliche Schnittstelle von der internen Implementierung trennen. Teams, die diesen Schritt überspringen und MCP-Server direkt bereitstellen, bereuen es beim ersten Mal, wenn ein Aufrufer die Backend-Kapazität ausschöpft oder mehr Daten extrahiert als vorgesehen. Die Fähigkeit des Proxys, die Backend-Last durch Ratenkontrolle und Caching zu reduzieren, ist ein echter operativer Vorteil, kein theoretischer.
MCP-Proxy vs. API Gateway: Warum die Unterscheidung für Architekten wichtig ist
Architekten, die zu einem API Gateway greifen, um MCP-Governance-Probleme zu lösen, werden feststellen, dass es etwa 60 % ihres Bedarfs abdeckt und die 40 % verfehlt, die MCP-spezifisch sind. Es lohnt sich, diese Unterscheidung präzise zu treffen.
| Funktion | API Gateway | MCP-Proxy |
|---|---|---|
| Protokollverständnis | HTTP/REST; Routing nach URLs und Headern | MCP-Protokoll; Routing nach Tool-Name, Ressource, Prompt |
| Funktionsaggregation | Nein; leitet pro Endpunkt an ein Upstream-System weiter | Ja; bündelt Tools mehrerer Backends zu einer Oberfläche |
| MCP-spezifische Funktionen | Keine; keine Tool-Weiterleitung, kein Prompt-/Ressourcen-Routing | Nativ; delegiert Tool-Aufrufe, Ressourcen und Prompts über Backends hinweg |
| Transportüberbrückung | Nein; setzt HTTP auf beiden Seiten voraus | Ja; überbrückt stdio, SSE und Streamable HTTP |
| Optimaler Anwendungsfall | REST-APIs, Ratenlimits, Authentifizierung für HTTP-Datenverkehr | MCP-Bereitstellungen mit mehreren Servern, gemischten Transporten oder Governance-Anforderungen |
Ein API Gateway kann Authentifizierung und Ratenlimits für HTTP-Datenverkehr handhaben, was tatsächlich nützlich ist und sich für die HTTP-Schicht Ihres Stacks lohnt. Die Lücke liegt bei der Delegierung: Ein Gateway leitet weiter, indem es URLs abgleicht und ein Upstream-System aufruft. Es verfügt über keinen Mechanismus, um zu erkennen, dass ein Tool namens „search_docs“ auf Backend A und „create_ticket“ auf Backend B liegt, diese zu einer einzigen Funktionsliste zusammenzuführen und sie einem Client nativ bereitzustellen. Das ist kein Konfigurationsproblem des Gateways. Es ist ein Architekturkonflikt zwischen dem, was ein Gateway tut, und dem, was MCP erfordert.
📊 In der Praxis:
Ein API Gateway, das für das Routing von MCP-Datenverkehr konfiguriert ist, kann eine HTTP-Anfrage an eine Proxy-Serveradresse weiterleiten – das ist eine gültige Transportschicht. Was es nicht kann: einem Client eine einheitliche MCP-Tool-Oberfläche bereitzustellen, wenn diese Tools über mehrere Backends verteilt sind. Das Gateway sieht URLs. Es sieht keine Tool-Namespaces. Ein Client, der über MCP mit einem API Gateway kommuniziert, erhält Routing. Er erhält keine Aggregation und keine Transportüberbrückung. Die beiden Schichten ergänzen sich, sie sind nicht austauschbar.
