KI-Modell- & Plattform-UpdatesAgenteninfrastrukturEmpfehlung der Redaktion

Ubers MCP Gateway: Agenten skalierbar mit Tausenden internen APIs verbinden

Uber hat ein MCP Gateway entwickelt, über das KI-Agenten auf Tausende interne APIs zugreifen können – ohne dass jedes Team eigene MCP-Server schreiben muss. Dieser Beitrag erläutert AutoCrawler, die zentrale Erkennung, die Protokollübersetzung, die Durchsetzung von Richtlinien und bewährte Betriebsansätze. Außerdem zeigt er, warum Gateway-Schichten für Unternehmensagenten immer wichtiger werden.

NexusAI Editorial Desk6. Okt. 20261.7K Aufrufe8 Min. Lesedauer

Ubers MCP Gateway: Agenten skalierbar mit Tausenden internen APIs verbinden

AI-Briefing

Ubers MCP Gateway löst ein Skalierungsproblem, mit dem jedes größere Unternehmen beim Einsatz von Agenten konfrontiert ist: Wie lassen sich Tausende bestehende APIs autonomen Systemen zugänglich machen, ohne dass Entwicklungsteams Services umschreiben oder maßgeschneiderte MCP-Server bauen müssen? Dieser Beitrag beleuchtet den Aufbau des Gateways mit zwei Ebenen, den Erkennungsworkflow von AutoCrawler, die Protokollübersetzung zur Laufzeit sowie Richtlinien- und Schwärzungskontrollen. Er stellt Betriebsansätze wie Omni MCP, Response Projection und Code Mode vor, die Tokenverbrauch und Kosten senken, und erläutert Risiken, Zuständigkeiten sowie konkrete Schritte für Unternehmen, die einen Gateway-zentrierten Ansatz für ihre Agenteninfrastruktur prüfen.

KI-Agenten in Unternehmen sind erst dann wirklich nützlich, wenn sie auf verlässlichen, aktuellen Geschäftskontext zugreifen und damit arbeiten können. Ubers MCP Gateway beantwortet eine konkrete, aber unausweichliche Frage: Wie erhalten Agenten einen kontrollierten, auffindbaren Zugriff auf Tausende bestehende APIs, ohne dass jedes Serviceteam einen MCP-Server implementieren muss? Das Gateway bündelt Erkennung, Übersetzung und Richtliniendurchsetzung. So bleiben Serviceteams aus dem kritischen Pfad heraus: Sie müssen ihre Endpunkte nicht umschreiben, und die Verantwortlichen behalten die Kontrolle über Prüfung und Freigabe. Dieser Kompromiss verringert doppelte Infrastruktur und vereinheitlicht die Governance, ohne die operative Unabhängigkeit der Teams einzuschränken.

Architektonisch ist das Gateway in eine Steuerungsebene (MCP Registry und AutoCrawler) und eine Datenebene (Proxy Gateway) aufgeteilt. Die Registry ist die maßgebliche Quelle für virtuelle Server und Tools. AutoCrawler leitet kontinuierlich Tool-Definitionen aus IDLs und nativen MCP-Servern ab, sodass der Katalog automatisch mitwächst. Das Proxy Gateway stellt virtuelle MCP-Server zur Laufzeit bereit, übersetzt MCP-Aufrufe in HTTP/gRPC/TChannel, übergibt die Ausführung an den Sidecar des Service Mesh (Muttley) und liefert MCP-kompatible Ergebnisse zurück. Diese Trennung ermöglicht schnelle Iterationen, Konfigurationsaktualisierungen in Echtzeit und ein einheitliches Ausführungsmodell für unterschiedliche Agenten-Clients.

AutoCrawler ist der entscheidende operative Hebel, der das gesamte System praktikabel macht. Statt auf manuell erstellte Definitionen zu setzen, nutzt Uber einen von Cadence gesteuerten Workflow, der die IDL-Registry durchsucht, Heartbeats nativer MCP-Server überwacht, Protobuf-/Thrift-Definitionen analysiert und erste Tool-Manifeste generiert. Diese generierten Tools bleiben standardmäßig deaktiviert; die Verantwortung für Prüfung und Freigabe liegt bei den Serviceteams. AutoCrawler ergänzt außerdem mithilfe von LLMs Schemas und Beschreibungen um agentenfreundliche Dokumentation – ein pragmatischer Kompromiss, der maschinelle Skalierung mit menschlicher Prüfung und Sicherheitskontrollen verbindet.

Sicherheit, Richtlinien und Betriebssicherheit sind in der Gateway-Schicht verankert, statt über einzelne Teams verstreut zu sein. Die Plattform setzt Richtlinien auf Tool- und Serverebene über Ubers internes Zugriffskontrollsystem durch, schwärzt personenbezogene Daten (PII) in Antworten und wendet einheitlich Ratenbegrenzungen und Audits an. Auch Integrationen mit MCP-Diensten von Drittanbietern sind möglich, ohne die Richtlinien aufzuweichen: Das Gateway leitet interne Tokens weiter, die Drittanbieterdienste gegen externe Zugangsdaten austauschen. So bleiben zentrale Kontrollen erhalten. Dieses Modell bietet einen praktikablen Mittelweg zwischen Flexibilität und Governance auf Unternehmensebene.

Bei Kosten und Leistung setzt das Gateway an zwei Skalierungshemmnissen agentischer Workflows an: überladenem Kontext und Tokenkosten. Omni MCP ermöglicht eine schrittweise Erkundung – mit Tools zum Auffinden von Servern, Auflisten von Tools, Abrufen von Schemas und Aufrufen von Tools. Agenten müssen dadurch nicht Hunderte Tool-Definitionen vorab laden. Response Projection beschränkt Antworten zur Laufzeit auf die angeforderten Felder. Code Mode (über aifx) sorgt dafür, dass CLI-basierte Coding-Agenten Ausgaben auf die Festplatte schreiben, statt alles in den Modellkontext zu laden. Zusammen reduzieren diese Ansätze unnötigen Modellkontext, Latenz und API-Kosten – auch im Unternehmensmaßstab.

Wichtigste Erkenntnisse

Erkennung zentralisieren, Zuständigkeit bewahren

Erstellen Sie mithilfe automatisierter Erfassung einen durchsuchbaren Tool-Katalog, verlangen Sie vor der Freigabe jedoch eine Prüfung und Aktivierung durch die Serviceverantwortlichen. So sinkt der Aufwand, während Verantwortlichkeit und Sicherheit gewahrt bleiben.

Kontext und Kosten direkt am Gateway optimieren

Setzen Sie auf schrittweise Erkennung (Omni MCP), feldbasierte Response Projection und CLI-basierten Code Mode, um Modellkontext, Latenz und API-Kosten in Agenten-Workflows zu reduzieren.

Das Gateway als kritische Infrastruktur mit Sicherheitskontrollen behandeln

Setzen Sie Zugriffskontrollen, PII-Schwärzung, Ratenbegrenzungen und Beobachtbarkeit einheitlich am Gateway durch. Ergänzen Sie dies um gestaffelte Rollouts und Canaries, um die Auswirkungen von Fehlkonfigurationen zu begrenzen.

Design und Architektur: zwei Ebenen, ein Katalog

Der zweistufige Aufbau des MCP Gateways prägt sowohl seine Skalierbarkeit als auch die Zusammenarbeit mit den Teams. Die Steuerungsebene (MCP Registry) verwaltet einen maßgeblichen Katalog virtueller MCP-Server und Tool-Manifeste. Die Datenebene (Proxy Gateway) führt Anfragen aus und hält eine In-Memory-Bereitstellung der aktivierten Server vor. Durch diese Aufteilung lassen sich Konfigurationen sofort und ohne erneute Bereitstellung ausrollen. Gleichzeitig kann die Erkennung automatisiert werden, während Durchsetzung und Zuständigkeit in menschlicher Hand bleiben. Für den Betrieb sinkt der Wartungsaufwand, weil wiederkehrende MCP-Infrastruktur in einem verwalteten Dienst gebündelt wird, der mit dem bestehenden Service Mesh kommuniziert.

AutoCrawler: Erkennung im großen Maßstab ohne Mehraufwand für Teams

AutoCrawler ist die Erkennungs-Engine, die verhindert, dass die Erstellung von Tools zu einem kombinatorischen Problem wird. Sie durchsucht fortlaufend IDL-Registries und Heartbeats nativer MCP-Server, analysiert Protobuf-/Thrift-Dateien, generiert JSON-RPC-kompatible Schemas und legt virtuelle MCP-Server an, die standardmäßig deaktiviert sind. Außerdem ergänzt AutoCrawler Tool-Beschreibungen um von LLMs erstellte Zusammenfassungen und hält die Teams aus dem kritischen Pfad heraus: Die Serviceverantwortlichen prüfen und aktivieren die Artefakte, sobald sie bereit sind. So können Unternehmen Tool-Kataloge für Agenten schnell aufbauen und zugleich Prüfschranken und Zuständigkeiten beibehalten.

Sicherheit, Richtlinien und Schwärzung: einmal durchsetzen, überall anwenden

Wer Autorisierung und Schwärzung zentral im Gateway bündelt, vereinfacht das Risikomanagement. Uber setzt Richtlinien auf Serverebene mit optionalen Ausnahmen für einzelne Tools durch, prüft über das interne Zugriffskontrollsystem die aufrufenden Akteure (Menschen, Services und Agenten) und schwärzt personenbezogene Daten (PII) in zurückgegebenen Daten. Bei Integrationen mit Drittanbietern leitet das Gateway Benutzertokens weiter; der externe Dienst tauscht sie gegen andere Tokens aus, sodass die Nachvollziehbarkeit erhalten bleibt. Dieser Ansatz verringert Unterschiede beim Sicherheitsniveau zwischen Teams und sorgt für einheitliche Audit-Protokolle, während die Durchsetzung nahe an der Ausführung zur Laufzeit bleibt.

Betriebsansätze: Omni MCP, Response Projection und Code Mode

Ubers Ergänzungen für den Betrieb erleichtern die Tool-Erkennung und entlasten den Modellkontext. Omni MCP stellt grundlegende Funktionen bereit (discover_server, discover_tools, get_tool_schema, invoke_tool), mit denen Agenten Tools schrittweise finden und aufrufen können. Mit Response Projection können LLM-Prompts nur die benötigten Felder anfordern, sodass das Gateway Antworten kürzt und den Tokenverbrauch senkt. Code Mode, verfügbar über die aifx-CLI, ermöglicht Coding-Agenten, list-, search- und call-Befehle der Reihe nach auszuführen und Ergebnisse auf der Festplatte abzulegen. Nachgelagerte dateisystembasierte Agenten laden dann nur die benötigten Daten. Diese Ansätze sind praktische Hebel, um Kosten zu kontrollieren und die Zuverlässigkeit produktiver Agentenketten zu erhöhen.

Risiken, Grenzen und Zuständigkeiten

Ein Gateway-zentrierter Ansatz verringert Doppelarbeit, bringt aber ein erhöhtes Konzentrationsrisiko mit sich: Eine Fehlkonfiguration oder ein Fehler im Gateway kann viele Tools betreffen. Deshalb sind klare Zuständigkeiten entscheidend – die Erkennung sollte automatisiert werden, die Freigabe muss jedoch bei den Serviceteams bleiben. Weitere Grenzen sind Schemaabweichungen bei IDL-basierten Services, Sonderfälle bei der Protokollübersetzung und verbleibende Kosten durch nicht passende Projektionen. Unternehmen sollten das Gateway mit robusten CI-Prozessen, Freigabeworkflows, schrittweisen Canary-Rollouts und umfassender Beobachtbarkeit absichern, um systemische Ausfälle abzufedern.

Häufig gestellte Fragen

Warum sollte nicht jedes Team einen nativen MCP-Server bauen?

Im Unternehmensmaßstab führt die Verpflichtung, MCP-Server selbst zu erstellen und zu betreiben, zu doppelter Infrastruktur, uneinheitlicher Sicherheit und einer verzögerten Einführung. Ein zentrales Gateway beseitigt diese Hürden, indem es bestehende APIs in MCP-kompatible Tools übersetzt. Teams können weiterhin native Server einsetzen, wenn sie eine feinere Kontrolle benötigen.

Wie verhindert AutoCrawler, dass unsichere Endpunkte freigegeben werden?

AutoCrawler registriert erkannte Services ausschließlich als standardmäßig deaktivierte virtuelle Server. Die Serviceverantwortlichen müssen die generierten Schemas und Beschreibungen prüfen und Tools ausdrücklich aktivieren. Zusätzlich setzt das Gateway Richtlinienkontrollen und automatische Schwärzung ein – Erkennung bedeutet also nicht automatisch Freigabe.

Welche betrieblichen Kontrollen begrenzen die Auswirkungen eines Gateway-Ausfalls?

Zu den bewährten Maßnahmen zählen Ratenbegrenzungen pro Tool, Richtlinien auf Serverebene, Circuit Breaker, Canary-Rollouts für Konfigurationsänderungen, regelmäßige Aktualisierungen der Live-Konfiguration und umfassende Beobachtbarkeit. Zuständigkeiten und Freigabeworkflows stellen sicher, dass nur geprüfte Tools aktiviert werden. Eine schnelle Rollback-Möglichkeit verkürzt zudem die Wiederherstellungszeit.