Tool use na Anthropic: o que muda para integrar Claude

TL;DR

A Anthropic vem deslocando o tool use de um simples vai-e-volta entre modelo e backend para um fluxo mais estruturado: o modelo sinaliza `tool_use`, a aplicação responde com `tool_result` e, em cenários mais complexos, parte da orquestração pode sair do contexto principal. Isso reduz atrito em integrações com muitas ferramentas e muda como times pensam catálogo, execução e custo operacional.

Na prática, quem integra Claude precisa olhar menos para “chamar tool” como evento isolado e mais para arquitetura: descoberta sob demanda, execução programática e conectores padronizados via MCP. Para times no Brasil, isso conversa bem com restrições de orçamento em BRL, latência com regiões fora do país e integrações comuns com AWS e sistemas corporativos legados.

O que mudou no tool use da Anthropic

O ponto central da evolução descrita pela Anthropic é que o tool use deixou de ser apenas uma forma de adicionar funções ao modelo e passou a virar uma superfície de orquestração mais explícita. No fluxo clássico, Claude responde com `stop_reason: "tool_use"`, devolve um bloco `tool_use` com `name`, `id` e `input`, e a aplicação precisa executar a ação e devolver `tool_result` com o mesmo `tool_use_id` [fonte].

Isso parece detalhe de protocolo, mas é exatamente o que permite construir integrações confiáveis. O identificador único fecha o ciclo de execução, evita ambiguidade quando há múltiplas chamadas e facilita observabilidade, retries e correlação em logs.

Loop determinístico: menos improviso, mais contrato

Quando o modelo para em `tool_use`, ele não está “respondendo errado”; ele está pedindo que o sistema externo continue a execução. Esse tipo de contrato é útil para casos como consulta a banco, busca interna, cálculo ou qualquer ação que não deva acontecer dentro da geração de texto [fonte].

Para o integrador, isso implica separar claramente o que é inferência e o que é execução. Em vez de tratar a IA como uma caixa preta que “faz tudo”, o backend passa a coordenar etapas.

Exemplo mínimo do ciclo

Um fluxo típico pode ser modelado assim no backend:

undefined

O detalhe importante não é a sintaxe exata, e sim o contrato: o modelo pede a ferramenta, o sistema executa, e a próxima resposta volta com base nesse resultado.

Tool search: catálogo grande sem entupir contexto

Outro avanço relevante é o tool search, pensado para cenários com muitas ferramentas. A ideia é evitar carregar no contexto todas as definições de tool o tempo inteiro e permitir descoberta sob demanda, com base em nomes e descrições [fonte].

Isso muda bastante a experiência de quem integra Claude em ambientes corporativos. Em vez de registrar dezenas ou centenas de ferramentas de uma vez, você pode manter um catálogo e deixar o sistema buscar apenas o que importa para a tarefa corrente. Em termos práticos, isso ajuda quando a aplicação conversa com ERP, CRM, observabilidade, catálogo de APIs internas e serviços de dados ao mesmo tempo.

O detalhe operacional aqui é importante: a própria documentação indica que o tool search tool não é compatível com tool use direto, então ele funciona como mecanismo de descoberta e não como execução da tool em si [fonte].

Para times brasileiros, isso é valioso em cenários com orçamento controlado. Menos definição carregada no contexto tende a significar menos tokens consumidos em orquestrações longas, o que ajuda quando o custo precisa caber em BRL e quando o volume de chamadas cresce em produção.

Programmatic tool calling: orquestração sai do modelo principal

A Anthropic também avançou para um modelo em que Claude pode emitir e executar código em um ambiente controlado para chamar ferramentas, filtrar dados e devolver apenas o necessário ao contexto principal. A empresa descreve isso como programmatic tool calling, dentro da linha de advanced tool use [fonte] [fonte].

O ganho arquitetural é simples de entender: em vez de dez round-trips entre modelo e backend, parte da lógica passa a rodar no container. Isso permite encadear várias buscas, agrupar resultados e enxugar a resposta antes de devolvê-la para o modelo. Em workflows multi-tool, essa mudança tende a reduzir latência e uso de contexto [fonte].

Quando isso faz diferença no dia a dia

Esse padrão é útil quando a tarefa envolve várias consultas parecidas: buscar N itens, filtrar por critérios, cruzar com uma política interna e retornar só o subconjunto útil. O modelo deixa de carregar ruído desnecessário e a aplicação ganha um lugar claro para aplicar lógica determinística.

Para quem integra de dentro de times de produto no Brasil, isso conversa bem com stacks já comuns em empresas locais: serviços em AWS, bancos de dados gerenciados, filas e integrações HTTP com sistemas legados. O ponto não é “usar IA para tudo”, e sim reduzir o custo da coordenação entre etapas.

Esta seção descreve capacidades documentadas pela Anthropic em 2026. APIs de IA mudam rápido — confira o changelog oficial antes de adotar em produção [fonte].

Web search e versões de tool: comportamento também vira contrato

Um detalhe que muita gente subestima é que a Anthropic passou a tratar ferramentas como versões explícitas, inclusive no web search tool. A documentação cita a versão `web_search_20260209`, com suporte a dynamic filtering, em que Claude pode processar resultados antes de devolvê-los ao contexto final [fonte].

Isso importa porque a integração deixa de ser apenas “chame uma ferramenta externa” e passa a depender de política de versão, comportamento e compatibilidade. Em ambientes reais, essa disciplina evita surpresas quando uma mudança na tool altera custo, ordem dos resultados ou o tipo de saída que chega ao modelo.

Implicação para quem mantém produto em produção

Se sua aplicação depende de busca web para enriquecer respostas, o ideal é tratar a ferramenta como parte da superfície de API: versionar, testar e documentar. Isso vale ainda mais quando o output precisa ser auditável, porque o pós-processamento dentro do container pode mudar a forma como as evidências aparecem no contexto.

MCP: padronização para fugir de integrações sob medida

O Model Context Protocol entrou como um eixo importante nessa história. A Anthropic o apresenta como um padrão aberto para conectar assistentes aos sistemas onde dados e ações vivem [fonte].

Na prática, MCP ajuda a reduzir integrações totalmente bespoke. Em vez de cada time criar um contrato proprietário para cada ferramenta, você pode implementar um servidor MCP e reaproveitar o mesmo padrão para múltiplos consumidores. Para organizações com muitas squads, isso diminui retrabalho e facilita governança.

Esse ponto tem um peso especial no Brasil, onde muitas empresas combinam SaaS globais, sistemas internos e legados on-premises. Padronizar a camada de ferramentas ajuda a evitar que cada integração vire um projeto isolado.

Por que importa pro dev brasileiro

O efeito prático dessas mudanças não é só técnico. No Brasil, a maioria dos times precisa equilibrar custo em moeda forte, latência para regiões fora do país e integrações com sistemas que nem sempre foram pensados para IA. Em muitos casos, plataformas e workloads ainda ficam em regiões AWS como us-east-1, o que adiciona latência quando a operação envolvida precisa de várias idas e voltas entre modelo e backend.

Além disso, a LGPD exige atenção ao tratamento de dados pessoais. Quando o tool use passa a orquestrar busca, filtragem e execução em camadas diferentes, fica ainda mais importante decidir onde o dado entra, onde é processado e o que realmente volta para o contexto do modelo. Isso vale para setores como varejo, bancos, saúde e govtech, onde o risco regulatório é concreto.

Em vez de pensar só em prompt, o dev brasileiro precisa pensar em arquitetura de integração: quais ferramentas ficam expostas, quais dados podem circular e quanto cada rodada custa em tokens, infraestrutura e tempo de resposta.

Como desenhar a integração pensando nessa nova fase

Para integrar Claude com menos atrito, vale estruturar a solução em camadas. A primeira cuida do contrato de tool use e do loop `tool_use`/`tool_result`. A segunda organiza catálogo de ferramentas, idealmente com descoberta sob demanda. A terceira define quais fluxos merecem orquestração programática fora do contexto principal.

Esse recorte ajuda a evitar um erro comum: transformar o modelo em coordenador de tudo, inclusive de tarefas que deveriam ser resolvidas por código direto. Quando a lógica é determinística, banco, serviço ou worker podem executar melhor do que o modelo.

Checklist prático

• Modele cada tool com entrada e saída bem definidas.
• Registre `tool_use.id` e `tool_result.tool_use_id` em logs para rastreabilidade.
• Separe ferramentas críticas por versão e documente mudanças.
• Use descoberta sob demanda quando o catálogo crescer demais.
• Empurre para código o que for filtragem, agregação ou validação determinística.

Conclusão

A mudança da Anthropic com tool use aponta para uma integração mais madura: menos improviso no prompt, mais contrato entre modelo, orquestrador e ferramentas. Para quem já integra sistemas reais, o valor está em reduzir custo, ganhar previsibilidade e manter a arquitetura legível quando o número de ferramentas cresce.

Se você quer testar isso na prática em menos de uma hora, pegue uma integração pequena do seu projeto, adicione logging do par `tool_use.id` / `tool_result.tool_use_id` e redesenhe uma etapa para sair do contexto do modelo e rodar no backend. Isso já mostra rapidamente onde a orquestração está cara demais.

Conteúdos da DIO para quem quer aprofundar

• Nexa - Engenharia de Prompts na AWS com Claude — traz uma trilha curta e prática para aplicar engenharia de prompts e trabalhar com Claude no ecossistema AWS.
• Nexa - Fundamentos de IA Generativa e Claude 3 — oferece uma introdução aos fundamentos de IA generativa, com projetos e desafios práticos usando Claude e serviços AWS.

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