- A Claude Developer Platform adicionou 3 novos recursos, oferecendo uma arquitetura avançada de uso de ferramentas para que o modelo possa explorar, chamar e aprender de forma eficiente com milhares de ferramentas externas
- O Tool Search Tool carrega definições de ferramentas apenas quando necessário e reduz o uso de tokens em até 85%, além de melhorar a precisão em 74~88% em ambientes MCP de grande escala
- O Programmatic Tool Calling chama ferramentas em paralelo em um ambiente de execução de código para alcançar redução de tokens (37%), menor latência e maior precisão
- O Tool Use Examples permite aprender padrões de uso de ferramentas e relações entre parâmetros que não podem ser expressos com JSON Schema, por meio de exemplos reais de chamadas
- Os três recursos fornecem a base para a orquestração eficiente de agentes de IA em grande escala e são componentes centrais para a automação de fluxos de trabalho complexos
Expansão do uso de ferramentas por agentes de IA
- Os agentes de IA do futuro precisarão usar de forma integrada centenas a milhares de ferramentas
- Como exemplos, são citados ferramentas auxiliares de IDE, coordenadores operacionais e integrações com Slack, GitHub, Jira e Google Drive
- A abordagem existente exigia carregar previamente todas as definições de ferramentas, consumindo rapidamente a janela de contexto (context window)
- A nova abordagem garante eficiência ao explorar e carregar ferramentas sob demanda e ao usar chamadas baseadas em código e aprendizado por exemplos
Tool Search Tool
- Em ambientes MCP existentes, ao conectar vários servidores, as definições de ferramentas podem ocupar mais de 100 mil tokens
- Ex.: GitHub (26K), Slack (21K), Jira (17K), ultrapassando 134K tokens no total
- O Tool Search Tool faz busca e carregamento de ferramentas on-demand
- No carregamento inicial, usa cerca de 500 tokens e carrega adicionalmente apenas as ferramentas necessárias
- O uso total de tokens cai para cerca de 8.7K, com economia de contexto de 95%
- Em testes internos, a precisão da avaliação MCP melhorou para Opus 4: 49%→74%, Opus 4.5: 79.5%→88.1%
- É possível fazer carregamento tardio de ferramentas com a configuração
defer_loading: true
- Apenas as ferramentas mais usadas permanecem sempre carregadas, enquanto as demais são trazidas no momento da busca
- Ferramentas de busca baseadas em regex e BM25 são fornecidas por padrão, e também é possível usar busca customizada baseada em embeddings
- Condições recomendadas de adoção: mais de 10 ferramentas, definições com mais de 10K tokens, ambientes com erros frequentes de seleção
Programmatic Tool Calling
- Chamadas tradicionais baseadas em linguagem natural geram ineficiência devido ao acúmulo de resultados intermediários e a múltiplas passagens de raciocínio
- Ex.: ao analisar um log de 10MB, todos os dados entram no contexto, desperdiçando tokens
- O Programmatic Tool Calling (PTC) faz chamadas paralelas de ferramentas em um ambiente de execução de código
- Claude executa loops, condicionais e transformações de dados com código Python
- Os resultados intermediários não entram no contexto do modelo, e apenas o resultado final é retornado
- Exemplo: ao buscar responsáveis por excesso de orçamento trimestral, apenas 1KB do resultado entra no contexto, em vez de 2.000 itens
- Efeitos
- Uso de tokens: 43,588→27,297 (redução de 37%)
- Redução de latência (eliminação de 19 inferências em 20 chamadas)
- Melhora de precisão: busca interna 25.6→28.5%, benchmark GIA 46.5→51.2%
- Condições recomendadas de adoção
- Resumo de grandes volumes de dados, chamadas dependentes em 3 etapas ou mais, tarefas que exigem execução paralela
- Ineficiente para uma única chamada ou respostas pequenas
Tool Use Examples
- O JSON Schema define apenas a estrutura, mas não consegue expressar padrões de uso, regras de formato e relações entre parâmetros
- Ex.: formato de data, regras de ID, momento de uso de objetos aninhados etc. ficam ambíguos
- O Tool Use Examples adiciona exemplos reais de entrada (
input_examples) à definição da ferramenta
- Com isso, Claude aprende formato de data (YYYY-MM-DD), regras de ID (USR-XXXXX) e combinações de parâmetros opcionais
- Em testes internos, a precisão no tratamento de parâmetros complexos subiu de 72%→90%
- Condições recomendadas de adoção
- Ferramentas com estruturas aninhadas e muitos parâmetros opcionais
- APIs cujas regras por domínio não podem ser expressas em Schema
- Casos em que é preciso distinguir entre ferramentas semelhantes
Uso integrado dos três recursos e melhores práticas
- Os três recursos funcionam de forma complementar
- Tool Search Tool → encontrar a ferramenta necessária
- Programmatic Tool Calling → executar com eficiência
- Tool Use Examples → chamar com precisão
- Prioridade de adoção
- Excesso de contexto → Tool Search Tool
- Resultados intermediários em excesso → Programmatic Tool Calling
- Erros de parâmetro → Tool Use Examples
- Dicas de configuração
- Escreva com clareza o nome e a descrição das ferramentas para melhorar a precisão da busca
- Mantenha sempre carregadas as 3~5 ferramentas mais usadas e deixe as demais para carregamento tardio
- Especifique o formato de retorno para ferramentas de execução de código
- Escreva dados de exemplo realistas e concisos (1~5 exemplos)
Primeiros passos
- Os três recursos são oferecidos em versão beta
- Podem ser usados após adicionar o header
betas=["advanced-tool-use-2025-11-20"]
- Ferramentas incluídas:
tool_search_tool_regex_20251119, code_execution_20250825 etc.
- A documentação oficial e o cookbook no GitHub oferecem exemplos de API e guias de implementação
- Esses recursos são apresentados como uma tecnologia fundamental para evoluir de simples chamadas de função para orquestração inteligente
- São destacados como componentes centrais para viabilizar exploração dinâmica, execução eficiente e chamadas precisas em fluxos de trabalho complexos e ambientes com grandes volumes de dados
5 comentários
Mas, por enquanto, ainda parece muito depender do modelo. Isso funciona tão bem porque são os modelos que o Claude oferece; fico me perguntando se com outros modelos seria assim também...
Entre empresas como Anthropic, Google e OpenAI, tenho a impressão de que a Anthropic é a que mais se aproxima de uma IA agentiva.
Comentários no Hacker News
Estou tentando encontrar uma forma de reduzir o uso de contexto ao fazer streaming de vários tool calls
Descarrego parte do processamento para a própria ferramenta para que ela retorne um markdown de 200k tokens em uma estrutura resumida, mas mesmo assim esse método às vezes preenche rapidamente o contexto do modelo principal
Acho que Programmatic Tool Calling é o próximo passo natural
Como os LLMs estão caminhando para tratar código como linguagem, a definição dessa linguagem é importante
Mas vejo a busca de ferramentas como um overhead desnecessário. É mais eficiente colocar previamente no contexto as ferramentas necessárias
No fim, é preciso uma tool definition language concisa, como uma definição de função, e eu gostaria de colocar objetos no contexto para que o modelo reconheça seus tipos e métodos chamáveis
.d.tsFica mais fácil de manter e testar, e, se necessário, dá para importar com algo como
export * as Foo from '@foo/foo'Como os LLMs também escrevem bem código, se receberem permissão de escrita podem criar ou importar ferramentas por conta própria
Mais adiante, acho que uma plataforma interativa de colaboração IA↔humano como Jupyter/Pluto/Mathematica será mais adequada
Se adicionar entrada por voz e permitir colaboração entre sessões, isso quase vira um sistema no nível de Skynet
O agente que eu criei funciona bem só com parte dos recursos do Python SDK e algumas funções customizadas
Essa estrutura de pseudo-RPC parece um ritual desnecessário
O Smolagents usa isso para tratar a saída das ferramentas como objetos (dict)
Fiquei curioso se essa abordagem é parecida com a direção que você descreveu
Mais detalhes estão neste post do blog da Hugging Face
Fiquei me perguntando se o servidor MCP vai incluir exemplos de uso na definição das ferramentas
Se sim, poderia incluir também exemplos de código e pular a etapa de geração de código, mas imagino que isso tenha sido bloqueado por questões de segurança
Executar código fornecido por terceiros é arriscado, então entendo esse desenho
Foi uma pena terem usado Python como wrapper
Se tivessem usado Bash, haveria mais compatibilidade entre linguagens e também serviria para fluxos de trabalho que não usam Python
Sua capacidade de executar ferramentas externas não fica atrás da do Bash
Acho equivocada essa ideia de “um futuro em que o modelo lida de forma fluida com centenas ou milhares de ferramentas”
Vejo o caminho certo como menos ferramentas + melhor capacidade de uso
No extremo, até um único ShellTool pode ser suficiente
O ideal é que o modelo aprenda a criar e testar suas próprias ferramentas para poder confiar nelas
O ecossistema de conectores é fácil de entender e bom para marketing, mas no fundo parece um paradigma equivocado
Acho que seria ótimo ter um pequeno modelo orquestrador local
Em muitos casos, é ineficiente coordenar todo o fluxo de trabalho de forma programática
Para reduzir a poluição de contexto e aumentar a velocidade, a estrutura ideal seria programmatic > tiny local LLM > frontier LLM
O modelo pequeno poderia reinicializar o contexto com frequência e passar ao modelo grande apenas os resultados necessários
Ao usar assistentes de IA, há padrões que se repetem
Quando melhoro manualmente um método ineficiente, alguns meses depois surge uma ferramenta nova e meu trabalho perde o sentido
Acho que esse é o preço de correr atrás do estado da arte
Um dia, acho que a web inteira será composta por bilhões de ferramentas
O Google vai indexá-las, e o Gemini vai selecioná-las dinamicamente para agir no mundo
Na verdade, eu esperava algo assim no Gemini 3
O recurso #2 mencionado aqui é uma implementação do conceito que virou assunto recentemente: “não chamar a ferramenta diretamente, mas escrever código para chamá-la”
Ele roda em um sandbox Python, também pode ser acessado via API e expõe chamadas de ferramenta como se fossem chamadas normais de API
O Batch tool calling já aumentou bastante a velocidade do assistente de IA no nosso produto, e este recurso parece ser uma evolução disso
Nosso agentic builder usa uma única ferramenta — GraphQL
O agente escreve e executa queries, e obtém as informações necessárias via introspection
Como recebe apenas o mínimo de dados, consegue economizar tokens
Não é preciso carregar mais de 50 ferramentas, e também se resolve o problema de N+1 das REST APIs
Graças ao schema tipado do GraphQL, o agente escreve código melhor
Antes eu não gostava de GraphQL, mas vendo o estado atual do MCP, acho que é uma das tecnologias mais adequadas para agentes de IA
Organizei mais detalhes neste texto
Meu agente executa apenas uma query SPARQL, e o estado fica só no banco de dados em grafo
Como a maioria das ontologias é pública, quase não é necessário schema introspection
Graças à saída estruturada, dá para restringir o sistema para gerar apenas RDF válido
Acho que algo parecido também seria possível com GraphQL
Eu preciso fazer várias tarefas, como busca na web, chamadas de API local e integração com Slack, então só GraphQL não basta
Há questões de permissão, cache e mutation, mas isso não afeta muito o carregamento seletivo de contexto
O LLM escreve queries GraphQL compatíveis com o schema muito bem
Mesmo quando erra, se você der boas mensagens de erro, ele corrige rápido
Há um raciocínio relacionado neste post do blog
Eu também achei o sonnet 4.5 bem bom.
O opus 4.5 parece ainda melhor. Uau.
Sério? Em quais pontos isso acontece principalmente?