Sobrecarga de Ferramentas Tem Imposto: Quando 50 MCPs Comem 7% do Contexto

A maioria dos times de plataforma não consegue responder, em cinco segundos, quantas ferramentas o agente em produção realmente tem registradas. Conseguem responder o headcount do time. Conseguem responder a conta da nuvem. Não conseguem responder a contagem de ferramentas.

Essa resposta importa mais do que parece. O time de engenharia da LeanIX publicou na semana passada uma medição que transforma a pergunta de descuidada em quantitativa: a partir de cinquenta ferramentas MCP registradas em um agente, os schemas das ferramentas — nomes, descrições, formatos de parâmetro — consomem entre cinco e sete por cento da janela de contexto do modelo antes que o usuário tenha digitado um único caractere. Toda requisição paga o imposto. Toda etapa de todo workflow paga o imposto. Ninguém colocou no orçamento.

Essa é a parte barata do problema.

O Imposto Que Ninguém Orçou

Quando você registra uma ferramenta em um agente compatível com MCP, três artefatos entram no prompt do modelo a cada decisão: o nome da ferramenta, sua descrição em linguagem natural e o schema completo de parâmetros. Com uma ferramenta, é invisível. Com dez, é arredondamento. Com cinquenta, é mensurável no percentual da janela de contexto que sumiu antes do agente ver a pergunta do usuário.

Cinco a sete por cento não é catástrofe em isolamento. É catástrofe no acúmulo. O mesmo agente tem prompts de sistema, documentos recuperados, turnos anteriores, raciocínio em rascunho e a mensagem real do usuário disputando a mesma janela. Cada ponto percentual entregue a schemas de ferramentas é um ponto percentual subtraído do trabalho. Conversas longas degradam mais rápido. A recuperação é cortada com mais agressividade. O agente perde contexto antigo para abrir espaço para a pergunta que está tentando responder.

Mas o imposto de schema é o problema contábil. O problema de comportamento é pior.

O Imposto de Alucinação Por Baixo

Ferramentas semanticamente similares — update_user, update_user_record, update_user_profile — confundem o modelo de maneiras que não aparecem em nenhum trace isolado. O agente inventa um quarto nome de ferramenta que não existe. Invoca a ferramenta certa com parâmetros emprestados do schema de outra. Mistura dois nomes de parâmetro que significam coisas diferentes. A taxa de erro sobe à medida que a superfície cresce, e sobe de forma não linear. Você não tem aumento de 50% na contagem de ferramentas com 50% de aumento em erros. Tem 50% de aumento na contagem de ferramentas com mudança de regime na forma como o agente raciocina sobre qual ferramenta chamar.

O imposto de schema é recuperável: pode-se podar ferramentas, recuperar tokens. O imposto de alucinação é estrutural: só diminui quando a superfície diminui, e é mais difícil de detectar nos workflows que funcionavam ontem e silenciosamente pararam de funcionar hoje.

O diagnóstico do autor merece ser absorvido: independentemente do padrão arquitetural, ainda é necessário manter um número razoável de ferramentas. Sobrecarga de ferramentas é a doença; tudo abaixo é tratamento.

Code Mode Como Um Tratamento

O padrão da Cloudflare, que o post da LeanIX descreve em detalhe, trata o imposto de schema e o imposto de alucinação como a mesma doença. Em vez de registrar cinquenta ferramentas, você busca o schema do servidor MCP upstream, gera um SDK em TypeScript a partir dele com comentários de documentação e expõe exatamente duas ferramentas ao modelo: uma para buscar no SDK, outra para executar código gerado em um sandbox.

A mecânica merece ser entendida com precisão:

Busca. O SDK vem com um índice vetorial sobre seus endpoints, tipos e exemplos. O modelo emite uma consulta em linguagem natural — “encontre a função que atualiza o endereço de cobrança de um usuário” — e recebe um conjunto pequeno de fragmentos relevantes do SDK. Somente esses fragmentos entram na janela de contexto. O schema de cinquenta ferramentas deixa de estar lá tributando cada requisição.
Execução. O modelo escreve uma função JavaScript assíncrona que usa os fragmentos de SDK que encontrou, e o agente a executa dentro de um isolate Dynamic Worker da Cloudflare. Loops, condicionais, batches, tratamento de erro — tudo colapsa em um programa gerado e uma chamada de execução. Workflows multietapa que antes exigiam dez round-trips de “modelo escolhe ferramenta, ferramenta retorna, modelo escolhe a próxima” passam a ser um round-trip de “modelo escreve programa, sandbox executa programa, modelo lê resultado”.

A matemática de tokens melhora duas vezes. O imposto de schema cai para duas ferramentas em vez de cinquenta. O imposto de conversa cai porque os workflows comprimem. O problema de alucinação encolhe porque o modelo não está mais escolhendo entre quarenta e oito nomes quase idênticos de ferramentas; está escrevendo código contra assinaturas de função tipadas com comentários de documentação ao lado.

Esse é o mesmo movimento arquitetural que catalogamos em ensaios adjacentes: o runtime do agente está virando uma superfície de syscalls em que a governança vive na fronteira entre modelo e execução, não em cada ferramenta individual. Code Mode é uma expressão desse movimento. O sandbox não é infraestrutura opcional; é o substrato que permite a fronteira existir.

Quando Code Mode É a Resposta Errada

Code Mode não é grátis. A matriz de decisão que o post da LeanIX oferece é a certa para manter à mão:

Use Code Mode quando o agente está registrado contra cinquenta ou mais ferramentas com padrões repetitivos de chamada, quando os workflows pedem loops, condicionais e batching, quando o número de round-trips é o gargalo, e quando você já tem infraestrutura de sandbox em produção. A parte do sandbox não é negociável. Se você está executando JavaScript que o modelo escreveu, está executando dentro de um isolate com limites de recurso estritos e sem acesso de rede por padrão. Um sandbox levantado apenas para Code Mode é um sandbox que você não endureceu.

Fique no MCP tradicional quando transparência de depuração importa mais que eficiência de tokens — toda chamada de ferramenta é uma linha de log que um humano consegue ler, enquanto Code Mode produz uma execução de programa que é mais difícil de inspecionar passo a passo. Fique no MCP quando operações de chamada única dominam; não é preciso um gerador de código para chamar uma função. Fique no MCP quando não puder rodar um sandbox de execução de código; a alternativa é insegura. E fique no MCP quando interoperabilidade com outros agentes compatíveis com MCP importa mais que eficiência por agente.

Existe um terceiro caminho que o post não nomeia explicitamente, mas que decorre de seu argumento: fique no MCP e pode. Corte a superfície de ferramentas. Filtre no lado do agente conforme a tarefa. Redesenhe no lado do servidor em torno de casos de uso em vez de espelhar APIs upstream um para um. O ponto do autor — de que ainda é necessário manter um número razoável de ferramentas — sobrevive a toda escolha arquitetural. Code Mode é uma forma de absorver o custo de ter muitas ferramentas. Reduzir a contagem é outra, e não exige sandbox.

A Pergunta Por Trás da Arquitetura

Sobrecarga de ferramentas é um problema quantificável de governança vestido de detalhe técnico. O número de cinco a sete por cento é útil porque torna a conversa orçável. Dá para entrar na reunião de plataforma e perguntar se os agentes estão pagando esse imposto, e dá para tomar decisões com a resposta.

Mas a pergunta mais profunda é a que a maioria dos times não consegue responder em cinco segundos: quantas ferramentas o agente em produção realmente tem registradas? Quem adicionou as três últimas? Quando foi a última auditoria da superfície? Se essas perguntas levam uma hora para responder, a fronteira já foi perdida, e o imposto de schema é o sintoma de que a fronteira está faltando — não a causa.

Code Mode é uma forma de retomar a fronteira. Podar é outra. Desenhar ferramentas em torno de casos de uso em vez de APIs upstream é uma terceira. As arquiteturas diferem; a disciplina não. Se a superfície de ferramentas do seu agente é governável, observável e limitada é uma pergunta com resposta de sim ou não. Cinco a sete por cento da janela de contexto é o que “não” custa em cada requisição, antes mesmo da conversa sobre chamadas alucinadas começar.

Se o seu time de plataforma não consegue responder “quantas ferramentas nosso agente tem?” em cinco segundos, esse é o trabalho. A arquitetura vem depois.

Fontes

Why Your AI Agent Is Drowning in Tools (and How Code Mode Saves It) — LeanIX Engineering, abril de 2026.

A Victorino ajuda times de engenharia a auditar e limitar a superfície de ferramentas do agente antes que ela consuma a janela de contexto: contato@victorino.com.br | www.victorino.com.br