Tool calling: cómo usan herramientas los agentes de IA
El tool calling (también llamado function calling) es la capacidad central con la que un agente de IA va más allá de la simple generación de texto: el LLM recibe descripciones legibles por máquina de herramientas (tools, API, fuentes de datos) y, cuando lo necesita, genera una llamada estructurada con parámetros que la aplicación ejecuta. El resultado vuelve al modelo, que a continuación planifica el siguiente paso. Así, el LLM deja de ser un generador de texto y se convierte en un actor que percibe, decide y desencadena acciones en sistemas reales.
De un vistazo
- El tool calling es el puente entre el LLM y el mundo exterior: el modelo devuelve una llamada estructurada (nombre de la función más parámetros en JSON Schema), la aplicación la ejecuta y devuelve el resultado como observación al bucle de razonamiento (Perceive-Reason-Act-Observe).
- El LLM no llama a las herramientas por sí mismo: propone la llamada. La ejecución, la validación y los permisos corresponden al código que lo rodea. Ahí es precisamente donde deben ir los permisos de las herramientas, la validación de entradas y el human-in-the-loop en las acciones irreversibles.
- La fuente de errores más frecuente no son los modelos, sino las definiciones de herramientas poco claras o solapadas. Nombres precisos, descripciones inequívocas y una cláusula de «cuándo no usarla» tienen más efecto que cualquier truco de prompt.
- En 2026, la buena práctica son 3-7 herramientas cargadas activamente; a partir de unas 10 herramientas empieza una degradación medible en la elección de herramienta. Un descubrimiento dinámico de herramientas, en lugar de cargarlas todas de forma estática, mantiene la selección precisa.
- El Model Context Protocol (MCP) es el estándar abierto para conectar herramientas: a través de servidores MCP, un agente puede acceder de forma estandarizada a herramientas y fuentes de datos sin escribir código de integración propio para cada conexión.
- La seguridad no es un añadido: scopes de mínimo privilegio por herramienta, listas de permitidos, pasos de confirmación en acciones de escritura o irreversibles y observabilidad sobre todas las llamadas a herramientas son obligatorios en cuanto un agente toca sistemas reales.
¿Qué es el tool calling?
El tool calling (también function calling o tool use) es la capacidad central con la que un agente de IA va más allá de la mera generación de texto. El LLM recibe descripciones legibles por máquina de herramientas, funciones, API y fuentes de datos, y cuando lo necesita genera una llamada estructurada con parámetros que la aplicación circundante ejecuta. El resultado vuelve al modelo como observación, y este planifica el siguiente paso. Así, el LLM deja de ser un generador de texto y se convierte en un actor que pasa a la acción.
Las tres respuestas clave, de entrada:
- ¿Qué ocurre a nivel técnico? El modelo no devuelve texto corrido, sino una llamada estructurada: un nombre de función más argumentos en formato JSON. La aplicación ejecuta esa llamada y devuelve el resultado al modelo.
- ¿Quién hace realmente la llamada? El LLM no. El modelo propone una llamada; la ejecución real, incluida la comprobación de permisos y la validación, está en el código circundante. Esta separación es la base de cualquier arquitectura de seguridad.
- ¿Por qué es la capacidad central de los agentes? Sin tool use, un LLM sigue siendo un asesor que solo sabe hablar. Solo el tool calling convierte el motor de razonamiento en un agente que percibe, planifica, actúa y observa: el bucle completo Perceive → Reason → Act → Observe.
Un ejemplo concreto: comprobar la disponibilidad y reservar una cita
Supongamos que un agente debe reservar una cita de asesoramiento para un cliente. El modelo recibe dos herramientas, cada una con nombre, descripción y un esquema de parámetros:
get_availability(date: string): devuelve los huecos libres de una fecha.book_appointment(slot_id: string, customer_email: string): reserva un hueco.
El flujo:
- Reason: El usuario escribe «¿Queda alguna cita libre el martes que viene por la mañana?». El modelo reconoce que primero necesita la disponibilidad.
- Act: En lugar de una respuesta de texto, el modelo devuelve una llamada estructurada:
get_availability(date: "2026-06-16"). - Execute: La aplicación, no el modelo, llama a la API real del calendario y recibe dos huecos libres.
- Observe: El resultado (
["09:00", "10:30"]) se devuelve al modelo como observación. - Loop: El modelo formula una pregunta de seguimiento o, tras la confirmación, llama a
book_appointment(...).
Importante: el paso de escritura (book_appointment) es irreversible en sus efectos. Justo aquí debe ir un paso human-in-the-loop o de confirmación antes de que el agente ejecute la acción.
La mecánica del function calling
En todas las API de LLM habituales, el function calling sigue el mismo patrón básico, sea cual sea el proveedor:
- Definición de la herramienta: Cada herramienta se describe mediante un JSON Schema: nombre, una descripción en lenguaje natural de su finalidad y los parámetros tipados. Esta descripción es la única información con la que el modelo decide si usa la herramienta y cómo la usa.
- Selección de la herramienta: En el paso de razonamiento, el modelo elige la herramienta adecuada y rellena los parámetros. Para ello usa exclusivamente las descripciones proporcionadas y el contexto de la conversación.
- Salida estructurada: En lugar de prosa, el modelo entrega un objeto legible por máquina. Si está activo un modo estricto o Structured Outputs, el proveedor garantiza mediante constrained decoding que los argumentos se ajusten al esquema. Sin ese modo, el modelo puede generar argumentos no válidos. En ambos casos, el ejecutor valida los parámetros, porque unos argumentos conformes al esquema no garantizan ni valores admisibles ni los permisos necesarios.
- Ejecución & observación: La llamada se ejecuta, el resultado se devuelve y el bucle continúa hasta que se alcanza el objetivo o salta un criterio de parada (límite de iteraciones, error, guardrail).
La conclusión práctica más importante: cuando un agente actúa mal, la causa no suele estar en el modelo, sino en la definición de la herramienta. Anthropic formula la pauta sin rodeos: si un ingeniero humano no puede decir con claridad qué herramienta usar en una situación, un agente tampoco puede.
De ahí se derivan tres reglas de diseño:
- Limitar el número de herramientas: En 2026, la buena práctica son 3-7 herramientas cargadas activamente; a partir de unas 10 herramientas empieza una degradación medible en la elección de herramienta. En las evaluaciones internas de MCP de Anthropic, la búsqueda dinámica de herramientas elevó la precisión en la selección de herramientas del 49 % al 74 % (Opus 4) y del 79,5 % al 88,1 % (Opus 4.5).
- Evitar solapamientos: Dos herramientas que podrían responder de forma plausible a la misma petición son un problema que ningún prompt resuelve. Una cláusula clara de «cuándo no usarla» en la descripción es el componente más eficaz y, a la vez, el que más se olvida.
- Nombres y parámetros inequívocos: Los nombres descriptivos y los parámetros con tipado estricto reducen las malinterpretaciones antes de que surjan.
La relación con MCP: un estándar para conectar herramientas
Sin un estándar, cada integración de herramientas hay que cablearla por separado: por agente, por API y por fuente de datos, cada una con su propio código de integración. El Model Context Protocol (MCP) resuelve este problema M×N: define un protocolo unificado con el que un agente (cliente MCP) se comunica de forma estandarizada con herramientas y fuentes de datos (servidores MCP).
Así, MCP es el «cómo» detrás del tool calling en cuanto las herramientas ya no están en el propio código, sino que se ofrecen como servidores reutilizables. Un servidor MCP proporciona herramientas, recursos y prompts; el agente los descubre en tiempo de ejecución y los llama mediante el mismo patrón de function calling. El grado de madurez es alto: la especificación de MCP actual lleva la versión 2026-07-28 y trabaja con peticiones sin estado y autocontenidas. En diciembre de 2025, el proyecto se transfirió a la Linux Foundation (Agentic AI Foundation), y ya existen más de 10.000 servidores MCP.
Mientras MCP estandariza la conexión agente ↔ herramienta, el protocolo complementario A2A (Agent-to-Agent) regula la comunicación agente ↔ agente en sistemas multiagente. Desde junio de 2025, A2A también está en manos de la Linux Foundation y cuenta con el respaldo de más de 150 organizaciones. Para el tool calling puro, el estándar relevante es MCP; A2A solo cobra importancia cuando varios agentes colaboran.
Seguridad: los permisos de herramientas son una obligación, no una opción
En cuanto un agente toca sistemas reales (escribe en bases de datos, envía correos electrónicos, ejecuta código), la seguridad de las herramientas se convierte en el requisito central. La buena noticia: como el LLM solo propone las llamadas y el código circundante las ejecuta, el punto de control está justo donde debe estar.
Aspecto | Riesgo sin protección | Medida |
|---|---|---|
Permisos (scopes) | El agente obtiene acceso total mediante un token de API | Mínimo privilegio: por herramienta, solo los scopes estrictamente necesarios; credenciales separadas para cada herramienta |
Validación de llamadas | El modelo genera parámetros no permitidos o dañinos | Listas de permitidos, validación del esquema y de los rangos de valores en el ejecutor, no en el modelo |
Acciones irreversibles | El agente borra, reserva o envía sin control | Human-in-the-loop / paso de confirmación para llamadas de escritura e irreversibles |
Prompt injection / tool injection | Una respuesta manipulada de una herramienta dirige al agente | Aislar la salida no confiable, cuarentena, no tratar nunca como una orden una salida de herramienta sin verificar |
Trazabilidad | Los fallos de comportamiento no se pueden reconstruir | Observabilidad: registrar cada llamada a herramienta con sus parámetros, su resultado y el contexto de decisión |
Hay tres errores prácticos especialmente frecuentes: tratar a los agentes como deterministas, aunque la elección de herramienta es probabilística; no tener observabilidad, de modo que los errores del bucle pasan desapercibidos; y no prever un human-in-the-loop en las acciones irreversibles. En contextos europeos sensibles al cumplimiento normativo se suma otro punto: las acciones de escritura sobre datos personales implican obligaciones del RGPD, y las decisiones automatizadas con efectos jurídicos pueden entrar en el ámbito del art. 22 del RGPD (a título informativo, no constituye asesoramiento jurídico).
Conclusión
El tool calling es el mecanismo que convierte un LLM en un agente: el modelo propone llamadas estructuradas, el código las ejecuta y el resultado impulsa el siguiente paso. La calidad se decide en tres puntos: definiciones de herramientas precisas y sin solapamientos, un conjunto activo de herramientas reducido (3-7) con descubrimiento dinámico, y una arquitectura de seguridad basada en el mínimo privilegio, la validación, los pasos de confirmación y la observabilidad. MCP aporta el estándar abierto que lleva la conexión de herramientas de integraciones aisladas a servidores reutilizables. Si dominas estos fundamentos, construyes agentes que actúan en producción de forma fiable y controlada.
Abre el chat con un prompt ya preparado.
Preguntas frecuentes
¿Qué diferencia hay entre tool calling y function calling?
¿El LLM llama a las herramientas por sí mismo?
¿Qué tiene que ver MCP con el tool calling?
¿Cuántas herramientas debería tener un agente a la vez?
¿Cómo proteges las llamadas a herramientas?
¿Cuál es la fuente de errores más frecuente en el tool calling?
¿Quieres profundizar?
Recibe nuevos análisis directamente en tu bandeja de entrada o descubre cómo aplicamos este conocimiento en empresas.