Qué es Tool Calling: cómo un agente de IA realmente hace cosas (y no solo responde)

Le pides a un chatbot que revise si mañana va a llover y, si va a llover, que te agende una alarma más temprano. Te responde perfecto, en buen español, explicándote paso a paso cómo podrías hacerlo tú mismo: entra a esta app del clima, abre tu calendario, crea el evento a esta hora.

Nunca lo hizo. Solo te explicó cómo hacerlo.

Ese "te explico cómo" en vez de "lo hago" era, literalmente, todo lo que un modelo de lenguaje podía ofrecer hasta hace poco más de tres años. Podía escribir sobre código, sobre APIs, sobre comandos de terminal — pero no podía tocar nada de verdad. A cerrar esa brecha entre saber y hacer se le llama Tool Calling, y es, sin exagerar, el mecanismo más fundamental de todo lo que ya viste en esta serie: sin él, no existirían ni los subagentes, ni los Skills, ni MCP.

Qué es, en una frase

Tool Calling (también llamado function calling) es el mecanismo por el cual un modelo de IA, en vez de solo generar texto, produce una salida estructurada — un nombre de función y sus argumentos en JSON — que tu código ejecuta de verdad. El modelo pide la acción. Nunca la ejecuta él mismo.

Esa última parte es la que casi nadie explica bien, así que vale la pena repetirla: el modelo no corre nada. Solo dice "quiero llamar a esta función, con estos datos". Alguien más — tu programa — decide si ejecutarla, la ejecuta, y le devuelve el resultado.

El chisme: de un paper académico a un anuncio que cambió todo

Esto no salió de la nada. En febrero de 2023, un equipo de Meta AI publicó un paper llamado Toolformer, donde demostraron que un modelo podía enseñarse a sí mismo cuándo llamar a una calculadora, un buscador o un traductor, y cómo usar esos resultados para responder mejor. Era la prueba de concepto.

El anuncio que lo convirtió en producto llegó el 13 de junio de 2023, cuando OpenAI publicó "Function calling and other API updates". La frase que resume todo:

"Estos modelos han sido fine-tuneados para detectar cuándo se necesita llamar a una función... y para responder con JSON que se adhiere a la firma de la función."

El ejemplo que dieron entonces ya se siente arqueológico visto desde hoy: le preguntabas "¿Qué tiempo hace en Boston?" y el modelo, en vez de inventar una respuesta, devolvía algo como get_current_weather(location="Boston", unit="fahrenheit") — listo para que tu código lo ejecutara contra una API real. Anthropic llevó su propia versión ("tool use") a disponibilidad general el 30 de mayo de 2024. Hoy, en 2026, es un estándar que comparten OpenAI, Anthropic y Google casi sin diferencias conceptuales.

Cómo funciona, en cinco pasos

No hace falta entender matemáticas de modelos para entender el mecanismo. Es un bucle de cinco pasos que se repite:

1. Le describes al modelo qué herramientas tiene disponibles — un nombre, una descripción, y qué datos necesita cada una, en un formato llamado JSON Schema.
2. El modelo lee tu pregunta y decide si alguna herramienta le sirve. Si sí, responde con un bloque estructurado: el nombre de la función y los argumentos.
3. Tu código ejecuta esa función de verdad — corre el comando, llama la API, lee el archivo. El modelo no toca nada de esto.
4. El resultado de esa ejecución se le devuelve al modelo.
5. El modelo usa ese resultado para responder — o para pedir otra herramienta más, si hace falta.

Es exactamente el mismo patrón, ya sea que el modelo pida leer un archivo, correr un comando de bash, o llamar a una API externa.

La analogía que lo deja claro: es la diferencia entre pedir comida contándole al mesero una historia larga ("algo tipo pasta, pero no muy pesado, con algo de picante, ya tú sabes") y llenar un formulario de pedido con casillas exactas: plato, tamaño, nivel de picante. La historia se puede malinterpretar. El formulario, no — o el mesero lo rechaza si falta un dato. Tool Calling es el formulario. Antes de que existiera, todos estábamos contándole historias al mesero.

Antes vs. después: por qué esto fue un salto real

Antes de que el tool calling nativo existiera, la única forma de lograr que un modelo "actuara" era un truco de prompt conocido como ReAct: le pedías que escribiera en texto plano algo como "Pensamiento: necesito el clima. Acción: buscar_clima(Boston)", y tu código tenía que leer ese texto con expresiones regulares y adivinar qué quiso decir.

	Antes (ReAct + regex)	Ahora (Tool Calling nativo)
Formato de salida	Texto libre, a veces con errores de sintaxis	JSON estructurado, garantizado por el proveedor
Qué pasaba si fallaba	Una comilla mal puesta rompía todo el parseo	El modelo no puede generar algo fuera del schema
Fiabilidad reportada	Muy variable, dependía del prompt	OpenAI reportó 100% de adherencia al schema con su función de Structured Outputs, frente a menos del 40% del enfoque anterior
Esfuerzo de desarrollo	Escribir y mantener parsers frágiles	Declarar el schema una vez, listo

Nota lo que cambió de fondo: antes tenías que adivinar qué quiso decir el modelo. Ahora el proveedor garantiza que la estructura sea válida — el modelo literalmente no puede generar un JSON mal formado, porque el sistema bloquea esa posibilidad token por token mientras genera.

Tool Calling, MCP y Skills: quién hace qué

Si ya leíste los blogs anteriores de esta serie, esta es la pieza que faltaba para que todo encaje:

Concepto	Responde a	Ejemplo
Tool Calling	¿Cómo pide el modelo ejecutar UNA acción?	El mecanismo mismo — el JSON estructurado
MCP	¿Cómo se descubren y exponen muchas herramientas de forma estandarizada?	Un servidor MCP de GitHub, con 20 tools disponibles
Skills	¿Cómo sabe el agente hacer bien una tarea con esas herramientas?	Un SKILL.md que le dice qué tools usar y en qué orden

Una tool MCP, cuando el agente decide usarla, se invoca exactamente con el mismo mecanismo de tool calling que cualquier otra herramienta nativa. MCP no reemplaza el tool calling — lo estandariza para que no tengas que inventar una integración distinta por cada servicio. Y un Skill no ejecuta nada por sí mismo: le dice al agente qué tools llamar y con qué criterio, pero la ejecución real sigue pasando por tool calling.

Cómo se ve esto en un agente de código real

En OpenCode, cada herramienta nativa — read, write, edit, bash, grep — está definida con un schema exacto de lo que necesita. Cuando armas una herramienta propia, se ve así:

// .opencode/tools/deploy-check.ts
import { tool } from "@opencode-ai/plugin"
import { z } from "zod"

export default tool({
  description: "Verifica que el build pase antes de un deploy. Úsalo antes de correr /release.",
  args: {
    entorno: tool.schema.string().describe("staging o production"),
  },
  async execute(args) {
    // acá va el código real que corre el chequeo
    return `Build verificado para ${args.entorno}`
  },
})

Nota que la description no es un detalle menor — es lo único que el modelo lee para decidir si esta herramienta le sirve para la tarea. Una descripción vaga ("chequea cosas") hace que el agente nunca la use, o la use mal.

El bucle agéntico: así nace un comando como /release

Un agente moderno no llama una sola herramienta y termina. Encadena varias, en un bucle: piensa → llama una tool → observa el resultado → piensa de nuevo → llama otra tool → hasta que la tarea está resuelta.

Así es como un comando del daily kit de Agent-ZAI, como /release, deja de ser magia y se vuelve algo entendible:

1. Tool call: bash corre git status — observa qué cambió.
2. Tool call: bash arma un commit atómico con el mensaje correcto.
3. Tool call: edit escribe la entrada nueva en el CHANGELOG.md, leyendo los commits anteriores.
4. Tool call: una tool custom postea el anuncio en el webhook de Discord.

Cada paso es una tool call distinta. Lo que hace que el comando se sienta "inteligente" no es magia — es que el agente decide el orden correcto y usa el resultado de un paso para alimentar el siguiente.

Cuando algo sale mal (y por qué)

El toolset sobrecargado. Anthropic documentó su propio caso: "hemos visto definiciones de tools consumir 134,000 tokens antes de optimizar" — solo describiendo qué herramientas existen, antes de que la conversación arrancara siquiera. Con demasiadas herramientas parecidas (enviar-notificacion-usuario vs. enviar-notificacion-canal), el modelo empieza a elegir mal. La regla práctica: mantener el set de herramientas activas entre 5 y 10; si crece más, hay que cargarlas bajo demanda, igual que un Skill.

Los parámetros inventados. El modelo puede pedir una herramienta real con datos que no existen — un estado que no es válido, un campo que nunca se declaró. Por eso una buena tool valida sus argumentos antes de ejecutar nada.

El caso más inquietante: el "tool call no autorizado". En enero de 2026, un desarrollador documentó un caso real con Claude Opus 4.6: el modelo alucinó tener acceso a una herramienta llamada read_secret que nunca le habían dado — inventó los parámetros, intentó ejecutarla, y como la función sí existía en el sistema (solo que no debía estar disponible para esa conversación), se ejecutó de verdad. El mismo comportamiento se reprodujo en otros modelos. La lección no es "no confíes en el modelo" — es que la validación de qué puede ejecutar un agente tiene que vivir en tu código, nunca solo en lo que le dijiste en el prompt.

Antes de armar tu próxima herramienta

# Checklist rápido para una tool bien diseñada

- [ ] ¿La description dice claramente CUÁNDO usarla, no solo qué hace?
- [ ] ¿El nombre se distingue claramente de otras tools similares?
- [ ] ¿Tienes menos de 10 tools activas al mismo tiempo?
- [ ] ¿Validas los argumentos antes de ejecutar, por si el modelo se equivoca?
- [ ] ¿La ejecución real está limitada por permisos en tu código, no solo por
      lo que le pediste en el prompt?

La próxima vez que un agente corra un comando, lea un archivo o llame una API por ti, ya sabes exactamente qué está pasando debajo: no es magia, es un JSON estructurado pidiendo permiso, y tu código decidiendo si se lo da.