Claude tool use em 2026: o que mudou para agentes

TL;DR

Em 2026, o avanço mais importante no tool use do Claude não foi “mais uma função de chamada”, e sim a combinação de descoberta on-demand de ferramentas, execução de código para filtrar e orquestrar chamadas, e contratos mais estritos para reduzir erro de formato. Na prática, isso muda a engenharia do agente: menos schemas gigantes no contexto, mais seleção dinâmica do que realmente será usado.

Para quem constrói agentes, o impacto é direto em custo, robustez e segurança. Em vez de empilhar ferramentas, o desenho passa a priorizar descoberta, contenção e execução incremental — um formato que conversa bem com MCP e com integrações corporativas comuns no Brasil.

O que mudou na camada de ferramentas

O ponto central é a passagem de um modelo “defini tudo antes” para um modelo de descoberta sob demanda. A documentação da Anthropic descreve o Tool Search Tool como mecanismo para localizar e carregar apenas o subconjunto relevante de ferramentas, em vez de despejar catálogos enormes no contexto. Isso reduz o custo de prompt e melhora a chance de o agente escolher a tool certa no momento certo.

Esse movimento importa porque a superfície de ferramentas cresceu muito em aplicações reais: CRM, banco de dados, busca interna, web search, código, filas, observabilidade. Quando tudo entra de uma vez, o agente passa a gastar tokens lendo o que talvez nunca use. Com descoberta on-demand, a seleção vira parte do fluxo de execução.

Tool Search para catálogos grandes

Na prática, o Tool Search resolve um problema comum em times que integram dezenas ou centenas de operações internas. Em vez de registrar cada schema na primeira mensagem, o agente pergunta o que existe e só então carrega a ferramenta adequada. A documentação oficial descreve essa abordagem para reduzir inflação de contexto e manter o planejamento mais focado: Tool Search Tool.

Esse desenho combina bem com ambientes corporativos em que cada área expõe um conjunto próprio de ações. Um agente de suporte, por exemplo, não precisa ver APIs de faturamento se a conversa for sobre senha expirada. O valor está em carregar menos, decidir melhor e agir com mais precisão.

Strict tool use e previsibilidade de contrato

Outra mudança relevante é o Strict tool use, que força conformidade maior entre o que o modelo tenta enviar e o contrato esperado pela ferramenta. Isso é útil quando pequenas variações de formato quebram integrações sensíveis, como parâmetros obrigatórios, enums fechados ou payloads que alimentam sistemas legados.

O ganho aqui não é glamour; é redução de erro operacional. Em um agente que chama APIs de produção, uma chave ausente ou um campo mal tipado custa tempo de retry e aumenta o risco de comportamento inconsistente. Para times que já sofreram com “quase correto”, a estrita validação ajuda a transformar chamadas em algo mais audível e menos frágil.

Execução de código como camada de orquestração

Outro eixo destacado nas fontes é o uso de code execution com MCP para fazer progressão de trabalho sem empurrar tudo para o contexto do modelo. A ideia de progressive disclosure é simples: o agente carrega o necessário em etapas, filtra dados antes de passá-los adiante e reduz o volume de material bruto que chega ao raciocínio principal.

Isso é especialmente útil em fluxos com busca na web, leitura de documentos e enriquecimento de dados. Em vez de retornar páginas inteiras ou coleções enormes de resultados, a execução intermediária pode pré-filtrar, resumir ou classificar antes de entregar o próximo passo ao modelo principal. O resultado tende a ser menor custo e melhor foco.

Web search com filtragem dinâmica

A documentação de Web search tool mostra versões em que a busca pode ser chamada com filtragem dinâmica e, dependendo da configuração, até via code execution por trás. O ponto técnico é separar a ação de buscar da ação de interpretar, o que facilita controle de escopo e reduz a dependência de um contexto inflado.

Para agentes que pesquisam artigos, changelogs, knowledge bases ou documentação interna, isso ajuda a evitar o efeito “capturar demais e usar de menos”. A execução intermediária age como um funil: coleta, filtra, ordena e só depois entrega o que vale a pena ao modelo principal.

MCP continua ganhando papel de infraestrutura

O avanço do ecossistema MCP reforça o desenho modular de agentes. O texto da Anthropic sobre Code execution with MCP mostra como a combinação de carregamento sob demanda e execução progressiva permite trabalhar com ferramentas sem trazer toda a definição para o contexto principal. Isso favorece agentes que precisam conversar com sistemas heterogêneos sem virar um monólito de schemas.

Na prática, MCP vira uma camada de integração que pode ser encaixada em ferramentas internas, bancos de conhecimento e flows de automação. O valor não está só em compatibilidade; está em manter a superfície acionável pequena o suficiente para ser rastreável, versionável e testável.

O efeito no desenho de agentes

Com descoberta, execução e contrato mais estrito, o agente deixa de ser um “falador com ferramentas” e passa a ser uma unidade de orquestração. Isso muda teste, observabilidade e até governança, porque cada chamada pode ser registrada, validada e isolada por etapa. Em ambientes regulados, essa granularidade costuma valer mais do que ganhar algumas linhas de prompt.

Também muda a forma de pensar em memória e seleção. Em vez de confiar que o modelo vai “lembrar” uma tool útil, a arquitetura passa a expor essa tool no momento certo. O agente fica mais parecido com um executor seletivo do que com um catálogo ambulante.

Por que isso importa pro dev brasileiro

No Brasil, esse tipo de mudança pesa por motivos bem concretos. Muitas equipes operam com orçamento em BRL pressionado pelo câmbio, e economizar tokens ou chamadas desnecessárias faz diferença real na conta mensal. Além disso, empresas que lidam com dados pessoais precisam considerar a LGPD, então reduzir quanto dado bruto circula no contexto do agente é também uma decisão de compliance, não só de custo.

Há ainda um fator operacional local: vários times brasileiros trabalham com integrações legadas, múltiplos fornecedores e janelas curtas de manutenção. Em cenários assim, strict tool use e filtragem intermediária ajudam a conter falhas em APIs internas que não foram desenhadas para receber payloads “quase corretos”. Isso é especialmente relevante em bancos, varejo e SaaS local, onde o custo de uma chamada malformada não é apenas técnico, mas também de suporte e reputação.

Como aplicar isso em um agente hoje

Uma forma prática de sair do “prompt com tudo” é separar o agente em três camadas: descoberta, execução e validação. A descoberta decide quais tools fazem sentido naquele caso; a execução faz o trabalho pesado de buscar, filtrar e transformar; e a validação garante que o payload final obedece ao contrato esperado.

Se a sua stack já usa MCP, o desenho fica mais natural ainda. Você pode expor ferramentas menores, testar cada uma isoladamente e introduzir code execution apenas onde faz diferença real, como filtragem de resultados, transformação de documentos e preparação de chamadas condicionais.

Checklist de implementação

reduza o catálogo inicial e carregue tools por contexto de tarefa, não por antecipação;
use validação estrita onde a API falha com campos ausentes ou tipos ambíguos;
faça filtragem antes de devolver dados ao modelo principal;
registre cada chamada com entrada, saída e erro para auditoria;
alimente o agente com ferramentas menores e composáveis, em vez de um único endpoint monolítico.

Esta seção descreve o stack de tool use e MCP conforme as páginas públicas da Anthropic em 2025/2026. APIs e comportamentos de agentes mudam rápido — confira a documentação oficial antes de levar qualquer fluxo para produção.

Um exemplo de desenho de fluxo

Imagine um agente que precisa responder dúvidas internas sobre produto, contrato e planos. Em vez de expor todas as APIs logo de início, ele primeiro consulta o catálogo de ferramentas, escolhe apenas o conector de conhecimento relevante e depois aplica filtros para remover ruído. Se a pergunta exigir uma ação, o strict tool use valida os parâmetros antes do disparo.

Esse fluxo é mais fácil de observar e menos propenso a surpresas. Quando algo falha, você sabe se o erro veio da descoberta, da filtragem ou da chamada final — e não de um contexto gigante em que tudo foi misturado.

Conclusão

O que mudou em 2026 foi a mentalidade de construção de agentes com Claude: menos dependência de ferramentas carregadas upfront, mais descoberta seletiva, execução intermediária e contratos rígidos onde eles realmente protegem a integração. Para times que querem agentes úteis em produção, isso significa gastar menos contexto com infraestrutura e mais com a tarefa de fato.

Se você quer começar em menos de uma hora, pegue um fluxo atual do seu projeto, escolha uma única etapa repetitiva e reescreva essa etapa com descoberta de ferramenta + validação estrita + logging de entrada e saída. Depois compare o consumo de tokens e a taxa de erro com a versão anterior.

Conteúdos da DIO para quem quer aprofundar

Bootcamp Bradesco Agentes — trilha prática para quem quer construir fluxos e automações com agentes de IA em cenários corporativos.
Microsoft - Foundry Agentic Engineer — abordagem voltada a engenharia de agentes, integração com ferramentas e padrões de execução.
AWS - Agentes de IA em Campo — conteúdos sobre aplicar agentes em arquiteturas com serviços em nuvem e integrações reais.
CI&T - Do Prompt ao Agente — trilha para sair do uso isolado de prompts e estruturar agentes com mais consistência técnica.
Nexa - Engenharia de Prompts na AWS com Claude — foco em prompts, Claude e aplicações em ambientes AWS com visão prática de construção.

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