Introduzione
La rapida adozione degli agenti AI da parte di Uber ha cambiato radicalmente il modo in cui i team interagiscono con codice, dati e sistemi operativi. Le prime integrazioni ad hoc con l'MCP (Model Context Protocol) hanno dimostrato un valore evidente: gli agenti sono diventati drasticamente più capaci nel momento in cui hanno potuto accedere al contesto aziendale in tempo reale, interrogare i servizi interni ed eseguire azioni concrete per conto degli utenti. Questi primi successi hanno confermato l'MCP come un'astrazione potente per costruire sistemi agentici all'interno di Uber.
Tuttavia, con l'accelerazione dell'adozione, sono emerse sfide significative. I singoli team sviluppavano integrazioni in modo indipendente, portando a una frammentazione degli strumenti e alla duplicazione dell'infrastruttura. Gli strumenti MCP erano difficili da individuare, complessi da gestire in modo affidabile e strettamente accoppiati a servizi o implementazioni specifiche degli agenti. Sebbene questi approcci funzionassero su piccola scala, non rispondevano alle esigenze di Uber quando centinaia di team hanno iniziato a esplorare i workflow agentici. Senza un'architettura unificata, scalare l'MCP avrebbe aumentato la complessità operativa, i rischi per la sicurezza e l'attrito per gli sviluppatori, limitandone in definitiva l'impatto.
Per sbloccare tutto il potenziale dell'MCP su scala Uber, avevamo bisogno di una soluzione centralizzata e scalabile che standardizzasse il modo in cui gli agenti AI interagiscono con i sistemi back-end esistenti, preservando al contempo la flessibilità per i team. Questa soluzione doveva astrarre le differenze tra i protocolli (HTTP, gRPC™, TChannel), garantire policy di sicurezza e osservabilità coerenti e rendere gli strumenti MCP facili da creare, scoprire e riutilizzare in tutta l'azienda.
Abbiamo costruito l'MCP Gateway proprio per rispondere a questa esigenza. Si tratta di un microservizio fondamentale che gestisce tutte le interazioni MCP in Uber, fungendo da livello di orchestrazione e routing tra gli agenti AI, i servizi back-end esistenti e i server MCP nativi. Centralizzando la logica MCP in un unico gateway, offriamo un modello di esecuzione coerente per le interazioni agente-servizio, eliminando la necessità per i team di reinventare l'infrastruttura di base. Le API esistenti possono essere esposte senza problemi come strumenti MCP, governate e gestite in un unico punto e utilizzate da più agenti in modo uniforme. L'MCP Gateway ha aperto una strada scalabile, veloce e coerente per lo sviluppo di agenti AI all'interno di Uber e attualmente ospita oltre 800 server MCP e più di 5000 strumenti.
Figura 1: MCP Gateway (le API come strumenti).
In questo articolo analizziamo il design dell'MCP Gateway, illustrando il Proxy Layer (la traduzione dall'MCP ai protocolli esistenti e viceversa), il Discovery Layer (MCP Registry e crawling delle API) e il suo control plane (authoring).
Il Gateway
L'MCP Gateway segue un'architettura basata su microservizi, in cui il gateway agisce come punto di integrazione centrale tra i sistemi abilitati all'AI e i servizi back-end di Uber. La piattaforma è composta da due elementi principali: l'MCP Registry, che funge da control plane, e il Proxy Gateway, che costituisce il data plane.
L'MCP Registry mantiene un catalogo di centinaia di server MCP supportati da servizi interni, insieme a migliaia di strumenti MCP. Questi strumenti spaziano dalle definizioni no-code, che espongono le API esistenti come strumenti MCP, fino a implementazioni completamente native costruite esplicitamente secondo le specifiche MCP. Il registry fornisce un'unica fonte di verità per la discovery, la ownership e l'abilitazione all'interno dell'intero ecosistema.
Il Proxy Gateway è responsabile dell'esecuzione delle richieste MCP a runtime. Traduce le chiamate del protocollo MCP in richieste HTTP, gRPC o TChannel, le inoltra al servizio back-end appropriato e converte le risposte in risultati compatibili con l'MCP. Questo livello di traduzione consente agli agenti AI di interagire con i sistemi esistenti attraverso un'interfaccia MCP coerente, senza richiedere modifiche ai servizi sottostanti.
Control Plane
Uber utilizza un'architettura a microservizi e gestisce migliaia di servizi interni che espongono API tramite HTTP, gRPC e TChannel. Queste API forniscono un contesto prezioso a un sistema AI, ma chiedere ai team di creare manualmente un server MCP sarebbe stato lento e doloroso. Per risolvere questo problema abbiamo sviluppato AutoCrawler, che scansiona continuamente il registry IDL di Uber alla ricerca di API, le traduce e le aggiorna nel registry. Inoltre, interroga i server MCP nativi e li aggiunge al registro.
AutoCrawler: il motore di discovery
Autocrawler è un sistema di workflow distribuito basato su Cadence, collegato al registry IDL di Uber e ai segnali dei servizi interni. Secondo una pianificazione fissa, un cron job avvia un workflow Cadence che cerca nuovi servizi, API e modifiche agli schemi appena aggiunti.
Per ogni entità individuata, AutoCrawler si occupa di:
- Creare o aggiornare le rappresentazioni dei server MCP
- Generare o recuperare le definizioni e gli schemi degli strumenti
- Registrare gli strumenti nell'MCP Registry in uno stato disabilitato di default
Questa base condivisa permette alla discovery MCP di scalare su migliaia di servizi, mantenendo i team responsabili dei servizi fuori dal percorso critico.
Figura 2: Auto Crawler.
Discovery per i servizi basati su IDL
Per i tradizionali servizi back-end definiti tramite IDL Protobuf o Thrift, AutoCrawler ricava server e strumenti MCP direttamente dall'IDL Registry. Per ogni gruppo di API di un servizio, AutoCrawler esegue i seguenti passaggi:
- Upsert del server MCP: crea o aggiorna un server MCP virtuale corrispondente al servizio individuato.
- Parsing delle definizioni IDL: analizza i file protobuf o Thrift associati per estrarre i nomi dei metodi, gli schemi di richiesta e risposta e i commenti della documentazione.
- Generazione delle descrizioni degli strumenti: utilizza un LLM per generare descrizioni degli strumenti MCP arricchite e ottimizzate per gli agenti, basandosi sugli schemi e sui commenti estratti.
- Traduzione dello schema: converte gli schemi protobuf o Thrift in schemi JSON-RPC 2.0 compatibili con l'MCP.
- Upsert degli strumenti MCP: registra o aggiorna gli strumenti MCP generati nell'MCP Registry in uno stato disabilitato di default.
Discovery per i server nativi
Oltre ai servizi basati su IDL, l'MCP Gateway supporta anche i server MCP nativi, ovvero servizi che implementano direttamente il protocollo MCP ed espongono strumenti ottimizzati per gli agenti.
MCPFx è il framework utilizzato da Uber per costruire server MCP nativi. Ogni server MCP nativo emette una metrica di heartbeat che ne segnala la presenza e la disponibilità. AutoCrawler monitora costantemente questi segnali di heartbeat per individuare automaticamente i nuovi server MCP nativi. Quando viene rilevato un server MCP nativo, AutoCrawler segue un percorso di discovery diverso:
- Effettua una chiamata listTools al server MCP nativo per recuperare gli strumenti che espone esplicitamente, insieme ai relativi schemi.
- Crea un server MCP proxy virtuale nell'MCP Registry che contiene tutti gli strumenti e gli schemi individuati, in uno stato disabilitato di default.
Server MCP di terze parti
L'MCP Gateway funge da livello di orchestrazione centralizzato per tutte le interazioni MCP in Uber, estendendo un supporto trasparente alle integrazioni di terze parti come Jira e Google.
Il provisioning dei server MCP di terze parti si basa sulla collaborazione di due componenti chiave:
- MCP Gateway: inoltra il token utente del chiamante verso valle, applicando al contempo le funzionalità essenziali del gateway, tra cui autorizzazione, rate limiting e redaction dei dati sensibili.
- Servizio MCP di terze parti: scambia il token utente interno con un corrispondente token di autenticazione di terze parti prima di inviare la richiesta al server MCP esterno.
Authoring e abilitazione
Anche se possiamo creare server MCP senza coinvolgere il team responsabile del servizio, la proprietà e il controllo del server MCP devono rimanere nelle mani del team stesso. Un principio di design fondamentale dell'MCP Gateway è che la discovery non implica l'esposizione. Ogni server e strumento MCP parte in uno stato disabilitato e deve essere esplicitamente revisionato e abilitato dal team proprietario. I service owner possono esaminare e perfezionare le definizioni degli strumenti generate prima di attivarle.
Ogni modifica alla descrizione dello strumento genera un diff di configurazione, che deve essere approvato dai proprietari del server. I proprietari possono approvare e rilasciare la modifica di configurazione e, se necessario, eseguire il rollback a una versione precedente nota.
Figura 3: UI dell'MCP Registry.
Figura 4: UI dello strumento MCP.
Data Plane
Il data plane dell'MCP Gateway è il servizio di runtime principale responsabile dell'esecuzione delle richieste MCP. Consuma continuamente le configurazioni di server e strumenti dal control plane e aggiorna il proprio stato in memoria a intervalli regolari, consentendo alle modifiche di configurazione — come gli aggiornamenti degli strumenti o i cambi di stato di abilitazione — di avere effetto in tempo reale senza riavvii o nuove distribuzioni del servizio.
Sulla base di questa configurazione, il data plane materializza dinamicamente i server MCP virtuali. Per ogni server virtuale, il Gateway espone un singolo endpoint /<service-name>/mcp che funge da punto di ingresso per l'esecuzione da parte degli agenti AI. Le richieste in arrivo vengono indirizzate ai rispettivi handler del server tramite un proxy server integrato.
Figura 5: Data Plane dell'MCP Gateway.
Traduzione dei protocolli ed esecuzione
La traduzione dei protocolli nell'MCP Gateway è gestita dagli handler dei server all'interno del Proxy Gateway. Ogni handler è consapevole sia degli strumenti sia dei servizi downstream, permettendogli di instradare ed eseguire correttamente le richieste MCP a runtime.
Sicurezza
L'MCP Gateway offre autorizzazione e redaction integrate per tutti i server, con granularità a livello di singolo strumento. L'MCP Gateway utilizza l'Access Control System interno di Uber per applicare diverse policy charter configurate sugli attori chiamanti rilevati (persone, servizi e agenti). Le policy charter vengono create a livello di server, con eventuali override a livello di strumento se necessario.
L'MCP Gateway esegue inoltre out-of-the-box la redaction di qualsiasi dato PII o sensibile presente nelle risposte degli strumenti.
Servizi downstream basati su IDL
Per gli strumenti supportati da servizi back-end esistenti, l'handler del server mantiene una mappatura in memoria che descrive la destinazione downstream, come la configurazione dell'endpoint HTTP o le procedure gRPC/TChannel.
Quando arriva una richiesta MCP, l'handler:
- Traduce il payload JSON in arrivo nel formato wire appropriato.
- Serializza la richiesta in byte Protobuf o Thrift.
- Inoltra la richiesta al servizio downstream.
- Converte le risposte in byte Protobuf o Thrift nuovamente in JSON compatibile con l'MCP e le restituisce all'agente chiamante.
La richiesta downstream effettiva viene eseguita tramite Muttley, il sidecar del service mesh di Uber che opera accanto a tutti i servizi back-end. Delegando l'esecuzione delle richieste a Muttley, l'MCP Gateway beneficia automaticamente delle capacità di routing service-to-service già esistenti.
Server MCP nativi
Anche i server MCP nativi vengono registrati come server virtuali nell'MCP Registry, che agisce da proxy verso il server originale. A runtime, le richieste MCP native vengono inoltrate in modo trasparente al server downstream e le risposte vengono restituite al chiamante.
I vantaggi del Gateway
Costruendo l'MCP-Gateway, Uber ha ottenuto un approccio scalabile e unificato allo sviluppo di sistemi agentici. I vantaggi più impattanti derivano da:
- Facile discovery e installazione
- Approccio no-code per le API esistenti
- Osservabilità e sicurezza integrate
- Ownership e governance centralizzate
Estendere il Gateway
Scalare l'MCP Gateway a centinaia di server e migliaia di strumenti ha fatto emergere problemi che non esistono su piccola scala. Context Bloat e costi eccessivi
Runtime Discovery
L'MCP non prevede nativamente il concetto di ricerca cross-server. Un agente deve già sapere con quale server comunicare prima di poter chiedere quali strumenti siano disponibili. Configurare un agente affinché utilizzi un server MCP richiede il collegamento esplicito dell'URL del server, delle credenziali e dell'elenco degli strumenti. Farlo per centinaia di server non è scalabile, poiché tutto questo contesto saturerebbe rapidamente il limite di contesto del modello. Abbiamo risolto questo problema nel modo seguente:
- Omni MCP - Un singolo server proxy che consente ai client MCP di accedere a qualsiasi server dell'MCP Gateway seguendo un pattern di discovery graduale, che sblocca anche l'ottimizzazione di contesto e token tramite la discovery incrementale. Omni MCP espone questi strumenti:
- discover_server - individua il server MCP in base all'intento della query
- discover_tools - cerca gli strumenti per un determinato server
- get_tool_schema - recupera lo schema json di uno strumento
- invoke_tool - invoca uno strumento
Insieme, questi strumenti abilitano la discovery incrementale e l'accesso a tutti i server MCP, con controllo degli accessi integrato e tutte le altre funzionalità del gateway.
- Response Projection - L'MCP Gateway offre anche la Response Projection, un pattern di chiamata simile a GraphQL per gli strumenti MCP. Funziona iniettando un nuovo campo nello schema di richiesta dello strumento, che indica al gateway di richiedere solo i campi necessari e non tutti. L'LLM legge e inserisce i campi sotto forma di array di percorsi annidati contenenti esclusivamente i campi richiesti. Il Gateway riduce poi la risposta a runtime, conservando solo i campi proiettati. Questo ci ha permesso di scalare la compatibilità degli schemi API per l'MCP a livello enterprise.
- Code Mode - Gli agenti di coding operano spesso in ambienti shell dove scrivere l'output degli strumenti direttamente su file è più efficiente rispetto al caricamento di intere risposte nel contesto del modello. Il Code Mode supporta questo pattern tramite aifx, la CLI di Uber per le operazioni agentiche, instradando le chiamate MCP attraverso il gateway senza richiedere l'installazione di alcun server MCP. Aiuta gli agenti a individuare gli strumenti MCP corretti per il lavoro da svolgere, anche senza che la definizione MCP sia presente nel contesto. aifx espone tre comandi:
- aifx mcp list - elenca i server MCP disponibili
- aifx mcp search - cerca strumenti tra tutti i server MCP
- aifx mcp call - invoca uno strumento MCP tramite l'MCP Gateway
Gli agenti possono concatenarli in un singolo comando e scrivere l'output su file, che gli agenti filesystem analizzano selettivamente con grep, caricando nel contesto solo ciò di cui hanno effettivamente bisogno. Il Code Mode è oggi lo standard aziendale per l'utilizzo degli strumenti MCP negli agenti di coding.
Conclusione
La creazione dell'MCP Gateway ha cambiato radicalmente il modo in cui gli agenti AI operano in Uber. Quello che era nato come un problema di frammentazione — con decine di team che collegavano in modo indipendente integrazioni MCP utilizzando strumenti eterogenei, senza garanzie di sicurezza condivise e con infrastrutture duplicate — è oggi una piattaforma unificata e scalabile a cui qualsiasi team può connettersi in pochi minuti.
L'intuizione fondamentale alla base del nostro design era semplice: le API esistenti sono il modo più rapido per fornire strumenti a un agente. Invece di chiedere ai team di riscrivere i propri servizi per un mondo agentico, l'MCP Gateway li incontra esattamente dove si trovano, traducendo le chiamate HTTP, gRPC e TChannel in interazioni compatibili con l'MCP in modo trasparente, tramite Muttley e senza alcuna modifica ai servizi downstream.
Se state costruendo sistemi agentici su larga scala, la parte più difficile non è l'AI. È costruire il tessuto connettivo — la discovery, la sicurezza, l'affidabilità — che rende gli agenti abbastanza affidabili da agire per conto di utenti reali in un ambiente di produzione. L'MCP Gateway è la nostra risposta a questa sfida, e speriamo che le scelte di design documentate qui possano essere utili ad altri che affrontano lo stesso problema.
Ringraziamenti
Attribuzione foto di copertina: generata con ChatGPT di OpenAI; nessuna immagine esterna, logo o risorsa di terze parti utilizzata.
gRPC è un marchio registrato di The Linux Foundation.
Resta aggiornato sulle ultime novità di Uber Engineering: seguici su LinkedIn per i nostri articoli e approfondimenti più recenti.
