O gateway MCP da Uber separa descoberta de ferramentas e autorização
Catálogo, revisão e descoberta sob demanda: o desenho da Uber oferece lições para integrar agentes sem liberar todas as APIs.
A Uber construiu um MCP Gateway para organizar ferramentas distribuídas por mais de 800 servidores MCP, reaproveitando APIs existentes em vez de exigir sua reescrita.[2] Segundo a InfoQ, a iniciativa responde à duplicação de infraestrutura, à fragmentação das integrações e à inconsistência de controles de segurança.[2]
A leitura técnica mais útil não é copiar a escala. É perceber que encontrar uma ferramenta, descrevê-la para o modelo e permitir sua execução são decisões diferentes.
O que muda para quem desenvolve
O desenho separa um MCP Registry, com definições, esquemas, responsáveis e estado de habilitação, de um Proxy Gateway que traduz chamadas MCP para HTTP, gRPC ou TChannel.[2] As configurações chegam ao plano de execução sem reiniciar ou reimplantar os serviços.[2]
O AutoCrawler descobre interfaces internas e produz esquemas e descrições, mas novas ferramentas permanecem desabilitadas até revisão e habilitação explícita pela equipe responsável.[2] Esse detalhe vale mais que uma demonstração com milhares de operações. A proposta preserva uma fronteira entre documentação encontrada e capacidade autorizada.
Para quem projeta integrações, recomendo explicitar essa fronteira no modelo de dados: ferramenta descoberta, revisada, habilitada e revogada não deveriam ser o mesmo estado com nomes diferentes.
Como aplicar
Comece com um catálogo pequeno. Escolha uma consulta e uma operação de escrita de baixo risco, cada uma com responsável, contrato de entrada, campos de saída e política de acesso. Mantenha a autenticação e a autorização fora da escolha textual do modelo.
A Uber aplica autorização por servidor e por ferramenta, e pode remover dados sensíveis das respostas.[2] O Omni MCP também usa descoberta incremental e recuperação seletiva de esquemas, enquanto Response Projection permite solicitar apenas campos necessários.[2]
Um experimento proposto é apresentar ao agente uma tarefa que exija apenas consulta. Observe quais definições ele precisa carregar e registre o volume das respostas. Depois, tente executar a operação de escrita com uma identidade sem permissão. O critério de aceite deve ser uma negativa efetiva na camada de execução, mesmo que o modelo solicite a operação corretamente. Não é um resultado medido aqui, mas um teste reproduzível para a sua implementação.
Cuidados e limites
Centralizar não elimina decisões de segurança. Minha análise é que um catálogo compartilhado também exige responsabilidade por contratos desatualizados, revogações e falhas de disponibilidade. Evite fazer do gateway uma credencial universal.
Descrições geradas com auxílio de LLM fazem parte do AutoCrawler relatado.[2] Trate-as como material a revisar, não como prova do comportamento da API. O objetivo deve ser dar ao agente a menor capacidade suficiente para a tarefa, não transformar cada endpoint encontrado em uma nova permissão.
Fonte
[2] Fonte: InfoQ