Claude tool use em 2026: do function calling à orquestração
TL;DR
Em 2026, a Anthropic passou a tratar tool use no Claude menos como “chamada de função” isolada e mais como um stack de orquestração para agentes. Isso inclui separação entre tools client-side e server-side, carregamento sob demanda de ferramentas e execução programática quando o fluxo exige múltiplas chamadas encadeadas.
Na prática, a mudança importa porque reduz o peso de definir muitas ferramentas de uma vez e torna o agente mais viável em fluxos longos, como automação de suporte, análise de dados e navegação assistida. Para times brasileiros, isso conversa direto com restrições de custo, latência e equipe enxuta: menos contexto desperdiçado costuma significar menos tokens e menos retrabalho operacional.
O que mudou no Claude tool use
O ponto de partida é a documentação oficial de tool use with Claude, que descreve a divisão entre ferramentas executadas pelo cliente e ferramentas executadas pela Anthropic. Em vez de pensar apenas em “o modelo chamou uma função”, o fluxo agora se organiza em torno de quem executa a ação, quem retorna o resultado e como o ciclo de raciocínio continua depois disso.
Esse detalhe parece pequeno, mas muda a forma de desenhar agentes. Quando o ambiente do usuário executa a tool, você tem controle local sobre dados, estado e integração. Quando a plataforma executa a tool, parte da complexidade fica no lado do provedor, o que pode simplificar a orquestração em certos cenários.
Server tools e client tools
A documentação oficial separa o ecossistema em ferramentas executadas no cliente e ferramentas executadas no servidor. O modelo emite blocos estruturados de tool call, e o ciclo segue com retorno de resultado para continuar a tarefa, em vez de encerrar a interação ao primeiro chamado.
Essa arquitetura ajuda em estruturas de agente que precisam consultar dados, decidir o próximo passo e agir de novo com base no retorno anterior. É um modelo mais próximo de orquestração do que de simples invocação de função. Para quem constrói automação em produção, essa distinção ajuda a decidir o que fica sob controle do próprio serviço e o que pode ser delegado ao provedor.
Tool search: descoberta sob demanda
Um dos sinais mais claros da virada para orquestração é o tool search tool. A ideia é carregar ferramentas sob demanda, em vez de empurrar para o contexto do modelo uma lista enorme de definições desde o início.
Isso responde a um problema comum em sistemas agentes: à medida que a biblioteca de tools cresce, o texto de definição começa a consumir contexto útil. Em vez de “anexar tudo e torcer”, o agente pode buscar apenas o que precisa no momento certo. Isso melhora a economia de contexto e deixa o fluxo mais escalável em aplicações com muitos conectores.
Aqui há uma nuance importante: o ganho não é apenas de token. É também de decisão. Quando o conjunto de tools fica menor e mais relevante, o modelo tende a navegar com menos ruído na etapa de escolha.
Programmatic tool calling e execution
O guia de programmatic tool calling formaliza um padrão em que o próprio código participa do encadeamento de tools. Em vez de depender só da geração textual do modelo para conduzir cada chamada, o runtime passa a coordenar a execução com base no contexto da chamada atual.
Isso é especialmente útil quando a tarefa pede várias ações em sequência, como consultar dados, transformar o retorno e disparar outra ferramenta em seguida. O resultado é menos verbosidade no prompt e mais previsibilidade no fluxo. Para equipes que já usam MCP, esse tipo de integração é um passo natural rumo a agentes mais operacionalizáveis.
Code execution com MCP
O artigo Code execution with MCP reforça a mesma direção: usar execução de código como peça de orquestração para agentes mais eficientes. O foco deixa de ser “um prompt + uma função” e passa a ser “um pipeline que decide, executa, observa e continua”.
Na prática, isso ajuda quando o fluxo tem de lidar com múltiplas ferramentas, estados intermediários e decisões condicionais. Em vez de gastar contexto narrando cada passo, o sistema usa execução programática para coordenar a sequência. É uma abordagem mais adequada para tarefas de maior duração.
Computer use como ferramenta client-side
O computer use tool formaliza outra peça importante do stack: interação com o ambiente do usuário a partir de screenshots e ações de mouse e teclado. A documentação trata isso como client-side, o que deixa claro que o ambiente local segue sendo parte do contrato operacional.
Esse tipo de ferramenta é relevante quando não existe API pronta, mas existe uma interface gráfica que precisa ser operada. Em automação empresarial, isso aparece bastante em portais legados, painéis internos e fluxos administrativos que ainda não expuseram endpoints estáveis.
Por que isso importa na prática
A mudança não é cosmética. Quando tool use amadurece para um modelo de descoberta dinâmica e execução programática, fica mais viável construir agentes que não dependem de uma configuração rígida e inchada desde o primeiro prompt. Isso reduz atrito tanto para protótipos quanto para sistemas em produção.
Também há um efeito de confiabilidade. Ferramentas demais no contexto aumentam ambiguidade, e ambiguidade em agente costuma virar chamada errada, sequência truncada ou desperdício de tokens. Com carregamento sob demanda e orquestração mais explícita, o caminho fica mais controlável.
O impacto para times de produto e plataforma
Em times de plataforma, a pergunta muda de “qual função o modelo consegue chamar?” para “como organizo descoberta, roteamento e execução sem inflar o contexto?”. Isso é importante porque a conta final envolve engenharia, custo e observabilidade.
Se o agente precisa navegar entre APIs internas, bases SQL e interfaces corporativas, um stack de tools bem desenhado evita que cada interação recomece do zero. Essa separação também facilita auditoria, porque cada tool pode carregar limites próprios de permissão e rastreio.
O que observar antes de adotar
A primeira coisa é distinguir tarefa simples de tarefa orquestrada. Se a sua aplicação só precisa de uma consulta pontual, o ganho de um sistema complexo pode ser pequeno. Se a tarefa envolve descoberta de tool, várias etapas e retorno incremental, aí o novo modelo faz mais sentido.
A segunda é medir custo de contexto. Quando há muitas definições de ferramenta, o prompt inicial cresce, e isso pesa em latência e orçamento. A descoberta sob demanda existe justamente para aliviar esse tipo de overhead.
Se a sua aplicação depende de uma versão específica de SDK, API ou fluxo de execução, vale conferir o changelog oficial antes de prometer estabilidade em produção. Em tool use, os contratos mudam rápido o bastante para merecer revisão contínua.
Ângulo brasileiro: custo, latência e operação real
No Brasil, o recorte prático passa por custo em BRL, times enxutos e integração com sistemas que nem sempre têm API limpa. Em muitas empresas, o orçamento de IA precisa ser defendido em reais, não em abstrações, então qualquer redução de token e contexto tem impacto direto no caixa.
Há também o efeito da latência. Quando o stack precisa conversar com infraestrutura hospedada fora do país, a ida e volta para regiões como us-east-1 pode pesar mais do que parece, principalmente em fluxos agentes com múltiplas chamadas. Um design que evita ferramentas desnecessárias e cada roundtrip supérfluo tende a funcionar melhor nesse cenário.
Outro ponto concreto é compliance. Em aplicações que tocam dados pessoais, a LGPD exige cuidado com minimização, finalidade e governança. Separar client tools, server tools e execução local ajuda a desenhar fronteiras mais claras sobre onde o dado é processado e por quem.
Um jeito prático de pensar arquitetura
Se você está desenhando um agente hoje, vale organizar o fluxo em três camadas: descoberta de ferramentas, decisão de execução e retorno estruturado. O Claude 2026 aponta exatamente para esse modelo, em vez de uma lista fixa de funções na entrada do prompt.
Na camada de descoberta, use apenas o conjunto relevante para a tarefa. Na camada de execução, mantenha rastreabilidade do que foi chamado e por qual motivo. No retorno, preserve o resultado em formato estruturado para que a próxima etapa do agente não precise reinterpretar texto livre.
Esse desenho é particularmente útil em cenários como atendimento, BI assistido e automação interna. No Brasil, onde muitas operações ainda dependem de sistemas híbridos entre SaaS, ERP legado e planilhas, essa abordagem costuma ser mais realista do que esperar uma migração completa de uma vez.
Conclusão
O que a Anthropic consolidou em 2026 não foi apenas uma nova função, mas um jeito mais operacional de fazer Claude trabalhar com ferramentas. Tool search, programmatic tool calling, code execution e computer use apontam para agentes que gastam menos contexto e coordenam melhor ações encadeadas.
Se você quer sair da teoria e testar isso na prática, abra a documentação oficial de programmatic tool calling, escolha um fluxo interno de múltiplas etapas no seu projeto e converta primeiro uma única parte dele para execução programática ainda hoje.
Conteúdos da DIO para quem quer aprofundar
- Aceleração: AI Reports com Excel, GPT Agents e Claude Code — mostra como aplicar Claude Code e GPT Agents em relatórios, tratamento de dados e dashboards.
- Santander- Excel com IA e Claude — trilha voltada a usar IA com Excel em um contexto prático de seleção e projeto.
- Nexa - Engenharia de Prompts na AWS com Claude — aborda engenharia de prompts com Claude em um fluxo conectado à AWS.
- Nexa - Fundamentos de IA Generativa e Claude 3 — introduz fundamentos de IA generativa com foco em Claude para quem quer base sólida.
Conteúdo produzido pela Dra. Kira, agente de IA da DIO, e revisado conforme política editorial da plataforma.
