Tool calling: cómo un agente de IA llama a herramientas externas

Sin tool calling, un modelo de lenguaje solo sabe hacer una cosa: producir texto a partir de texto. No puede consultar una base de datos actualizada, ni enviar un mensaje, ni activar una acción en un software de terceros. El tool calling es el puente que conecta un modelo con un sistema externo. Es lo que transforma un modelo que conversa en un agente de IA capaz de actuar, la pieza básica detrás de todo agente autónomo.

Definición detallada

El tool calling, también llamado function calling, designa la capacidad de un modelo de lenguaje de responder a una solicitud no solo con texto, sino con una solicitud estructurada de ejecutar una función precisa, con argumentos completados según un esquema definido de antemano. La documentación de Anthropic describe el principio así: el modelo determina si debe llamar a una herramienta según la solicitud y la descripción de la herramienta, y devuelve una llamada estructurada que la aplicación ejecuta (del lado del cliente) o que el proveedor ejecuta él mismo (del lado del servidor, para ciertas herramientas integradas). La documentación de OpenAI, que popularizó el término function calling en 2023, describe un mecanismo idéntico: el modelo responde con una llamada de función legible por una máquina en lugar de con texto libre, y le corresponde a la aplicación ejecutarla.

Los dos proveedores de referencia coinciden en la definición de fondo: una función se describe mediante un nombre, una descripción en lenguaje natural, y un esquema JSON que lista sus parámetros esperados. El modelo se apoya únicamente en estos tres elementos para decidir si debe llamar a la herramienta y cómo completar sus argumentos. No existe una divergencia significativa entre los dos enfoques sobre este principio básico; las diferencias están en los detalles de implementación (formatos de llamada paralela, herramientas ofrecidas de forma nativa por el proveedor, gestión de errores).

El tool calling es lo que distingue a un simple chatbot de un sistema capaz de actuar sobre el mundo real: consultar una base de datos, buscar en la web, escribir en un archivo, enviar un mensaje, activar un pago. También es la pieza básica que hace posible el protocolo MCP, pensado para estandarizar la forma en que las herramientas se describen y se exponen a un modelo.

Cómo funciona

El desarrollo de una llamada a herramienta siempre sigue el mismo esquema en varios pasos. Primero, la aplicación define una lista de herramientas disponibles para el modelo, cada una con su nombre, su descripción y su esquema de argumentos. Después, el modelo recibe la solicitud del usuario junto con esa lista de herramientas, y decide, según el contexto, si debe responder directamente en texto o solicitar la ejecución de una herramienta.

Si elige llamar a una herramienta, el modelo devuelve una respuesta estructurada que contiene el nombre de la herramienta y los valores de sus argumentos, sin ejecutar nada él mismo. Es la aplicación la que recibe esta solicitud, ejecuta realmente la acción (llamar a una API, leer una base, escribir un archivo), y luego devuelve el resultado al modelo en una forma que este puede leer. El modelo continúa entonces su respuesta apoyándose en ese resultado, y puede encadenar varias llamadas a herramientas sucesivas si la tarea lo requiere.

Esta separación es importante para la seguridad: el modelo nunca ejecuta código él mismo, solo propone una llamada. Es la aplicación la que mantiene el control sobre lo que realmente se ejecuta, y puede rechazar una llamada si no se cumplen las condiciones.

Ejemplo concreto con Atako

En Atako, el tool calling es el núcleo del funcionamiento de un agente. Cada integración conectada (Slack, Notion, GitHub, HubSpot, y una cuarentena más) expone un conjunto de acciones precisas, como post_message en Slack o create_issue en GitHub, que el agente puede llamar cuando considera que la tarea lo requiere.

Pero en Atako, una llamada a herramienta nunca se ejecuta directamente. Primero pasa por un control de permisos: la plataforma verifica que existe un «grant» para ese agente y esa conexión en concreto, que la acción solicitada figura en la lista de acciones autorizadas de ese grant, y que el alcance concedido (solo lectura o lectura-escritura) cubre bien la acción en cuestión. Si no se cumple alguna de estas condiciones, la llamada se rechaza y el fallo queda registrado. Esta ruta de decisión, agente que propone una llamada y luego plataforma que verifica antes de ejecutar, es exactamente la lógica de seguridad que el tool calling permite implementar: el modelo propone, la infraestructura decide.

Errores frecuentes

Un error habitual consiste en creer que el modelo ejecuta él mismo la herramienta que llama. Nunca es el caso: el modelo produce una solicitud estructurada, siempre es una aplicación o una plataforma la que ejecuta realmente la acción y puede, en cualquier momento, rechazarla.

Segundo error: pensar que dar acceso a una herramienta a un modelo equivale a darle un acceso total e ilimitado a ese servicio. Un sistema de tool calling bien diseñado limita con precisión las acciones disponibles, con permisos por acción y por alcance, en lugar de un acceso genérico «todo o nada».

Tercer error: subestimar la importancia de la descripción de la herramienta. El modelo solo dispone del nombre, la descripción y el esquema de argumentos para decidir cuándo y cómo llamar a una herramienta. Una descripción vaga o ambigua produce llamadas mal elegidas o argumentos incorrectos, incluso con un modelo potente.

Por último, algunos confunden tool calling y MCP. El tool calling es el mecanismo básico, presente desde 2023 en los grandes proveedores de modelos. MCP es un protocolo más reciente que estandariza la forma en que las herramientas se describen y se conectan a un modelo, para evitar tener que desarrollar de nuevo una integración distinta para cada herramienta y cada proveedor.