Uber constrói MCP Gateway para governar 5 mil ferramentas de agentes de IA

A Uber publicou, em 2 de novembro de 2026, os detalhes de um MCP↳MCP7 conteúdosArquitetura de Sistemas Cognitivos: Integração de RAG, MCP e LLMs no Ecossistema .NETDev (Back & Front) · abr 2026MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025Agentes de IA com LLMs de Código Aberto: Integração Prática com o Model Context Protocol (MCP)AI · ago 2025Ver tudo em AI → Gateway construído internamente para resolver um problema que qualquer empresa que está escalando agentes de IA vai reconhecer: integrações fragmentadas, infraestrutura duplicada e práticas de segurança inconsistentes. Segundo o relato reproduzido pelo InfoQ, a plataforma já sustenta mais de 800 servidores MCP e 5 mil ferramentas, funcionando como camada comum de descoberta, tradução de protocolo, autorização e execução para todos os agentes da empresa.

O caso importa menos pelo número bruto e mais pelo que ele expõe: o Model Context Protocol (MCP) virou padrão de fato para conectar agentes a sistemas corporativos, mas ninguém resolveu sozinho o problema de governar centenas de servidores MCP crescendo sem controle. A Uber tratou isso como problema de infraestrutura, não de IA.

O problema antes do gateway

Antes do gateway, cada time que queria expor um serviço para agentes precisava construir sua própria integração MCP, reimplementando autenticação, schemas e lógica de execução. O resultado é o mesmo de qualquer ambiente de microsserviços↳Microsserviços24 conteúdosArquitetura de Microsserviços em Node com o MoleculerJSDev (Back & Front) · jun 2025Segurança das APIs: como proteger seu ecossistema de microsserviçosDev (Back & Front) · dez 2023Você provavelmente não precisa de microsserviços (ainda)Dev (Back & Front) · mar 2026Ver tudo em Dev (Back & Front) → sem padronização: múltiplas implementações do mesmo tipo de problema, nenhuma delas auditável de forma central.

A solução da Uber foi tratar os agentes como mais um tipo de cliente de API, e aplicar a esse cliente o mesmo rigor arquitetural que a empresa já aplica a APIs REST e gRPC internas. Isso significou separar claramente duas responsabilidades que, em implementações mais simples de MCP, costumam ficar misturadas.

Duas camadas: registro e proxy

A arquitetura descrita pelos engenheiros da Uber divide o sistema em dois componentes com responsabilidades distintas:

• MCP Registry: funciona como plano de controle. Mantém definições de ferramentas, schemas, informações de ownership (qual time é dono de qual ferramenta) e configurações de habilitação.
• Proxy Gateway: cuida da execução em tempo real. Traduz requisições MCP para chamadas HTTP, gRPC ou TChannel contra os serviços reais, e converte as respostas de volta para o formato MCP.

Essa separação é o que permite expor APIs internas já existentes como ferramentas MCP sem alterar o código dos serviços originais, uma decisão que reduz drasticamente o custo de adoção para cada time. Não é coincidência que a abordagem tenha sido comparada a padrões já conhecidos de API gateway. Ajay Sharma, Principal Software Engineer na Microsoft CoreAI, resumiu o ponto num post no LinkedIn:

Os Azure API Gateways já fazem isso há um bom tempo. É uma receita para trazer ordem ao caos que os LLMs trazem.

Ajay Sharma, Principal Software Engineer na Microsoft CoreAIAzure API Gateways has been doing this for a while now. It's a recipe for order to the chaos that LLMs come with.

Kelly Goetsch, presidente da Pipe17, fez observação parecida:

O novo MCP gateway da Uber parece idêntico aos gateways que construímos ao longo das décadas para APIs e, depois, para GraphQL.

Kelly Goetsch, Presidente na Pipe17Uber's new MCP gateway looks identical to gateways we've built over the decades for APIs and later GraphQL.

Tamir Dresher, em outro post citado pelo InfoQ, reforçou que o desenho não inventa problemas novos: segurança, descoberta, observabilidade↳Observabilidade11 conteúdosObservabilidade para APIs: os desafios e benefícios dessa abordagemDev (Back & Front) · jan 2025Falhas em Observabilidade afetam os Apps e a Segurança das OrganizaçõesDev (Back & Front) · nov 2023ADK Java 1.0: O Google quer que você pare de gambiarra Python no seu backendMarketing Tech · abr 2026Ver tudo em DevSecOps → e governança continuam sendo as mesmas preocupações de sempre em sistemas distribuídos, só que agora aplicadas a agentes.

AutoCrawler: descoberta automática de ferramentas

Com mais de 800 servidores, catalogar ferramentas manualmente não escala. A Uber construiu o AutoCrawler, que roda sobre Cadence (o próprio motor de workflows da empresa) e automatiza a descoberta:

1. Escaneia os registros internos de interface definition language (IDL) da empresa.
2. Extrai definições de API a partir de schemas Protocol Buffers e Thrift.
3. Gera schemas compatíveis com MCP a partir dessas definições.
4. Usa um modelo de linguagem para produzir as descrições das ferramentas.

Um detalhe de governança é relevante aqui: ferramentas recém-descobertas ficam desabilitadas por padrão até que o time dono faça a revisão e habilite explicitamente o acesso. Mudanças de configuração se propagam para o plano de dados sem exigir restart ou novo deploy dos serviços, o que mantém o catálogo atualizado sem fricção operacional para quem mantém os serviços de origem.

Segurança: autorização, PII e tokens de terceiros

O gateway aplica autorização em dois níveis, de servidor e de ferramenta, usando o sistema interno de controle de acesso da Uber. Isso significa que um agente pode ter acesso a um servidor MCP mas não a todas as ferramentas expostas por ele, o que é o tipo de granularidade que falta na maioria das integrações MCP feitas às pressas.

O sistema também suporta redação de dados pessoais (PII) e outras informações sensíveis nas respostas das ferramentas, antes que o conteúdo chegue ao agente. Para integrações com serviços de terceiros, como Jira e Google, um serviço separado troca tokens internos de usuário pelos tokens de autenticação correspondentes de cada terceiro, evitando que credenciais internas vazem para fora do perímetro da empresa.

Omni MCP: o problema do contexto que cresce demais

Com o catálogo de ferramentas em milhares de itens, carregar todas as definições no contexto de um agente deixa de ser viável, tanto por custo de tokens quanto por latência. A Uber respondeu com o Omni MCP, que implementa descoberta incremental: o agente busca servidores, descobre as ferramentas relevantes para a tarefa, recupera o schema individual de cada uma e só então invoca as que precisa, em vez de carregar o catálogo inteiro de uma vez.

Um segundo mecanismo, chamado Response Projection, permite que o agente peça apenas campos específicos da resposta, em vez de receber o payload completo de volta. Para quem já lidou com agentes que estouram janela de contexto processando JSON gigante de uma API só para usar três campos, o ganho prático é direto.

A Uber também mantém uma CLI chamada aifx, que permite que agentes de codificação descubram e invoquem ferramentas diretamente, escrevendo os resultados em arquivos para inspeção seletiva, em vez de despejar tudo no contexto da conversa.

O que isso significa para quem constrói com MCP

O caso da Uber é um sinal de maturidade para o ecossistema MCP: a primeira onda de adoção, de conectar um agente a uma API via servidor MCP individual, funciona em escala pequena, mas quebra exatamente nos mesmos pontos em que qualquer arquitetura de microsserviços sem gateway central quebra. Ownership difuso, autorização inconsistente, nenhuma visibilidade central sobre quem acessa o quê.

Para times que estão hoje conectando os primeiros agentes a sistemas internos, a lição replicável não é a escala (poucas empresas vão ter 800 servidores MCP), mas o princípio: separar o plano de controle (o que existe, quem é dono, o que está habilitado) do plano de execução (como a chamada realmente acontece) desde o início evita reescrever tudo quando o número de integrações passar de dezenas para centenas.

O que ainda fica em aberto, e o InfoQ não detalha, é como a Uber mede o custo operacional de manter o AutoCrawler e o Omni MCP rodando sobre um catálogo que só cresce, nem que métricas de observabilidade o time usa para decidir quando uma ferramenta vira risco em vez de utilidade.

Fonte: InfoQ