Introdução
A rápida adoção de agentes de IA pela Uber mudou fundamentalmente a forma como as equipes interagem com código, dados e sistemas operacionais. As primeiras integrações pontuais com o MCP (Model Context Protocol) mostraram um valor claro: os agentes se tornaram drasticamente mais capazes quando puderam acessar o contexto de negócios em tempo real, consultar serviços internos e executar ações significativas em nome dos usuários. Essas vitórias iniciais validaram o MCP como uma abstração poderosa para construir sistemas agênticos dentro da Uber.
No entanto, à medida que a adoção acelerou, surgiram desafios significativos. Equipes individuais construíram integrações de forma independente, o que levou à fragmentação das ferramentas e à duplicação de infraestrutura. As ferramentas MCP eram difíceis de descobrir, complicadas de operar com confiabilidade e fortemente acopladas a serviços ou implementações de agentes específicos. Embora essas abordagens funcionassem em pequena escala, elas não atendiam às necessidades da Uber quando centenas de equipes começaram a explorar fluxos de trabalho agênticos. Sem uma arquitetura unificada, escalar o MCP aumentaria a complexidade operacional, o risco de segurança e o atrito para os desenvolvedores, limitando, no fim das contas, seu impacto.
Para liberar todo o potencial do MCP na escala da Uber, precisávamos de uma solução centralizada e escalável para padronizar a forma como os agentes de IA interagem com os sistemas de back-end existentes, preservando ao mesmo tempo a flexibilidade das equipes. Essa solução precisava abstrair as diferenças de protocolo (HTTP, gRPC™, TChannel), garantir padrões consistentes de segurança e observabilidade, e tornar as ferramentas MCP fáceis de criar, descobrir e reutilizar em toda a empresa.
Criamos o MCP Gateway para atender a essa necessidade. Trata-se de um microsserviço fundamental que impulsiona todas as interações MCP na Uber, funcionando como uma camada de orquestração e roteamento entre os agentes de IA, os serviços de back-end existentes e os servidores MCP nativos. Ao centralizar a lógica do MCP em um único gateway, oferecemos um modelo de execução consistente para as interações entre agentes e serviços, eliminando a necessidade de as equipes reinventarem a infraestrutura principal. APIs existentes podem ser expostas perfeitamente como ferramentas MCP, governadas e operadas em um só lugar, e consumidas por vários agentes de maneira uniforme. O MCP Gateway abriu um caminho escalável, rápido e consistente para a construção de agentes de IA dentro da Uber e atualmente hospeda mais de 800 servidores MCP e mais de 5000 ferramentas.
Figura 1: MCP Gateway (APIs como ferramentas).
Neste blog, analisamos o design do MCP Gateway, abordando a Camada de Proxy (tradução do MCP para protocolos existentes e vice-versa), a Camada de Descoberta (MCP Registry e rastreamento de APIs) e seu plano de controle (autoria).
O Gateway
O MCP Gateway segue uma arquitetura baseada em microsserviços, com o gateway atuando como o ponto central de integração entre os sistemas habilitados para IA e os serviços de back-end da Uber. A plataforma é composta por dois componentes principais: o MCP Registry, que atua como o plano de controle, e o Proxy Gateway, que forma o plano de dados.
O MCP Registry mantém um catálogo de centenas de servidores MCP apoiados por serviços internos, além de milhares de ferramentas MCP. Essas ferramentas variam desde definições no-code que expõem APIs existentes como ferramentas MCP até implementações totalmente nativas construídas especificamente sobre a especificação MCP. O registry fornece uma fonte única de verdade para descoberta, propriedade e ativação em todo o ecossistema.
O Proxy Gateway é responsável por executar as requisições MCP em tempo de execução. Ele traduz as chamadas do protocolo MCP em requisições HTTP, gRPC ou TChannel, encaminha-as para o serviço de back-end apropriado e converte as respostas de volta em resultados compatíveis com o MCP. Essa camada de tradução permite que os agentes de IA interajam com os sistemas existentes por meio de uma interface MCP consistente, sem exigir alterações nos serviços subjacentes.
Plano de Controle
A Uber utiliza uma arquitetura de microsserviços e executa milhares de serviços internos que expõem APIs via HTTP, gRPC e TChannel. Essas APIs fornecem um contexto valioso para um sistema de IA, mas pedir que as equipes criassem manualmente um servidor MCP seria lento e doloroso. Para resolver esse problema, construímos o AutoCrawler, que varre continuamente o registry de IDL da Uber em busca de APIs, traduzindo-as e atualizando-as no registry. Ele também consulta servidores MCP nativos e os adiciona ao registry.
AutoCrawler: Motor de Descoberta
O Autocrawler é um sistema de fluxo de trabalho distribuído alimentado pelo Cadence, inscrito no registry de IDL da Uber e nos sinais de serviços internos. Em um cronograma fixo, um job cron dispara um fluxo de trabalho do Cadence que busca por serviços recém-adicionados, APIs e mudanças de esquema.
Para cada entidade descoberta, o AutoCrawler é responsável por:
- Criar ou atualizar representações de servidores MCP
- Gerar ou buscar definições e esquemas de ferramentas
- Registrar ferramentas no MCP Registry em um estado desativado por padrão
Essa base compartilhada permite que a descoberta de MCP escale para milhares de serviços, mantendo as equipes de serviço fora do caminho crítico.
Figura 2: Auto Crawler.
Descoberta para Serviços Baseados em IDL
Para serviços de back-end tradicionais definidos por meio de IDLs Protobuf ou Thrift, o AutoCrawler deriva servidores e ferramentas MCP diretamente do IDL Registry. Para cada grupo de API de serviço, o AutoCrawler executa as seguintes etapas:
- Inserir ou atualizar servidor MCP: Cria ou atualiza um servidor MCP virtual correspondente ao serviço descoberto.
- Analisar definições de IDL: Analisa os arquivos protobuf ou Thrift associados para extrair nomes de métodos, esquemas de requisição e resposta, e comentários de documentação.
- Gerar descrições de ferramentas: Usa um LLM para gerar descrições de ferramentas MCP enriquecidas e otimizadas para agentes, com base nos esquemas e comentários extraídos.
- Tradução de esquema: Traduz esquemas protobuf ou Thrift em esquemas JSON-RPC 2.0 compatíveis com MCP.
- Inserir ou atualizar ferramentas MCP: Registra ou atualiza as ferramentas MCP geradas no MCP Registry em um estado desativado por padrão.
Descoberta para Servidores Nativos
Além dos serviços baseados em IDL, o MCP Gateway também suporta servidores MCP nativos — serviços que implementam o protocolo MCP diretamente e expõem ferramentas otimizadas para agentes.
O MCPFx é o framework que a Uber usa para construir servidores MCP nativos. Cada servidor MCP nativo emite uma métrica de heartbeat que sinaliza sua presença e prontidão. O AutoCrawler monitora continuamente esses sinais de heartbeat para descobrir automaticamente novos servidores MCP nativos. Quando um servidor MCP nativo é descoberto, o AutoCrawler segue um caminho de descoberta diferente:
- Ele faz uma chamada listTools ao servidor MCP nativo para recuperar as ferramentas que ele expõe explicitamente, junto com seus esquemas.
- Ele cria um servidor MCP de proxy virtual no MCP Registry que contém todas as ferramentas descobertas e seus esquemas, em um estado desativado por padrão.
Servidores MCP de Terceiros
O MCP Gateway atua como a camada de orquestração centralizada para todas as interações MCP na Uber, estendendo suporte contínuo a integrações de terceiros, como Jira e Google.
O provisionamento de servidores MCP de terceiros depende da cooperação de dois componentes essenciais:
- MCP Gateway: Repassa o token de usuário do chamador para o downstream, aplicando recursos essenciais do gateway, incluindo autorização, limitação de taxa (rate limiting) e redação de dados sensíveis.
- Serviço MCP de Terceiros: Troca o token de usuário interno por um token de autenticação de terceiros correspondente antes de enviar a requisição ao servidor MCP externo.
Autoria e Ativação
Embora possamos criar servidores MCP sem envolver a equipe de serviço, a propriedade e o controle do servidor MCP devem pertencer a ela. Um princípio central de design do MCP Gateway é que a descoberta não implica exposição. Todo servidor e ferramenta MCP começa em um estado desativado e deve ser explicitamente revisado e ativado pela equipe proprietária. Os donos do serviço podem revisar e refinar as definições de ferramentas geradas antes de ativá-las.
Toda alteração na descrição da ferramenta gera um diff de mudança de configuração, que deve ser aprovado pelos proprietários do servidor. Eles podem aprovar e implantar a mudança de configuração e, se necessário, reverter para uma versão anterior conhecida.
Figura 3: Interface do MCP Registry.
Figura 4: Interface da ferramenta MCP.
Plano de Dados
O plano de dados do MCP Gateway é o serviço de runtime central responsável por executar as requisições MCP. Ele consome continuamente configurações de servidores e ferramentas do plano de controle e atualiza seu estado em memória em uma cadência fixa, permitindo que mudanças de configuração — como atualizações de ferramentas ou alterações de ativação — entrem em vigor em tempo real, sem reinicializações ou novas implantações de serviço.
Com base nessa configuração, o plano de dados materializa dinamicamente servidores MCP virtuais. Para cada servidor virtual, o Gateway expõe um único endpoint /<service-name>/mcp que serve como ponto de entrada para a execução pelo agente de IA. As requisições recebidas são resolvidas para seus respectivos handlers de servidor por meio de um servidor de proxy integrado.
Figura 5: Plano de Dados do MCP Gateway.
Tradução de Protocolo e Execução
A tradução de protocolo no MCP Gateway é gerenciada por handlers de servidor dentro do Proxy Gateway. Cada handler de servidor tem conhecimento das ferramentas e dos serviços downstream, permitindo rotear e executar corretamente as requisições MCP em tempo de execução.
Segurança
O MCP Gateway fornece autorização e redação integradas para todos os servidores com granularidade em nível de ferramenta. O MCP Gateway usa o Sistema de Controle de Acesso interno da Uber para aplicar diferentes políticas charter configuradas nos atores chamadores detectados (humanos, serviços e agentes). As políticas charter são criadas no nível do servidor, com substituições opcionais no nível da ferramenta, se necessário.
O MCP Gateway também realiza, nativamente, a redação de qualquer PII (informação de identificação pessoal) ou dado sensível presente nas respostas das ferramentas.
Serviços Downstream Baseados em IDL
Para ferramentas apoiadas por serviços de back-end existentes, o handler do servidor mantém um mapeamento em memória que descreve o destino downstream, como a configuração de endpoint HTTP ou procedimentos gRPC/TChannel.
Quando uma requisição MCP chega, o handler:
- Traduz o payload JSON recebido para o formato de transmissão adequado.
- Serializa a requisição em bytes Protobuf ou Thrift.
- Encaminha a requisição para o serviço downstream.
- Traduz as respostas em bytes Protobuf ou Thrift de volta para JSON compatível com MCP e as retorna ao agente chamador.
A requisição downstream real é executada via Muttley, o sidecar de service mesh da Uber que roda junto a todos os serviços de back-end. Ao delegar a execução da requisição ao Muttley, o MCP Gateway se beneficia automaticamente dos recursos existentes de roteamento serviço a serviço.
Servidores MCP Nativos
Os servidores MCP nativos também são registrados como servidores virtuais no MCP registry, que atua como um proxy para o servidor original. Em tempo de execução, as requisições MCP nativas são transparentemente enviadas via proxy para o servidor downstream, e as respostas retornam via proxy para o chamador.
Benefícios do Gateway
Ao construir o MCP-Gateway, a Uber alcançou uma abordagem escalável e unificada para a criação de sistemas agênticos, com os benefícios mais impactantes vindo de:
- Facilidade de descoberta e instalação
- Abordagem no-code para APIs existentes
- Observabilidade e segurança integradas
- Propriedade e governança centralizadas
Expandindo o Gateway
Escalar o MCP Gateway para centenas de servidores e milhares de ferramentas revelou problemas que não existem em pequena escala. Inchaço de Contexto e Custo Excessivo
Descoberta em Tempo de Execução
O MCP não possui um conceito nativo de busca entre servidores. Um agente já precisa saber com qual servidor falar antes de poder perguntar quais ferramentas estão disponíveis. Configurar um agente para usar um servidor MCP exige conectar explicitamente a URL do servidor, as credenciais e a lista de ferramentas. Fazer isso para centenas de servidores não escala, pois todo esse contexto consumiria o limite de contexto do modelo. Resolvemos esse problema com o seguinte:
- Omni MCP - Um único servidor de proxy que permite aos clientes MCP acessar qualquer um dos servidores do MCP Gateway com um padrão de descoberta gradual, o que também viabiliza a otimização de contexto/tokens por meio de descoberta incremental. O Omni MCP expõe estas ferramentas:
- discover_server - descobre o servidor MCP com base na intenção da consulta
- discover_tools - busca ferramentas para um servidor
- get_tool_schema - obtém o esquema json de uma ferramenta
- invoke_tool - invoca uma ferramenta
Juntas, essas ferramentas permitem a descoberta incremental e o acesso a todos os servidores MCP, com controle de acesso integrado e o restante dos recursos do gateway.
- Projeção de Resposta - O MCP Gateway também oferece Projeção de Resposta, um padrão de chamada semelhante ao GraphQL para ferramentas MCP. Funciona injetando um novo campo no esquema de requisição da ferramenta, instruindo o gateway a solicitar apenas os campos necessários, e não todos. O LLM lê e injeta os campos com um array de caminhos aninhados contendo apenas os campos obrigatórios. O Gateway então reduz a resposta em tempo de execução, mantendo apenas os campos projetados. Isso nos permitiu escalar a compatibilidade de esquemas de API para o MCP em nível corporativo.
- Code Mode - Agentes de codificação frequentemente operam em ambientes shell, onde gravar a saída da ferramenta diretamente em arquivos é mais eficiente do que carregar respostas completas no contexto do modelo. O Code Mode atende a esse padrão por meio do aifx, a CLI da Uber para operações agênticas, roteando chamadas MCP pelo gateway sem exigir que nenhum servidor MCP seja instalado. Ele ajuda os agentes a descobrir as ferramentas MCP corretas para o trabalho sem que a definição do MCP precise estar presente no contexto. O aifx expõe três comandos:
- aifx mcp list - lista os servidores MCP disponíveis
- aifx mcp search - busca ferramentas em todos os servidores MCP
- aifx mcp call - invoca uma ferramenta MCP através do MCP Gateway
Os agentes podem encadear esses comandos em uma única instrução e gravar a saída em arquivos, que os agentes de sistema de arquivos filtram seletivamente com grep, carregando no contexto apenas o que precisam. O Code Mode é agora o padrão da empresa para o uso de ferramentas MCP em agentes de codificação.
Conclusão
A construção do MCP Gateway mudou fundamentalmente a forma como os agentes de IA operam na Uber. O que começou como um problema de fragmentação, com dezenas de equipes conectando independentemente integrações MCP usando ferramentas inconsistentes, sem garantias de segurança compartilhadas e com infraestrutura duplicada, é hoje uma plataforma unificada e escalável na qual qualquer equipe pode se integrar em questão de minutos.
A percepção central que guiou nosso design foi simples: as APIs existentes são a maneira mais rápida de fornecer ferramentas a um agente. Em vez de pedir que as equipes reescrevessem seus serviços para um mundo agêntico, o MCP Gateway vai ao encontro delas — traduzindo chamadas HTTP, gRPC e TChannel em interações compatíveis com MCP de forma transparente, por meio do Muttley, com zero alterações nos serviços downstream.
Se você está construindo sistemas agênticos em escala, a parte mais difícil não é a IA. É construir o tecido conjuntivo — a descoberta, a segurança, a confiabilidade — que torna os agentes confiáveis o suficiente para agir em nome de usuários reais em um ambiente de produção. O MCP Gateway é a nossa resposta para esse desafio, e esperamos que as decisões de design documentadas aqui sejam úteis para outras pessoas que enfrentam o mesmo problema.
Agradecimentos
Créditos da Foto de Capa: Gerada com ChatGPT da OpenAI; nenhuma imagem externa, logotipo ou recurso de terceiros foi utilizado.
gRPC é uma marca registrada da The Linux Foundation.
Fique por dentro das novidades da Uber Engineering — siga-nos no LinkedIn para conferir nossos artigos e insights mais recentes.
