La carrera por construir agentes de IA de verdad útiles —capaces de trabajar horas, encadenar tareas y coordinarse con decenas de sistemas— no va solo de modelos cada vez más grandes. Va, sobre todo, de cómo esos modelos usan herramientas: APIs, bases de datos, scripts, servicios SaaS, MCP servers… Y ahí es donde Anthropic acaba de mover ficha importante.
La compañía ha anunciado en su plataforma para desarrolladores tres grandes novedades: Tool Search Tool, Programmatic Tool Calling y Tool Use Examples. Combinadas con funciones ya disponibles como effort control y context compaction, el objetivo es claro: permitir que Claude trabaje con cientos de herramientas, durante más tiempo y con menos intervención humana, sin reventar la ventana de contexto ni el presupuesto en tokens.
Este movimiento refuerza la apuesta de Anthropic por los agentes de IA “de verdad”, esos que no solo responden prompts, sino que se conectan a infraestructuras complejas y automatizan procesos de negocio de principio a fin.
El problema: demasiadas herramientas, demasiado contexto
El modelo de uso clásico es conocido: se definen las herramientas (funciones, APIs, MCP servers) y se las “inyecta” en el contexto del modelo, normalmente como JSON Schema. Esto funciona… hasta que crece el sistema.
En un entorno corporativo real no es raro tener:
- Un servidor MCP de GitHub con decenas de herramientas.
- Integraciones con Slack, Jira, Grafana, Sentry, Splunk…
- Herramientas propias para bases de datos, CRMs, ERPs, etc.
Según datos de Anthropic, solo cinco servidores MCP pueden suponer alrededor de 55.000 tokens en definiciones de herramientas antes de que el modelo siquiera lea la petición del usuario. En algunos entornos internos han visto hasta 134.000 tokens consumidos únicamente en definiciones.
El resultado es obvio:
- Menos espacio para la conversación y el historial.
- Costes más altos por petición.
- Más errores de selección de herramienta (confusiones entre APIs de nombres parecidos).
- Menor estabilidad en sesiones largas.
Ahí entra en juego el Tool Search Tool.
Tool Search Tool: descubrir herramientas bajo demanda
La idea es sencilla, pero potente: en vez de cargar todas las herramientas desde el principio, Claude solo ve una herramienta de búsqueda de herramientas y un pequeño subconjunto de utilidades críticas. El resto se marcan como deferred y permanecen fuera del contexto hasta que hacen falta.
Cuando el modelo necesita, por ejemplo, crear un ticket de Jira o abrir un pull request en GitHub, primero llama al Tool Search Tool:
- Busca por nombre, descripción o palabras clave.
- El sistema devuelve solo las herramientas relevantes (por ejemplo,
github.createPullRequestygithub.listIssues). - Esas definiciones se inyectan en el contexto y Claude ya puede usarlas con normalidad.
El ahorro de contexto es brutal. En un ejemplo típico:
- Enfoque tradicional: ~72.000 tokens en definiciones de herramientas + conversación.
- Con Tool Search Tool: ~500 tokens del buscador + 3–5 herramientas relevantes (~3.000 tokens).
Es decir, se preserva alrededor del 95 % de la ventana de contexto. Anthropic afirma que en sus pruebas internas Opus 4 pasó de un 49 % a un 74 % de acierto en tareas con muchas herramientas, y Opus 4.5 subió del 79,5 % al 88,1 % con búsqueda de herramientas activada.
Para escenarios con múltiples MCP servers y decenas de integraciones, esto convierte algo inmanejable en un sistema mucho más robusto y económico.
Programmatic Tool Calling: orquestación por código, no solo por prompts
El segundo gran problema que se encuentran los equipos al construir agentes complejos es el “ensuciamiento” del contexto con datos intermedios.
Ejemplos típicos:
- Analizar logs de varios MB para encontrar patrones de error.
- Cruzar datos de ventas, presupuestos y gastos por empleado.
- Hacer barridos masivos de métricas de observabilidad en distintos sistemas.
Con el enfoque clásico, cada llamada de herramienta:
- Genera una nueva inferencia del modelo.
- Devuelve resultados que se incrustan en el contexto.
- Obliga al modelo a “leer” toda esa información para decidir el siguiente paso.
En flujos de trabajo con muchas llamadas encadenadas, el contexto se llena de datos que el modelo ya no necesita, el coste se dispara y la latencia se multiplica.
Con Programmatic Tool Calling, Anthropic le da la vuelta al esquema: Claude puede escribir código (por ejemplo, Python) que orquesta las herramientas, ejecutarlo en un entorno aislado y solo devolver al contexto el resultado final o un resumen.
Imaginemos una tarea de negocio como:
“¿Qué miembros del equipo han superado su presupuesto de viajes en el tercer trimestre?”
Las herramientas disponibles podrían ser:
get_team_members(department)get_expenses(user_id, quarter)get_budget_by_level(level)
En lugar de hacer 20 llamadas de herramienta, traer todos los gastos de cada empleado al contexto y sumarlos uno a uno “a ojo”, Claude genera un script que:
- Pide la lista de miembros del equipo.
- Consulta los presupuestos por nivel.
- Lanza en paralelo las consultas de gastos.
- Suma los importes, compara con el límite y construye una lista solo con quienes se han pasado.
Todo el procesamiento (bucles, filtros, cálculos) ocurre fuera del contexto del modelo, en el entorno de ejecución de código. Claude solo recibe como entrada final algo del estilo:
[
{ "name": "Alice", "spent": 12_500, "limit": 10_000 },
{ "name": "Bob", "spent": 9_200, "limit": 8_000 }
]
Según Anthropic, este enfoque proporciona:
- Ahorro de tokens: en tareas complejas de investigación interna, el consumo medio cayó de 43.588 a 27.297 tokens (un 37 % menos).
- Menos latencia: se evita hacer una inferencia de modelo por cada llamada de herramienta; muchas se agrupan en un único bloque de código.
- Más precisión: la lógica de control de flujo (condicionales, bucles, reintentos) queda explícita en código, en lugar de diluida en instrucciones en lenguaje natural.
Para flujos de trabajo de producción —tablas enormes, recopilar datos de distintas APIs, filtrados complicados— esto abre la puerta a agentes que hacen de verdad trabajo pesado, sin saturar al modelo con ruido.
Tool Use Examples: enseñar con ejemplos, no solo con esquemas
El tercer componente de la actualización responde a una cuestión menos evidente, pero igual de importante: los esquemas JSON dicen qué es válido, pero no cómo se usa bien una API.
Un input_schema puede definir que un campo due_date es una cadena, pero no aclarar si debe ir en formato YYYY-MM-DD o incluir zona horaria. Puede indicar que priority es un enum con valores low, medium, high y critical, pero no explicar en qué casos se combina con escalation.level o sla_hours.
Con Tool Use Examples, el desarrollador puede adjuntar ejemplos reales de uso directamente en la definición de la herramienta. Por ejemplo, para un sistema de tickets:
- Un caso de bug crítico con todos los campos rellenos, escalado y SLA agresivo.
- Una petición de funcionalidad donde solo se indica el título y algunas etiquetas.
- Una tarea interna con un mínimo de información.
A partir de 3–5 ejemplos bien elegidos, el modelo aprende:
- El formato correcto de fechas, identificadores y etiquetas.
- Cuándo tiene sentido rellenar campos opcionales y cómo se combinan entre sí.
- Qué estructura anidada espera la API (por ejemplo,
reporter.contact.email).
Anthropic asegura que, en sus pruebas internas, el uso de ejemplos elevó la precisión en el manejo de parámetros complejos del 72 % al 90 %. Para APIs corporativas con reglas de negocio rígidas, esto reduce mucho el riesgo de llamadas mal formadas o datos incoherentes.
Effort control y context compaction: hacer que las sesiones duren más
Aunque el anuncio se centra en las tres nuevas funciones, Anthropic recuerda que todo esto se apoya en otras dos piezas que ya estaban presentes en la plataforma:
- Effort control, que permite ajustar cuántos recursos computacionales dedica Claude a cada tarea (algo así como decidir cuánto “piensa” antes de responder).
- Context compaction, mecanismos para resumir historial y mantener conversaciones largas sin perder información crítica ni disparar el número de tokens.
Combinadas con la búsqueda de herramientas y la orquestación programática, estas capacidades apuntan a un objetivo: agentes que puedan operar durante horas o días, encadenando acciones, integraciones y consultas de datos, sin supervisión constante.
Qué significa esto para desarrolladores y empresas
Para quienes construyen productos sobre la Claude Developer Platform, estas novedades cambian el tipo de proyectos que resultan viables:
- IDE assistants capaces de usar Git, gestores de paquetes, herramientas de testing y pipelines de despliegue sin ahogar el contexto en definiciones.
- Coordinadores de operaciones que se integran con Slack, GitHub, Jira, bases de datos y docenas de MCP servers, manteniendo la sesión estable.
- Agentes internos de negocio que consultan grandes volúmenes de datos, aplican lógica empresarial compleja en código y solo devuelven al modelo la información relevante para la decisión final.
En un mercado donde todas las grandes plataformas hablan de “AI agents”, Anthropic está apostando por algo muy concreto: menos magia de prompt y más infraestructura de orquestación seria.
Queda por ver cómo responde el ecosistema, pero el mensaje es claro: el futuro de los agentes pasa por gestionar mejor las herramientas, no por añadir solo más parámetros al modelo.
Preguntas frecuentes sobre las nuevas funciones de herramientas en Claude
¿Tiene sentido usar Tool Search Tool si solo tengo unas pocas herramientas definidas?
Probablemente no. La búsqueda de herramientas está pensada para bibliotecas medianas o grandes (más de 10 herramientas) donde las definiciones empiezan a consumir miles de tokens. Si en cada sesión se usan casi siempre las mismas 3 o 4, es más sencillo cargarlas directamente.
¿Programmatic Tool Calling sustituye al uso clásico de herramientas por lenguaje natural?
No. Es complementario. Las llamadas “normales” siguen siendo muy útiles para operaciones simples o consultas puntuales. La orquestación programática brilla cuando hay múltiples llamadas, datos voluminosos o se necesita lógica de control compleja (bucles, reintentos, filtrados…).
¿Los Tool Use Examples aumentan mucho el coste en tokens?
Añaden algo de peso extra a la definición de la herramienta, pero suele compensar con menos errores, menos reintentos y menos debugging. La recomendación general es incluir entre 1 y 5 ejemplos por herramienta y centrarse en los casos que generan más ambigüedad.
¿Estas funciones están pensadas solo para MCP o también para APIs propias?
Funcionan para ambos. MCP facilita mucho la conexión con servicios existentes, pero cualquier API propia que se exponga como herramienta puede beneficiarse de búsqueda diferida, ejecución programática y ejemplos de uso, especialmente en entornos empresariales con muchos sistemas internos.
vía: anthropic
