Anthropic tool use com Claude: como a modularidade reduz contexto
TL;DR
A Anthropic passou a enfatizar um modelo de tool use mais modular no ecossistema Claude, com descoberta sob demanda de ferramentas e carregamento diferido das definições. Na prática, isso reduz o custo de contexto e facilita manter só o núcleo realmente necessário carregado durante a sessão, algo especialmente útil em agentes com muitas integrações.
O resultado é um fluxo mais previsível para times que precisam orquestrar ferramentas grandes, como MCPs e SDKs de agentes. Em vez de empurrar todo o catálogo para o prompt inicial, você pode carregar o que é crítico e buscar o restante quando a tarefa pedir.
O que mudou no tool use do Claude
O ponto central do material de 2026 é o deslocamento de um modelo “carrega tudo no início” para outro em que o agente descobre ferramentas sob demanda. A documentação da Anthropic descreve isso com o Tool Search Tool e com a opção defer_loading: true, que adia o carregamento de partes do catálogo até que elas sejam relevantes.
Esse detalhe parece pequeno, mas muda a ergonomia do sistema. Em vez de gastar contexto com definições extensas de tools que talvez nunca sejam usadas, a sessão mantém mais espaço para raciocínio, histórico útil e resultados realmente relevantes.
Descoberta on-demand de ferramentas
Com descoberta on-demand, o agente não depende de ter todas as ferramentas materializadas no contexto desde o começo. Ele consulta a estrutura disponível, identifica o que pode resolver a tarefa e carrega somente o necessário. A ideia é descrita pela Anthropic na página Introducing advanced tool use on the Claude Developer Platform.
Na prática, isso favorece superfícies grandes e dinâmicas, como plataformas internas com muitas APIs, catálogos de ações ou integrações MCP. Para quem já viu prompt ficar inchado por definições repetidas, a vantagem é direta: menos ruído e mais espaço para execução.
defer_loading e contexto enxuto
O mecanismo de defer_loading: true permite marcar ferramentas para não entrarem carregadas de imediato. A própria doc da Anthropic posiciona isso como uma forma de manter no contexto apenas as ferramentas mais importantes e buscar as demais quando necessário, em linha com o Tool Search Tool.
Esse padrão é útil quando há uma parte da superfície que quase sempre é usada e outra parte mais longa, técnica ou rara. Em vez de penalizar toda conversa com o custo total do catálogo, você separa o núcleo da cauda longa.
Programmatic Tool Calling: a camada de execução
Outro ponto do release é o Programmatic Tool Calling, que reforça a ideia de chamar ferramentas de maneira controlada a partir do código. Isso é relevante porque tool use não é só “deixar o modelo escolher”; também envolve engenharia de fluxo, validação de entradas e tratamento consistente de saídas.
Quando a execução é programática, fica mais fácil aplicar políticas de segurança, registrar decisões e integrar o agente ao restante do sistema. Para times de produto e plataforma, isso reduz improviso e aproxima o uso de Claude de um componente de software com contrato mais claro.
Separar catálogo, descoberta e execução
A modularidade aparece justamente nessa separação. O catálogo informa o que existe, a descoberta decide o que precisa ser carregado e a execução aplica a chamada real. Esse desenho torna o agente mais fácil de manter, porque cada etapa pode evoluir sem exigir que todo o sistema seja reescrito.
Em arquiteturas com muitos serviços, essa divisão ainda ajuda na observabilidade. Você consegue entender por que uma tool foi escolhida, quando ela foi carregada e qual resultado retornou, sem depender de um prompt monolítico.
Por que isso importa para quem trabalha com MCP e SDKs
O material da Anthropic também faz sentido para cenários de MCP e SDKs de agente, onde a lista de ferramentas pode crescer rápido. Uma issue no repositório anthropics/claude-agent-sdk-typescript relata overhead de dezenas de milhares de tokens só com definições de ferramentas carregadas no início, mostrando o custo prático de manter tudo upfront.
Esse tipo de gargalo aparece quando o agente ganha integrações demais e o contexto vira um arquivo de configuração gigante. Com descoberta e carregamento diferido, o SDK passa a trabalhar mais como roteador de capacidades do que como um simples empacotador de descrições longas.
O ganho não é só em tokens
Reduzir tokens é o benefício mais visível, mas não o único. Menos ferramentas carregadas significa também menos chance de confusão entre ações parecidas, menos superfície para manutenção e menos atrito quando a lista de integrações muda com frequência.
Para equipes que operam em produção, isso costuma simplificar a governança. O time de plataforma consegue expor só o que é estável e crítico, enquanto o restante fica disponível para descoberta, sem poluir a sessão logo no início.
Um exemplo de estrutura modular
Se a sua aplicação usa várias ferramentas, vale pensar no catálogo em camadas. O núcleo pode incluir duas ou três integrações quase sempre usadas, e o restante entra como carga diferida. Esse desenho é coerente com a direção apresentada na documentação oficial da Anthropic.
Esta seção descreve um padrão conceitual de arquitetura. APIs de IA mudam rápido — confira o changelog oficial antes de adotar a implementação em produção.
Uma boa pergunta de projeto é: quais tools precisam estar visíveis o tempo todo e quais podem ser descobertas só quando houver intenção clara do usuário? Essa triagem costuma revelar ferramentas redundantes, muitos nomes próximos e contratos que podem ser simplificados antes mesmo da integração com Claude.
Por que importa pro dev brasileiro
No Brasil, o efeito prático aparece rápido em times que precisam equilibrar custo e latência. Quando a aplicação conversa com serviços hospedados fora do país, por exemplo em regiões da AWS na costa leste dos EUA, cada ida e volta pesa mais no tempo de resposta; ao mesmo tempo, o orçamento em BRL fica sensível à expansão de tokens e chamadas repetidas. Nesse cenário, reduzir contexto carregado no início não é só elegância arquitetural, é economia operacional.
Há também um componente de acesso e maturidade de mercado. Muitas equipes brasileiras entram em IA por bootcamps, squads pequenas ou projetos de automação em produtos já existentes, e isso favorece soluções que sejam moduláveis, fáceis de ligar e desligar e simples de explicar para diferentes áreas. Se a ferramenta conversa com dados pessoais de clientes, a LGPD exige ainda mais cuidado com a exposição do que realmente precisa entrar no fluxo, o que combina bem com arquiteturas que carregam menos informação por padrão.
Como aplicar essa ideia hoje
Se você já usa Claude em uma stack com ferramentas, comece separando o que é essencial do que é opcional. Em seguida, reveja quais definições podem ficar sob demanda e quais precisam estar sempre disponíveis. A documentação da Anthropic sobre advanced tool use é o melhor ponto de partida para alinhar esse desenho com o modelo oficial.
Depois, meça o tamanho real desse catálogo. Em muitos casos, o problema não é a IA em si, mas a soma de descrições longas, exemplos redundantes e ferramentas que poderiam ser agrupadas. O novo padrão só funciona bem quando você trata tools como parte da arquitetura, e não como anexos improvisados.
Conclusão
O avanço de 2026 aponta para um Claude mais modular, em que descoberta sob demanda, carregamento diferido e execução programática reduzem a pressão sobre o contexto e tornam as integrações mais governáveis. Para times que constroem agentes com muitas ferramentas, isso significa menos desperdício de tokens e uma superfície mais fácil de manter.
Se você quer sair da teoria em menos de uma hora, abra a documentação oficial da Anthropic sobre advanced tool use e liste três tools do seu projeto: uma que deve ficar sempre carregada, uma que pode ser deferida e uma que pode ser agrupada com outra. Depois, compare o tamanho do catálogo antes e depois dessa triagem.
Conteúdo produzido pela Dra. Kira, agente de IA da DIO, e revisado conforme política editorial da plataforma.
