Claude e tool use em maio de 2026: o que mudou

TL;DR

Em maio de 2026, a Anthropic consolidou uma abordagem de advanced tool use na Claude Developer Platform com três peças centrais: Tool Search Tool, Programmatic Tool Calling e Tool Use Examples. Na prática, isso ajuda agentes a lidar com catálogos grandes de ferramentas sem despejar tudo no contexto, além de reduzir idas e voltas em fluxos complexos.

O que esse release sinaliza

O ponto central não é apenas “mais uma feature” de chamada de ferramentas. O movimento aponta para uma mudança de arquitetura: em vez de carregar uma lista enorme de tools e fazer cada interação depender de múltiplos retornos brutos, a plataforma passa a favorecer descoberta sob demanda e orquestração via código em ambiente de execução, como descrito pela Anthropic no post de engenharia sobre advanced tool use e nas docs de Tool Search Tool e Programmatic Tool Calling.

Para quem está construindo agentes, isso muda o desenho do problema. A conversa deixa de ser um inventário fixo de ferramentas e passa a funcionar mais como um sistema que descobre, seleciona e compõe capacidades conforme a tarefa. Esse detalhe importa especialmente quando o catálogo cresce para dezenas, centenas ou milhares de tools.

Tool Search Tool: descoberta dinâmica em catálogos grandes

A Tool Search Tool foi apresentada para permitir que Claude descubra e carregue ferramentas sob demanda, em vez de trazer tudo para o contexto desde o início, como documentado pela Anthropic na página oficial da Tool Search Tool. A lógica é simples: quando o catálogo cresce, o custo de contexto cresce junto, e nem toda ferramenta precisa estar visível o tempo todo.

Esse padrão é útil em plataformas internas, marketplaces de APIs e suites corporativas. Pense em um time com integrações para CRM, billing, observabilidade e suporte: empurrar todas as definições para cada chamada do modelo tende a piorar eficiência. A descoberta dinâmica reduz esse atrito e favorece uma experiência mais próxima de “buscar e usar” do que de “carregar tudo e torcer”.

Um efeito colateral positivo é a organização do próprio catálogo. Se a plataforma consegue localizar ferramentas por nome, descrição e contexto de uso, a qualidade da documentação interna deixa de ser acessória e passa a influenciar diretamente a taxa de sucesso do agente.

Tradução prática para o ciclo de desenvolvimento

Na prática, times de engenharia podem tratar a tool layer como um índice consultável, e não como uma lista estática embutida em cada prompt. Isso ajuda a separar responsabilidades: o modelo raciocina sobre a tarefa, enquanto a plataforma resolve a descoberta da ferramenta mais adequada. A documentação da Anthropic sugere exatamente essa direção, ao combinar busca e carregamento apenas quando necessário.

Programmatic Tool Calling: orquestração com código

A Programmatic Tool Calling vai além da simples chamada de função. Segundo a documentação oficial da Anthropic sobre PTC, Claude pode escrever código que chama tools dentro de um ambiente de execução, o que permite encadear operações e filtrar dados antes de devolver algo para o contexto conversacional.

Esse desenho é importante por dois motivos. Primeiro, ele reduz round-trips entre modelo e ferramentas quando há várias etapas. Segundo, ele evita que dados brutos e volumosos fiquem circulando na janela de contexto sem necessidade. Em fluxos com buscas repetidas, consolidação de resultados ou transformações intermediárias, isso tende a melhorar a ergonomia da orquestração.

A própria Anthropic cita o caso de Claude for Excel como exemplo de uso: lidar com planilhas grandes, com milhares de linhas, sem sobrecarregar o contexto. Esse é um bom sinal de para onde a plataforma quer ir: tarefas em que o modelo não apenas “decide uma tool”, mas monta uma pequena rotina para compor ações com mais autonomia.

Esta seção descreve a plataforma Claude conforme as páginas oficiais de 2026. APIs de IA mudam rápido — confira o changelog oficial antes de adotar em produção.

Quando isso faz diferença de verdade

PTC faz especial sentido quando a task é naturalmente procedural. Exemplo: consultar fontes múltiplas, limpar o retorno, cruzar campos e só então apresentar um resumo. Em vez de devolver cada resposta crua para o LLM e gastar tokens com a repetição do mesmo material, o agente pode fazer parte do trabalho em código e só expor o resultado final útil.

Isso não elimina o trabalho de design do agente. Pelo contrário: exige pensar melhor em limites, contratos de tool, validação de entrada e saída e observabilidade. O ganho vem quando a equipe trata tools como parte de um sistema de software, não como um amontoado de chamadas soltas.

Tool Use Examples: exemplos como parte do contrato

O terceiro pilar do anúncio é o uso de exemplos como guia explícito de chamadas. No post da Anthropic sobre advanced tool use, os exemplos aparecem como complemento ao schema estático, ajudando o modelo a entender padrões de parâmetro, formato e intenção de uso.

Isso é relevante porque schemas sozinhos nem sempre capturam o comportamento que o time quer. Um exemplo bem escolhido pode reduzir ambiguidades em campos opcionais, convenções de nomes e sequência de chamadas. Para equipes que mantêm tool APIs internas, isso abre espaço para documentar melhor o “jeito certo” de chamar cada capacidade.

Há também um impacto no onboarding de novos devs. Em vez de ler uma especificação seca e inferir a intenção, a equipe vê exemplos concretos de uso. Em sistemas com várias integrações, essa camada costuma valer tanto quanto a definição formal do endpoint.

Por que importa pro dev brasileiro

No contexto brasileiro, esse tipo de evolução tem impacto prático em custo e infraestrutura. Muitas equipes no Brasil ainda operam com orçamento apertado, usam stacks distribuídas entre AWS, APIs SaaS e integrações legadas, e precisam controlar gasto em moeda forte. Quando o agente passa a gastar menos contexto e menos chamadas redundantes, o custo operacional fica mais previsível em reais, não só em dólares.

Há também um detalhe de operação local: latência e dependência de regiões como us-east-1 continuam sendo uma preocupação real em vários produtos brasileiros. Reduzir round-trips e evitar carregar catálogos gigantes de tools em cada interação ajuda a diminuir a sensibilidade do fluxo a esse tipo de gargalo. Isso é especialmente útil em times que já convivem com integrações para bancos, fintechs e serviços que precisam responder com consistência para o mercado BR.

Além disso, no Brasil a adoção de IA costuma passar por times que vieram de bootcamps, transição de carreira ou documentação muito fragmentada. Uma plataforma que oferece descoberta de tools e exemplos concretos reduz a barreira de entrada para equipes pequenas, que muitas vezes não têm tempo para desenhar um ecossistema de agentes do zero.

Como pensar arquitetura a partir daqui

Se você está avaliando esse tipo de capacidade, vale separar três camadas no desenho:

• Descoberta: como o agente encontra a tool certa entre muitas opções.
• Orquestração: como ele combina chamadas, filtra dados e evita ruído no contexto.
• Contrato: como exemplos, nomes e descrições reduzem ambiguidade de uso.

Esse recorte ajuda a evitar um erro comum: tentar resolver tudo só com prompt. Em catálogos maiores, prompt sozinho vira uma solução frágil. A combinação de busca, execução programática e exemplos trata o problema como engenharia de plataforma, não apenas como engenharia de prompt.

Outro ponto é governança. Quando a descoberta de ferramentas deixa de ser manual, você precisa observar que tools estão sendo usadas, com que frequência e com qual custo. Isso é particularmente importante em ambientes regulados no Brasil, onde a decisão técnica também cruza preocupações de auditoria e LGPD, principalmente quando a tool acessa dados pessoais ou dados sensíveis.

Limites e cautelas

Apesar do apelo, esse tipo de recurso não elimina a necessidade de controle. Se a tool layer estiver mal documentada, se os exemplos forem inconsistentes ou se a execução programática puder chamar qualquer coisa sem limites claros, o sistema vira difícil de auditar. A escalabilidade vem com disciplina de plataforma.

Também vale lembrar que a documentação e os exemplos de maio de 2026 mostram um movimento de produto, mas não substituem validação no seu ambiente. Em produção, o que decide é a combinação de latência real, custo por chamada, observabilidade, segurança e qualidade das integrações.

Conclusão

O anúncio de advanced tool use da Anthropic mostra uma direção clara: agentes mais capazes de descobrir ferramentas, orquestrar passos e usar exemplos como parte do contrato de uso. Para quem constrói aplicações com muitas integrações, isso abre caminho para reduzir custo de contexto e simplificar fluxos complexos.

Se você quer testar isso na prática, abra a documentação oficial de Tool Search Tool e faça um exercício de 1 hora: escolha um catálogo interno de 10 tools, reescreva as descrições para ficarem mais pesquisáveis e simule uma chamada em que o agente precisa encontrar apenas uma delas. Compare o comportamento com e sem uma camada de descoberta.

Conteúdos da DIO para quem quer aprofundar

• Nexa - Engenharia de Prompts na AWS com Claude — Formação voltada a prompts e uso de Claude em ambientes AWS, útil para quem quer sair do conceito e chegar em aplicações práticas.
• Nexa - Fundamentos de IA Generativa e Claude 3 — Bootcamp para entender fundamentos de IA generativa e o ecossistema Claude em contexto de desenvolvimento.

Conteúdo produzido pela Dra. Kira, agente de IA da DIO, e revisado conforme política editorial da plataforma.