Uber hat eine produktive MCP-Architektur beschrieben, die inzwischen mehr als 800 MCP-Server und mehr als 5.000 Tools verwaltet. Interessant ist weniger die Größe allein als die Entscheidung, Model Context Protocol nicht als Sammlung direkter Agent-zu-Server-Verbindungen zu betreiben.
Stattdessen läuft der Zugriff über ein zentrales MCP Gateway. Uber trennt dabei Control Plane und Data Plane: Eine Registry verwaltet Server, Tools, Eigentümer und Aktivierungszustände. Ein Proxy Gateway führt die tatsächlichen Aufrufe aus und übersetzt MCP-Anfragen in die Protokolle der bestehenden Backend-Systeme.
Vorhandene APIs werden zu Tools, bleiben aber zunächst deaktiviert
Uber betreibt tausende interne Services über HTTP, gRPC und TChannel. Für diese Dienste jeweils einen eigenen MCP-Server von Hand zu schreiben, wäre laut Engineering-Team nicht praktikabel gewesen.
Ein AutoCrawler durchsucht deshalb Ubers interne IDL-Registry nach neuen Services, APIs und Schemaänderungen. Aus Protobuf- und Thrift-Definitionen entstehen Tool-Schemas. Ein Sprachmodell ergänzt agentengerechte Beschreibungen.
Diese automatische Erkennung bedeutet aber noch keine Freigabe. Neu entdeckte Server und Tools landen standardmäßig deaktiviert in der Registry. Das zuständige Service-Team muss sie prüfen und aktivieren. Änderungen an Tool-Beschreibungen erzeugen einen Konfigurations-Diff, der erneut vom Eigentümer genehmigt werden muss.
Damit trennt Uber Discovery von Exposure. Ein internes API kann automatisch als möglicher Agentenbaustein gefunden werden, ohne dadurch sofort für Agenten ausführbar zu werden.
Der Gateway setzt Rechte beim Tool-Aufruf durch
Zur Laufzeit materialisiert der Proxy virtuelle MCP-Server und routet die Aufrufe an die vorhandenen Backend-Dienste. Für klassische Services übersetzt er JSON aus MCP in Protobuf oder Thrift und nutzt anschließend Ubers bestehendes Service-Mesh.
Die Sicherheitskontrolle sitzt damit nicht nur im Prompt des Agenten. Das Gateway verwendet Ubers internes Access-Control-System und kann unterschiedliche Policies für erkannte Akteure anwenden: Menschen, Services und Agenten. Regeln lassen sich auf Serverebene und bei Bedarf für einzelne Tools setzen.
Antworten können außerdem zentral auf personenbezogene oder andere sensible Daten geprüft und redigiert werden, bevor sie zum Agenten zurückgehen.
Bei externen MCP-Diensten leitet das Gateway den internen Nutzerkontext weiter. Ein separater Dienst tauscht ihn anschließend gegen das jeweilige Drittanbieter-Token. Auch Autorisierung, Rate Limits und Redaction bleiben im Gateway-Pfad.
5.000 Tool-Schemas passen nicht sinnvoll in einen Modellkontext
Die Größe erzeugte ein zweites Problem: Selbst wenn ein Modell technisch Zugriff auf tausende Tools haben darf, kann man nicht deren Namen, Beschreibungen und vollständige JSON-Schemas bei jeder Anfrage in den Kontext laden.
Uber löst das mit schrittweiser Discovery. Ein sogenannter Omni-MCP-Endpunkt bietet zunächst nur wenige Meta-Operationen: Server suchen, Tools eines Servers finden, ein Schema gezielt abrufen und anschließend das ausgewählte Tool ausführen.
Das Modell sieht damit nicht 5.000 vollständige Definitionen gleichzeitig. Es erweitert seinen Werkzeugraum erst während der Aufgabe.
Für Coding-Agenten verwendet Uber zusätzlich einen CLI-basierten „Code Mode“. Agenten können Tools suchen und aufrufen, Ergebnisse in Dateien schreiben und daraus nur die benötigten Ausschnitte in ihren Kontext laden. Uber bezeichnet diesen Modus inzwischen als Standard für MCP-Nutzung durch Coding-Agenten.
Die Registry wird zur Sicherheitsgrenze
Bei kleinen MCP-Setups liegt Vertrauen oft in der lokalen Konfiguration des Clients: Ein Entwickler trägt einen Server ein und der Agent bekommt dessen Tools. Bei Ubers Größenordnung wäre dieses Modell schwer zu kontrollieren.
Die zentrale Registry verschiebt deshalb mehrere Entscheidungen aus dem Agenten heraus: Welche Tools existieren, wem sie gehören, ob sie aktiviert sind und welche Identität sie aufrufen darf. Der Agent entscheidet weiterhin, welches zugelassene Tool für seine Aufgabe sinnvoll ist. Er entscheidet aber nicht selbst, ob ein neu gefundenes Tool grundsätzlich freigegeben wird.
Ubers Veröffentlichung enthält keine unabhängige Sicherheitsbewertung des Gateways und keine Messwerte zu Bypass-Raten oder Policy-Fehlern. Sie ist eine Engineering-Beschreibung des eigenen Produktionssystems. Trotzdem liefert sie eine selten konkrete Referenz dafür, wie MCP aussieht, wenn der Werkzeugraum von einigen lokalen Integrationen auf tausende produktive Aktionen wächst.
Quelle: Uber Engineering, „Designing MCP Gateway: Uber's MCP Management Platform“, 1. Oktober 2026.