- Se agregaron 3 funciones nuevas a la Claude Developer Platform, ofreciendo una arquitectura avanzada de uso de herramientas para que el modelo pueda explorar, invocar y aprender de miles de herramientas externas de forma eficiente
- Tool Search Tool carga las definiciones de herramientas solo cuando se necesitan y reduce el uso de tokens hasta en un 85%, además de mejorar la precisión entre 74% y 88% en entornos MCP a gran escala
- Programmatic Tool Calling permite invocar herramientas en paralelo dentro de un entorno de ejecución de código para lograr ahorro de tokens (37%), menor latencia y mejor precisión
- Tool Use Examples permite aprender patrones de uso de herramientas y relaciones entre parámetros que no pueden expresarse con JSON Schema, mediante ejemplos reales de llamadas
- Estas tres funciones proporcionan la base para una orquestación eficiente de agentes de IA a gran escala y son componentes clave para automatizar flujos de trabajo complejos
Escalando el uso de herramientas en agentes de IA
- Los agentes de IA del futuro deberán utilizar de forma integrada cientos o miles de herramientas
- Como ejemplos se mencionan herramientas de apoyo para IDE, coordinadores de operaciones e integraciones con Slack, GitHub, Jira y Google Drive
- El enfoque tradicional exige cargar por adelantado todas las definiciones de herramientas, lo que consume rápidamente la ventana de contexto (context window)
- El nuevo enfoque busca y carga herramientas en el momento necesario, y gana eficiencia mediante invocaciones basadas en código y aprendizaje con ejemplos
Tool Search Tool
- En entornos MCP tradicionales, al conectar varios servidores las definiciones de herramientas pueden ocupar más de 100 mil tokens
- Ejemplo: GitHub (26K), Slack (21K), Jira (17K), superando en conjunto los 134K tokens
- Tool Search Tool busca y carga herramientas on-demand
- En la carga inicial usa solo unos 500 tokens, y luego carga herramientas adicionales únicamente cuando hacen falta
- El uso total de tokens baja a alrededor de 8.7K, con un ahorro de contexto del 95%
- En pruebas internas, la precisión de evaluación MCP mejoró a Opus 4: 49%→74%, Opus 4.5: 79.5%→88.1%
- Con la configuración
defer_loading: true es posible retrasar la carga de herramientas
- Las herramientas más usadas se cargan siempre, y el resto se trae en el momento de la búsqueda
- Incluye por defecto herramientas de búsqueda basadas en regex y BM25, y también permite búsqueda personalizada basada en embeddings
- Condiciones recomendadas para usarlo: más de 10 herramientas, definiciones de más de 10K tokens y entornos donde los errores de selección sean frecuentes
Programmatic Tool Calling
- Las invocaciones tradicionales basadas en lenguaje natural generan ineficiencias por la acumulación de resultados intermedios y por múltiples pasadas de razonamiento
- Ejemplo: al analizar un log de 10MB, todos los datos terminan incluidos en el contexto y desperdician tokens
- Programmatic Tool Calling (PTC) invoca herramientas en paralelo dentro de un entorno de ejecución de código
- Claude puede usar código Python para realizar bucles, condicionales y transformación de datos
- Los resultados intermedios no se incluyen en el contexto del modelo, y solo se devuelve el resultado final
- Ejemplo: en una tarea para detectar responsables de sobrepasar el presupuesto trimestral, en vez de incluir 2,000 elementos en el contexto, solo entra un resultado de 1KB
- Efectos
- Uso de tokens: 43,588→27,297 (37% menos)
- Menor latencia (elimina 19 pasos de razonamiento en 20 llamadas)
- Mejor precisión: búsqueda interna 25.6→28.5%, benchmark GIA 46.5→51.2%
- Condiciones recomendadas para usarlo
- Resumen de grandes volúmenes de datos, llamadas dependientes de 3 o más etapas y tareas que requieren ejecución en paralelo
- Puede ser ineficiente para una sola llamada o respuestas pequeñas
Tool Use Examples
- JSON Schema solo define la estructura, pero no puede expresar patrones de uso, reglas de formato ni relaciones entre parámetros
- Ejemplo: formato de fecha, reglas de ID o cuándo usar objetos anidados
- Tool Use Examples agrega ejemplos reales de entrada (
input_examples) a la definición de herramientas
- Con esos ejemplos, Claude aprende formatos de fecha (YYYY-MM-DD), reglas de ID (USR-XXXXX) y combinaciones de parámetros opcionales
- En pruebas internas, la precisión en el manejo de parámetros complejos mejoró de 72%→90%
- Condiciones recomendadas para usarlo
- Herramientas con muchas estructuras anidadas o parámetros opcionales
- APIs donde las reglas específicas del dominio no pueden expresarse con Schema
- Casos donde sea necesario distinguir entre herramientas similares
Uso combinado de las tres funciones y mejores prácticas
- Las tres funciones operan de manera complementaria
- Tool Search Tool → encuentra la herramienta necesaria
- Programmatic Tool Calling → la ejecuta de forma eficiente
- Tool Use Examples → permite llamarla correctamente
- Prioridad de adopción
- Si el problema es exceso de contexto → Tool Search Tool
- Si hay demasiados resultados intermedios → Programmatic Tool Calling
- Si hay errores de parámetros → Tool Use Examples
- Consejos de configuración
- Escribe con claridad los nombres y descripciones de las herramientas para mejorar la precisión de búsqueda
- Mantén siempre cargadas las 3 a 5 herramientas más usadas, y deja el resto con carga diferida
- Especifica el formato de retorno para las herramientas de ejecución de código
- Redacta ejemplos de datos realistas y concisos (1 a 5 ejemplos)
Primeros pasos
- Las tres funciones se ofrecen en versión beta
- Se pueden usar agregando el header
betas=["advanced-tool-use-2025-11-20"]
- Herramientas incluidas:
tool_search_tool_regex_20251119, code_execution_20250825, entre otras
- La documentación oficial y el cookbook de GitHub ofrecen ejemplos de API y guías de implementación
- Estas funciones se presentan como una tecnología base que va más allá del simple function calling y evoluciona hacia una orquestación inteligente
- Se destacan como componentes clave para habilitar búsqueda dinámica, ejecución eficiente e invocaciones precisas en flujos de trabajo complejos y entornos con grandes volúmenes de datos
5 comentarios
Pero hasta ahora parece que sigue dependiendo de la calidad del modelo. Como Claude es quien ofrece esos modelos, por eso funciona tan bien; con otros modelos, la verdad, queda la duda...
Entre empresas como Anthropic, Google y OpenAI, siento que Anthropic es la que más se acerca a la IA agéntica.
Opiniones en Hacker News
Están buscando formas de reducir el uso de contexto al hacer streaming de varios tool call
Parte del procesamiento se descarga a la propia herramienta para que devuelva un markdown de 200k tokens en una estructura resumida, pero incluso así a veces el contexto del modelo principal se llena muy rápido
Programmatic Tool Calling parece el siguiente paso natural
Como los LLM van en la dirección de tratar el código como lenguaje, la definición de ese lenguaje importa
Pero la búsqueda de herramientas parece un overhead innecesario. Es más eficiente poner de antemano en el contexto las herramientas necesarias
Al final hace falta un tool definition language conciso, como una definición de funciones, y les gustaría meter objetos en el contexto para que reconozca tipos y métodos invocables
.d.tsTambién sería más fácil de mantener y probar, y si hace falta se puede importar con algo como
export * as Foo from '@foo/foo'Como los LLM también escriben bien código, si se les da permiso de escritura podrían crear o importar herramientas por sí solos
Más adelante, una plataforma interactiva de colaboración IA↔humano como Jupyter/Pluto/Mathematica quizá sería más adecuada
Si además se le agrega entrada por voz y colaboración entre sesiones, sería casi un sistema nivel Skynet
El agente que hice funciona bien solo con parte del SDK de Python y funciones personalizadas
Esta estructura de pseudo-RPC se siente como un ritual innecesario
Smolagents lo aprovecha para tratar la salida de herramientas como objetos (dict)
Me pregunto si ese enfoque se parece a la dirección que mencionas
Hay más detalle en esta entrada del blog de Hugging Face
Me pregunto si los servidores MCP incluirán ejemplos de uso en la definición de las herramientas
Si fuera así, también podrían incluir ejemplos de código y saltarse la etapa de generación de código, pero probablemente lo bloquearon por problemas de seguridad
Ejecutar código provisto por terceros es riesgoso, así que se entiende ese diseño
Es una lástima que hayan usado Python como wrapper
Si hubieran usado Bash, habría más compatibilidad entre lenguajes y también encajaría en flujos de trabajo que no usan Python
Su capacidad para ejecutar herramientas externas no se queda atrás frente a Bash
La idea de “un futuro donde el modelo maneje sin fricción cientos o miles de herramientas” parece equivocada
Más bien la dirección correcta sería menos herramientas + mejor capacidad de uso
Llevado al extremo, hasta una sola ShellTool podría bastar
Lo ideal sería que el modelo aprenda a crear y probar sus propias herramientas para volverlas confiables
El ecosistema de conectores es fácil de entender y de vender en marketing, pero en el fondo parece un paradigma equivocado
Sería bueno tener un modelo orquestador local pequeño
En muchos casos coordinar programáticamente todo el flujo de trabajo resulta ineficiente
Para reducir la contaminación del contexto y acelerar el proceso, lo ideal sería una estructura programmatic > tiny local LLM > frontier LLM
El modelo pequeño puede reiniciar el contexto con frecuencia y pasarle al modelo grande solo los resultados necesarios
Al usar asistentes de IA aparecen patrones repetitivos
Si uno mejora por su cuenta un método ineficiente, unos meses después sale una herramienta nueva y ese trabajo pierde sentido
Es el precio de seguir el ritmo de la tecnología más reciente
Algún día toda la web probablemente estará compuesta por decenas de miles de millones de herramientas
Google las indexará y Gemini las elegirá dinámicamente para actuar en el mundo
De hecho, eso era lo que esperaba de Gemini 3
La función #2 mencionada aquí es una implementación de la idea que recientemente ha dado de qué hablar: “no llamar herramientas directamente, sino escribir código para llamarlas”
Funciona dentro de un sandbox de Python, también se puede acceder por API y expone las llamadas a herramientas como si fueran llamadas normales de API
El batch tool calling ya aceleró muchísimo el asistente de IA de nuestro producto, y esta función parece una evolución de eso
Nuestro agentic builder usa una sola herramienta: GraphQL
El agente escribe y ejecuta consultas, y obtiene la información que necesita mediante introspection
Como recibe solo los datos mínimos, puede ahorrar tokens
No hace falta cargar más de 50 herramientas, y además se resuelve el problema N+1 de las API REST
Gracias al typed schema de GraphQL, el agente escribe mejor código
Antes no me gustaba GraphQL, pero viendo el estado actual de MCP, creo que es una de las tecnologías más adecuadas para agentes de IA
Lo expliqué con más detalle en este artículo
Mi agente solo ejecuta una consulta SPARQL, y el estado vive únicamente en una base de datos de grafos
Como la mayoría de las ontologías son públicas, casi no hace falta schema introspection
Gracias a la salida estructurada, se puede restringir para que solo genere RDF válido
Supongo que en GraphQL también se podría hacer algo similar
Yo necesito hacer búsquedas web, llamadas a API locales, integraciones con Slack y otras tareas, así que solo con GraphQL no alcanza
Hay temas de permisos, caché y mutation, pero eso no afecta demasiado la carga selectiva de contexto
El LLM escribe bastante bien consultas GraphQL que respetan el schema
Incluso si se equivoca, si se le dan buenos mensajes de error corrige rápido
El razonamiento relacionado está en esta entrada del blog
Yo también pensaba que sonnet 4.5 era bastante bueno.
Creo que opus 4.5 es aún mejor. Guau.
¿Sí? ¿Qué aspectos son principalmente así?