Como o Uber MCP Gateway funciona na prática?

A ideia contraintuitiva do Uber MCP Gateway é simples: o agente não deveria conhecer o catálogo inteiro. Ele deve saber encontrá-lo. Quatro metaferramentas substituem a lista global por uma busca em etapas, e o contexto passa a conter apenas o que a tarefa atual exige.

Uber MCP Gateway: por que o MCP padrão estoura o contexto

O Uber MCP Gateway existe porque o fluxo padrão do MCP não escala: em um protocolo MCP (Model Context Protocol, o padrão aberto para agentes chamarem ferramentas), o cliente lista todas as ferramentas antes de usar qualquer uma. Cada definição traz nome, descrição e um JSON schema com os campos aceitos. Tudo isso entra no contexto, que é o texto que o modelo consegue ler de uma vez.

A Uber relata mais de 5.000 ferramentas em mais de 800 servidores MCP. Configurar centenas de servidores à mão e derramar o catálogo inteiro no contexto é inviável nesse porte, segundo o post de engenharia da Uber. A versão do protocolo publicada em 25 de novembro de 2025 mantém esse fluxo: listar, o modelo escolhe, o cliente chama.

Há um segundo problema além do volume. O MCP não tem busca entre servidores: o agente precisa saber antecipadamente com qual servidor falar antes de perguntar quais ferramentas existem. Sem um intermediário, o agente começa a tarefa já cego e com o contexto quase cheio.

Omni MCP: quatro metaferramentas de disclosure progressiva

O Omni MCP é um servidor proxy entre o agente e os demais servidores, e ele expõe apenas quatro metaferramentas. Uma metaferramenta é uma ferramenta para encontrar e chamar outras ferramentas. O agente nunca vê a lista completa de definições; só o que ele pede entra no contexto.

A sequência reduz as escolhas a cada passo. Primeiro o agente escolhe um servidor, depois uma ferramenta dentro dele, depois preenche argumentos. Essa leitura de encadeamento é interpretação editorial sobre o design, não redação literal da Uber.

Metaferramenta	O que faz	O que entra no contexto
discover_server	Encontra um servidor por intenção	Um servidor correspondente
discover_tools	Lista as ferramentas daquele servidor	Descrições curtas daquele servidor
get_tool_schema	Busca o JSON schema de uma ferramenta	Um único schema
invoke_tool	Executa a chamada com os argumentos	O resultado da chamada

Em uma tarefa como consultar o status de uma entrega, o agente mantém no contexto um servidor, uma lista de ferramentas, um schema e um resultado. As demais 5.000+ ferramentas ficam de fora. Os nomes de servidor, ferramenta e campos usados como exemplo no post são ilustrativos, e o post não explica como o discover_server ordena os resultados, se por palavras-chave ou por comparação semântica com modelo.

AutoCrawler: como o catálogo de ferramentas é construído

O catálogo chega ao gateway por dois caminhos, segundo o post da Uber. Servidores MCP nativos são consultados com o listing padrão de ferramentas. Serviços internos sem MCP são varridos pelo AutoCrawler, que lê arquivos de definição de interface em Protobuf e Thrift IDL.

Um LLM escreve descrições amigáveis para agentes das ferramentas encontradas. A qualidade dessas descrições faz parte do design: uma descrição ruim pode mandar o agente para a ferramenta errada na etapa de escolha.

Nada entra ativo por padrão. Cada ferramenta é registrada desabilitada, e a frase da Uber é direta: todo servidor e ferramenta MCP começa desabilitado e precisa ser revisado e habilitado explicitamente pela equipe responsável. O post cita apenas a revisão do dono como verificação; checagens de permissão são um mecanismo separado.

Gateway de dados: tradução de protocolos e checagem de permissões

A arquitetura separa controle e execução. O registro é o plano de controle e guarda o catálogo de ferramentas; o gateway é o plano de dados e conduz as chamadas. O post não detalha como essas duas peças se relacionam com o Omni MCP.

O gateway traduz uma chamada MCP para um de três protocolos: HTTP, gRPC ou TChannel, o protocolo RPC de código aberto da Uber. A execução é delegada ao Muttley, um sidecar de service mesh descrito no mesmo post, um processo auxiliar que roda ao lado do serviço. O agente fala MCP; os serviços recebem seus protocolos nativos.

As permissões usam o sistema interno de controle de acesso da Uber, com políticas definidas por servidor e possibilidade de override por ferramenta. O gateway detecta se quem chama é humano, serviço ou agente, e a mesma ferramenta pode ter regras diferentes para cada tipo de chamador. Autorização e redação de PII (dados pessoais) valem por ferramenta.

A checagem acontece no caminho da requisição, entre o agente e o serviço. O post não diz se a descoberta ou a busca de schema também verificam permissões, nem se o discover_tools filtra por permissão do chamador ou por ferramenta habilitada. Se você for implementar algo parecido, filtrar por ambos evita que o agente escolha uma ferramenta que não pode chamar; essa recomendação é inferência editorial.

Respostas grandes: projeção de resposta e Claude Code

Descoberta reduz o que entra no contexto antes da chamada; respostas grandes são outro problema. A primeira resposta da Uber é a projeção de resposta em tempo de execução: o agente pede apenas os campos que precisa, e o gateway remove os demais antes de o modelo ler. Na consulta de pedido, o agente pede só o campo de status, não o registro completo.

A segunda resposta vale para agentes de shell, como o Claude Code, a ferramenta de codificação agêntica da Anthropic que roda no terminal. Esses agentes chamam ferramentas MCP por uma CLI chamada AIFX, com comandos list, search e call. O agente escreve a saída em arquivos, usa grep para localizar o trecho e carrega no contexto só o trecho.

Há um limite declarado: a Uber descreve arquivos apenas para o Claude Code. O post não explica como o Omni MCP trata resultados grandes para outros clientes, se corta, limita tamanho ou grava em disco. Como o agente declara os campos desejados na projeção também não está especificado.

Quanto economiza? O que a evidência sustenta

A Uber não publicou economia medida de tokens, latência nem percentual para o gateway. Qualquer número de economia atribuído ao sistema da Uber seria chute, então este artigo não apresenta nenhum.

A Anthropic publicou em 4 de novembro de 2025 um exemplo com ideia semelhante: carregar definições de ferramentas sob demanda e filtrar resultados em código antes de o modelo ver. O exemplo reduz de 150.000 para 2.000 tokens, uma economia de 98,7%. É o resultado de um exemplo de outro sistema; não mede o gateway da Uber e não diz nada sobre os resultados dela.

A decisão prática depende da sua escala. Se você roda um servidor com poucas ferramentas, mantenha o listing padrão, porque quatro passos significam mais chamadas; esse custo extra é inferência, não afirmação da Uber. Se você opera muitos servidores, meça quantos tokens sua lista de ferramentas consome antes da primeira tarefa e compare com o tamanho do contexto do seu modelo.

FAQ sobre o Uber MCP Gateway

• O que é o Omni MCP? É o servidor proxy da Uber que fica entre o agente e os demais servidores MCP. Ele expõe quatro metaferramentas de descoberta e invocação, para que o agente carregue apenas o schema de que precisa em vez do catálogo completo.

• Quais são as quatro metaferramentas do Omni MCP? discover_server, discover_tools, get_tool_schema e invoke_tool. Em ordem, elas encontram um servidor por intenção, listam as ferramentas daquele servidor, buscam o JSON schema de uma ferramenta e executam a chamada.

• O Uber MCP Gateway economiza tokens? A Uber não publicou números medidos de economia de tokens, latência ou percentual. O único número público próximo vem de um exemplo da Anthropic novembro de 2025, que cortou 150.000 para 2.000 tokens em outro sistema.

• Como as permissões funcionam no gateway? O gateway aplica políticas do sistema interno de controle de acesso no caminho da requisição, com regras por servidor e override por ferramenta. Ele distingue chamador humano, serviço e agente, e aplica redação de PII por ferramenta.

• Vale usar disclosure progressiva com poucos servidores? Provavelmente não. Com poucas ferramentas, o fluxo padrão é mais direto, e a sequência de quatro passos adiciona chamadas. O ganho aparece quando o catálogo inteiro não cabe ou sobrecarrega o contexto.

Source video