Designing MCP Gateway: Uber's MCP Management Platform

Einleitung

Die rasante Einführung von AI Agents bei Uber hat grundlegend verändert, wie Teams mit Code, Daten und operativen Systemen arbeiten. Erste Ad-hoc-Integrationen mit dem MCP (Model Context Protocol) zeigten schnell einen klaren Mehrwert: Agents wurden deutlich leistungsfähiger, sobald sie auf Live-Geschäftskontexte zugreifen, interne Services abfragen und sinnvolle Aktionen im Namen der Nutzer ausführen konnten. Diese frühen Erfolge bestätigten MCP als leistungsstarke Abstraktion für den Aufbau agentenbasierter Systeme innerhalb von Uber.

Mit der zunehmenden Verbreitung traten jedoch erhebliche Herausforderungen zutage. Einzelne Teams bauten ihre Integrationen unabhängig voneinander, was zu einer Fragmentierung der Tools und zu doppelter Infrastruktur führte. MCP-Tools waren schwer auffindbar, ließen sich nur mühsam zuverlässig betreiben und waren eng an bestimmte Services oder Agent-Implementierungen gekoppelt. Im kleinen Maßstab funktionierten diese Ansätze zwar, doch als Hunderte von Teams begannen, agentenbasierte Workflows zu erproben, reichten sie für Ubers Anforderungen nicht mehr aus. Ohne eine einheitliche Architektur hätte die Skalierung von MCP die operative Komplexität, die Sicherheitsrisiken und den Aufwand für Entwickler erhöht – und damit letztlich dessen Wirkung begrenzt.

Um das volle Potenzial von MCP in Ubers Größenordnung auszuschöpfen, brauchten wir eine zentrale, skalierbare Lösung. Sie sollte standardisieren, wie AI Agents mit bestehenden Backend-Systemen interagieren, und den Teams gleichzeitig Flexibilität bewahren. Diese Lösung musste Protokollunterschiede (HTTP, gRPC™, TChannel) abstrahieren, konsistente Sicherheits- und Observability-Garantien durchsetzen und es unternehmensweit vereinfachen, MCP-Tools zu erstellen, zu finden und wiederzuverwenden.

Genau dafür haben wir das MCP Gateway entwickelt. Es ist ein grundlegender Microservice, der sämtliche MCP-Interaktionen bei Uber antreibt und als Orchestrierungs- und Routing-Schicht zwischen AI Agents, bestehenden Backend-Services und nativen MCP-Servern fungiert. Indem wir die MCP-Logik in einem einzigen Gateway bündeln, bieten wir ein konsistentes Ausführungsmodell für Interaktionen zwischen Agents und Services – ohne dass Teams die Kerninfrastruktur immer wieder neu erfinden müssen. Bestehende APIs lassen sich nahtlos als MCP-Tools bereitstellen, zentral steuern und betreiben sowie von mehreren Agents einheitlich nutzen. Das MCP Gateway hat einen skalierbaren, schnellen und konsistenten Weg zur Entwicklung von AI Agents bei Uber geebnet und hostet derzeit über 800 MCP-Server und mehr als 5000 Tools.

Abbildung 1: MCP Gateway (APIs als Tools).

In diesem Blogbeitrag beleuchten wir das Design des MCP Gateways – von der Proxy-Schicht (Übersetzung von MCP in bestehende Protokolle und zurück) über die Discovery-Schicht (MCP Registry und API-Crawling) bis hin zur Control Plane (Authoring).

Das Gateway

Das MCP Gateway folgt einer microservicebasierten Architektur, wobei das Gateway als zentraler Integrationspunkt zwischen KI-gestützten Systemen und den Backend-Services von Uber dient. Die Plattform besteht aus zwei Hauptkomponenten: der MCP Registry als Control Plane und dem Proxy Gateway als Data Plane.

Die MCP Registry verwaltet einen Katalog mit Hunderten von MCP-Servern, die von internen Services betrieben werden, sowie Tausenden von MCP-Tools. Diese reichen von No-Code-Definitionen, die bestehende APIs als MCP-Tools verfügbar machen, bis hin zu vollständig nativen Implementierungen, die explizit nach der MCP-Spezifikation entwickelt wurden. Die Registry bildet die Single Source of Truth für Discovery, Ownership und Enablement im gesamten Ökosystem.

Das Proxy Gateway ist für die Ausführung von MCP-Anfragen zur Laufzeit zuständig. Es übersetzt MCP-Protokollaufrufe in HTTP-, gRPC- oder TChannel-Anfragen, leitet sie an den entsprechenden Backend-Service weiter und wandelt die Antworten zurück in MCP-kompatible Ergebnisse um. Dank dieser Übersetzungsschicht können AI Agents über eine einheitliche MCP-Schnittstelle mit bestehenden Systemen interagieren, ohne dass Änderungen an den zugrunde liegenden Services nötig sind.

Control Plane

Uber nutzt eine Microservice-Architektur und betreibt Tausende interne Services, die APIs über HTTP, gRPC und TChannel bereitstellen. Diese APIs liefern wertvollen Kontext für ein KI-System – doch jedes Team manuell einen MCP-Server entwickeln zu lassen, wäre langsam und mühsam. Um dieses Problem zu lösen, haben wir AutoCrawler gebaut. Er scannt kontinuierlich Ubers IDL-Registry nach APIs, übersetzt sie und aktualisiert sie in der Registry. Außerdem fragt er native MCP-Server ab und nimmt sie in die Registry auf.

AutoCrawler: Die Discovery Engine

AutoCrawler ist ein verteiltes Workflow-System auf Basis von Cadence, das an Ubers IDL-Registry und interne Service-Signale angebunden ist. Nach einem festen Zeitplan löst ein Cron-Job einen Cadence-Workflow aus, der nach neu hinzugefügten Services, APIs und Schemaänderungen sucht.

Für jede entdeckte Entität übernimmt AutoCrawler folgende Aufgaben:

• Erstellen oder Aktualisieren von MCP-Server-Repräsentationen
• Generieren oder Abrufen von Tool-Definitionen und Schemas
• Registrieren der Tools in der MCP Registry im standardmäßig deaktivierten Zustand

Diese gemeinsame Grundlage ermöglicht es, die MCP-Discovery über Tausende von Services hinweg zu skalieren, ohne die Service-Teams zum Flaschenhals zu machen.

Abbildung 2: AutoCrawler.

Discovery für IDL-basierte Services

Bei klassischen Backend-Services, die über Protobuf- oder Thrift-IDLs definiert sind, leitet AutoCrawler MCP-Server und -Tools direkt aus der IDL-Registry ab. Für jede Service-API-Gruppe führt AutoCrawler folgende Schritte aus:

• MCP-Server upserten: Erstellt oder aktualisiert einen virtuellen MCP-Server, der dem gefundenen Service entspricht.
• IDL-Definitionen parsen: Analysiert die zugehörigen Protobuf- oder Thrift-Dateien, um Methodennamen, Request- und Response-Schemas sowie Dokumentationskommentare zu extrahieren.
• Tool-Beschreibungen generieren: Nutzt ein LLM, um anhand der extrahierten Schemas und Kommentare angereicherte, agentenfreundliche MCP-Tool-Beschreibungen zu erzeugen.
• Schema-Übersetzung: Überführt Protobuf- oder Thrift-Schemas in MCP-kompatible JSON-RPC 2.0-Schemas.
• MCP-Tools upserten: Registriert oder aktualisiert die generierten MCP-Tools in der MCP Registry im standardmäßig deaktivierten Zustand.

Discovery für native Server

Neben IDL-basierten Services unterstützt das MCP Gateway auch native MCP-Server – also Services, die das MCP-Protokoll direkt implementieren und für Agents optimierte Tools bereitstellen.

MCPFx ist das Framework, mit dem Uber native MCP-Server entwickelt. Jeder native MCP-Server sendet eine Heartbeat-Metrik, die seine Verfügbarkeit und Betriebsbereitschaft signalisiert. AutoCrawler überwacht diese Heartbeat-Signale kontinuierlich, um neue native MCP-Server automatisch zu erkennen. Wird ein nativer MCP-Server entdeckt, folgt AutoCrawler einem anderen Discovery-Pfad:

1. Er ruft per listTools den nativen MCP-Server auf, um die explizit bereitgestellten Tools samt ihrer Schemas abzurufen.
2. Er erstellt in der MCP Registry einen virtuellen Proxy-MCP-Server, der alle gefundenen Tools und deren Schemas enthält – standardmäßig im deaktivierten Zustand.

MCP-Server von Drittanbietern

Das MCP Gateway dient als zentrale Orchestrierungsschicht für alle MCP-Interaktionen bei Uber und unterstützt auch Drittanbieter-Integrationen wie Jira und Google nahtlos.

Die Bereitstellung von MCP-Servern Dritter erfordert das Zusammenspiel zweier Schlüsselkomponenten:

1. MCP Gateway: Leitet das User-Token des Aufrufers an den Downstream weiter und setzt dabei essenzielle Gateway-Funktionen wie Autorisierung, Rate Limiting und die Schwärzung sensibler Daten durch.
2. MCP-Service des Drittanbieters: Tauscht das interne User-Token gegen ein entsprechendes Authentifizierungs-Token des Drittanbieters aus, bevor die Anfrage an den externen MCP-Server gesendet wird.

Authoring und Enablement

Auch wenn wir MCP-Server ohne Beteiligung des jeweiligen Service-Teams erstellen können, müssen Ownership und Kontrolle beim Service-Team verbleiben. Ein zentrales Designprinzip des MCP Gateways lautet: Discovery bedeutet nicht automatisch Freigabe. Jeder MCP-Server und jedes Tool startet im deaktivierten Zustand und muss vom verantwortlichen Team explizit geprüft und aktiviert werden. Service-Owner können die generierten Tool-Definitionen überprüfen und anpassen, bevor sie sie freigeben.

Jede Änderung an der Tool-Beschreibung erzeugt einen Config-Change-Diff, der von den Server-Ownern freigegeben werden muss. Diese können die Konfigurationsänderung genehmigen und deployen – und bei Bedarf auf eine frühere, bekannte Version zurückrollen.

Abbildung 3: UI der MCP Registry.

Abbildung 4: UI des MCP-Tools.

Data Plane

Die Data Plane des MCP Gateways ist der zentrale Runtime-Service für die Ausführung von MCP-Anfragen. Sie bezieht kontinuierlich Server- und Tool-Konfigurationen aus der Control Plane und aktualisiert ihren In-Memory-Zustand in festen Intervallen. So wirken sich Konfigurationsänderungen – etwa Tool-Updates oder Freigaben – in Echtzeit aus, ohne dass Services neu gestartet oder redeployed werden müssen.

Auf Basis dieser Konfiguration materialisiert die Data Plane dynamisch virtuelle MCP-Server. Für jeden virtuellen Server stellt das Gateway einen einzelnen /<service-name>/mcp-Endpunkt bereit, der als Einstiegspunkt für die Ausführung durch AI Agents dient. Eingehende Anfragen werden über einen integrierten Proxy-Server den entsprechenden Server-Handlern zugeordnet.

Abbildung 5: Data Plane des MCP Gateways.

Protokollübersetzung und Ausführung

Die Protokollübersetzung im MCP Gateway übernehmen Server-Handler innerhalb des Proxy Gateways. Jeder Server-Handler kennt sowohl die Tools als auch die Downstream-Ziele und kann MCP-Anfragen zur Laufzeit korrekt routen und ausführen.

Sicherheit

Das MCP Gateway bietet für alle Server eine integrierte Autorisierung und Datenschwärzung mit Granularität auf Toolebene. Es nutzt Ubers internes Access Control System, um verschiedene Charter-Policies auf die erkannten aufrufenden Akteure (Menschen, Services und Agents) anzuwenden. Charter-Policies werden auf Serverebene definiert, bei Bedarf mit optionalen Overrides auf Toolebene.

Darüber hinaus schwärzt das MCP Gateway out-of-the-box alle PII oder sensiblen Daten in den Tool-Antworten.

IDL-basierte Downstream-Services

Bei Tools, die auf bestehenden Backend-Services aufsetzen, pflegt der Server-Handler ein In-Memory-Mapping, das das Downstream-Ziel beschreibt – etwa die HTTP-Endpunkt-Konfiguration oder gRPC-/TChannel-Prozeduren.

Wenn eine MCP-Anfrage eingeht, führt der Handler folgende Schritte aus:

1. Er übersetzt das eingehende JSON-Payload in das passende Wire-Format.
2. Er serialisiert die Anfrage in Protobuf- oder Thrift-Bytes.
3. Er leitet die Anfrage an den Downstream-Service weiter.
4. Er übersetzt die Protobuf- oder Thrift-Byte-Antworten zurück in MCP-kompatibles JSON und gibt sie an den aufrufenden Agent zurück.

Die eigentliche Downstream-Anfrage wird über Muttley ausgeführt – Ubers Service-Mesh-Sidecar, der neben allen Backend-Services läuft. Durch die Delegation an Muttley profitiert das MCP Gateway automatisch von den bestehenden Routing-Funktionen für die Service-zu-Service-Kommunikation.

Native MCP-Server

Native MCP-Server werden ebenfalls als virtuelle Server in der MCP Registry registriert, die als Proxy zum Originalserver fungiert. Zur Laufzeit werden native MCP-Anfragen transparent an den Downstream-Server weitergeleitet und die Antworten zurück an den Aufrufer proxied.

Vorteile des Gateways

Mit dem MCP-Gateway hat Uber einen skalierbaren und einheitlichen Ansatz für den Aufbau agentenbasierter Systeme geschaffen. Die größten Vorteile liegen in folgenden Bereichen:

• Einfache Discovery und Installation
• No-Code-Ansatz für bestehende APIs
• Integrierte Observability und Sicherheit
• Zentrale Ownership und Governance

Erweiterung des Gateways

Die Skalierung des MCP Gateways auf Hunderte Server und Tausende Tools brachte Probleme ans Licht, die im kleinen Maßstab gar nicht existieren – etwa Context Bloat und übermäßige Kosten.

Runtime Discovery

MCP kennt kein natives Konzept für serverübergreifende Suchen. Ein Agent muss bereits wissen, welchen Server er ansprechen soll, bevor er nach verfügbaren Tools fragen kann. Um einen Agent für einen MCP-Server zu konfigurieren, müssen Server-URL, Credentials und Tool-Liste explizit verdrahtet werden. Bei Hunderten von Servern skaliert das nicht, da all dieser Kontext das Context-Limit des Modells sprengen würde. Wir haben dieses Problem wie folgt gelöst:

• Omni MCP – Ein einzelner Proxy-Server, der es MCP-Clients ermöglicht, schrittweise auf jeden Server des MCP Gateways zuzugreifen. Dieses Muster erlaubt zudem eine Kontext- und Token-Optimierung durch inkrementelle Discovery. Omni MCP stellt folgende Tools bereit:
• discover_server – findet MCP-Server basierend auf der Query-Intention
• discover_tools – sucht Tools für einen bestimmten Server
• get_tool_schema – ruft das JSON-Schema eines Tools ab
• invoke_tool – führt ein Tool aus

Zusammen ermöglichen diese Tools eine schrittweise Discovery und den Zugriff auf alle MCP-Server – inklusive integrierter Zugriffskontrolle und aller weiteren Gateway-Funktionen.

• Response Projection – Das MCP Gateway bietet zudem Response Projection, ein GraphQL-ähnliches Aufrufmuster für MCP-Tools. Dabei wird ein neues Feld in das Request-Schema des Tools eingefügt, das dem Gateway signalisiert, nur die benötigten Felder anzufordern – nicht alle. Das LLM liest die Felder und fügt ein Array verschachtelter Pfade ausschließlich für die erforderlichen Felder ein. Das Gateway kürzt die Antwort dann zur Laufzeit und behält nur die projizierten Felder. So konnten wir die API-Schema-Kompatibilität für MCP auf Enterprise-Niveau skalieren.
• Code Mode – Coding Agents arbeiten häufig in Shell-Umgebungen, in denen es effizienter ist, Tool-Ausgaben direkt in Dateien zu schreiben, statt vollständige Antworten in den Modellkontext zu laden. Der Code Mode bedient genau dieses Muster über aifx, Ubers CLI für agentenbasierte Operationen. Er leitet MCP-Aufrufe über das Gateway, ohne dass ein MCP-Server installiert sein muss. So finden Agents die passenden MCP-Tools für ihre Aufgabe, selbst wenn die MCP-Definition nicht im Kontext vorliegt. aifx bietet drei Befehle:
• aifx mcp list – listet verfügbare MCP-Server auf
• aifx mcp search – sucht serverübergreifend nach Tools
• aifx mcp call – führt ein MCP-Tool über das MCP Gateway aus

Agents können diese Befehle in einem einzigen Aufruf verketten und Ausgaben in Dateien schreiben. Filesystem-Agents durchsuchen diese dann gezielt per grep und laden nur das Nötigste in den Kontext. Der Code Mode ist heute der unternehmensweite Standard für die Nutzung von MCP-Tools in Coding Agents.

Fazit

Der Aufbau des MCP Gateways hat die Arbeitsweise von AI Agents bei Uber grundlegend verändert. Was als Fragmentierungsproblem begann – Dutzende Teams verdrahteten MCP-Integrationen eigenständig mit uneinheitlichen Tools, ohne gemeinsame Sicherheitsgarantien und mit doppelter Infrastruktur –, ist heute eine einheitliche, skalierbare Plattform, an die sich jedes Team in wenigen Minuten anbinden lässt.

Die zentrale Erkenntnis hinter unserem Design war simpel: Bestehende APIs sind der schnellste Weg, einem Agent Tools bereitzustellen. Anstatt Teams zu bitten, ihre Services für eine agentenbasierte Welt neu zu schreiben, holt das MCP Gateway sie dort ab, wo sie stehen. Es übersetzt HTTP-, gRPC- und TChannel-Aufrufe transparent über Muttley in MCP-kompatible Interaktionen – ganz ohne Änderungen an den Downstream-Services.

Wer agentenbasierte Systeme in großem Maßstab baut, weiß: Die größte Hürde ist nicht die KI. Es ist das Bindegewebe – die Discovery, die Sicherheit, die Zuverlässigkeit –, das Agents vertrauenswürdig genug macht, um in einer Produktionsumgebung im Namen echter Nutzer zu handeln. Das MCP Gateway ist unsere Antwort auf diese Herausforderung. Wir hoffen, dass die hier dokumentierten Designentscheidungen auch anderen helfen, die vor denselben Fragen stehen.

Danksagungen

Bildnachweis Titelbild: Generiert mit ChatGPT von OpenAI; keine externen Bilder, Logos oder Assets Dritter verwendet.

gRPC ist eine Marke der Linux Foundation.

Bleib auf dem Laufenden über Neuigkeiten aus dem Uber Engineering – folge uns auf LinkedIn für unsere neuesten Blogbeiträge und Insights.