GUÍA TÉCNICA
Tool calling: cómo utilizan herramientas los agentes de IA
Un agente no necesita recibir acceso directo a tus sistemas para poder trabajar con ellos.
El modelo puede solicitar una capacidad con argumentos estructurados; otra capa valida identidad, permisos y reglas, ejecuta la operación y devuelve el resultado. Entender esa separación es la base para diseñar herramientas útiles sin convertir cada integración en una superficie de autoridad ilimitada.
RESPUESTA RÁPIDA
Tool calling permite que un modelo solicite el uso de una herramienta mediante una llamada estructurada. En las herramientas definidas por la aplicación, el modelo normalmente no ejecuta la operación: propone una tool y sus argumentos; el sistema valida, autoriza y ejecuta, y devuelve el resultado. El schema ayuda con la forma de la llamada, pero no sustituye permisos ni reglas de negocio. MCP puede conectar herramientas, pero no es sinónimo de tool calling.
La pregunta importante no es solo «¿qué API puede llamar el agente?», sino qué capacidades ponemos a su alcance, quién valida cada solicitud y bajo qué condiciones puede producir un efecto real.
Qué es tool calling
Un modelo de lenguaje puede redactar, clasificar, resumir o razonar con la información que tiene en contexto. Pero para consultar un pedido real, crear un ticket, obtener una cotización o modificar un registro necesita acceder a capacidades que existen fuera del modelo.
Tool calling es el mecanismo que permite que el modelo solicite utilizar una de esas capacidades mediante una llamada estructurada.
La idea básica es:
modelo → herramienta solicitada + argumentos → ejecución → resultado → modelo
El término function calling se utiliza especialmente cuando la herramienta se describe como una función con parámetros estructurados. Tool calling o tool use es una forma más amplia de hablar del mismo patrón y puede abarcar funciones de aplicación, búsqueda, ejecución de código, archivos, herramientas alojadas por el proveedor o herramientas descubiertas mediante protocolos como MCP.
La herramienta no tiene que ser una API pública. Puede ser una función interna, una consulta a una base de datos, un servicio de búsqueda, un proceso de negocio o una interfaz controlada sobre otro sistema.
El harness también puede limitar cuánto decide el modelo. Algunas APIs permiten dejar la elección en modo automático, exigir que se use alguna herramienta, forzar una herramienta concreta, restringir el conjunto permitido o impedir el uso de tools para ese turno. Esto recuerda algo importante: tool calling no implica que toda decisión sobre herramientas pertenezca al modelo.
En un workflow, la aplicación puede decidir de antemano qué capacidades están disponibles y en qué paso. En un agente con mayor control dinámico, el modelo puede seleccionar entre varias herramientas según lo que observa. El mismo mecanismo técnico sirve para arquitecturas con grados de autonomía muy distintos.
La clave es que el modelo no necesita conocer cómo está implementada esa capacidad por dentro. Necesita saber qué puede pedir, con qué argumentos y qué resultado recibirá.
El modelo no ejecuta la herramienta
Esta es probablemente la distinción más importante de todo el artículo.
Cuando una herramienta pertenece a nuestra aplicación, el modelo no recibe las credenciales del CRM ni abre por sí mismo una conexión contra la base de datos. Lo habitual es que produzca una solicitud estructurada: qué herramienta quiere usar y qué argumentos propone.
Después, la aplicación o el harness que rodea al modelo puede:
- comprobar que la herramienta está disponible;
- validar la forma de los argumentos;
- aplicar identidad, permisos y reglas de negocio;
- solicitar una aprobación si corresponde;
- ejecutar la operación;
- devolver al modelo el resultado o el error.
OpenAI, Anthropic, Google y Microsoft documentan este mismo patrón general. Algunas plataformas ofrecen además herramientas alojadas por el propio proveedor —por ejemplo búsqueda o ejecución de código—, pero incluso en esos casos sigue siendo útil separar conceptualmente la decisión de usar una capacidad de la ejecución de esa capacidad.
Esta separación permite construir controles que no dependen de que el modelo «recuerde» una instrucción.
El modelo solicita; el sistema ejecuta
El tool call es una propuesta estructurada de uso. La validación, la autorización y la ejecución real pertenecen a la capa que rodea al modelo.
Equivalente textual del diagrama
- USUARIO: Petición
- MODELO: Decide solicitar una capacidad
- TOOL CALL: Nombre + argumentos
- VALIDACIÓN: Schema · policy · permisos
- EJECUTOR: Código / servicio
- SISTEMA: API · CRM · ERP · BD
- RESULTADO: Datos · confirmación · error
- MODELO: Siguiente decisión
Qué contiene una definición de herramienta
Una herramienta necesita una interfaz suficientemente clara para que el modelo pueda decidir cuándo utilizarla y construir sus argumentos.
Normalmente esa definición incluye:
- un nombre;
- una descripción;
- un esquema de parámetros;
- tipos de datos;
- campos obligatorios;
- valores permitidos cuando aplica;
- y, en algunos sistemas, un esquema de salida.
Imaginemos una capacidad:
get_order(order_id)
El modelo no necesita conocer tablas, joins, tokens de autenticación ni endpoints internos. Su contrato puede limitarse a algo parecido a: «recupera el estado de un pedido existente cuando dispongas de su identificador».
Esta abstracción es importante porque la interfaz de la herramienta puede permanecer estable aunque por debajo cambie la infraestructura.
La descripción de una tool también es parte de la arquitectura
La descripción no es una nota decorativa para desarrolladores. Forma parte de la información que ayuda al modelo a elegir correctamente entre varias capacidades.
Una herramienta llamada simplemente search obliga al modelo a deducir demasiado.
Una interfaz como crm_search_customer_by_email ya delimita mejor su intención. Y una descripción puede añadir cuándo usarla, cuándo no usarla, qué representa cada parámetro y qué limitaciones tiene.
Anthropic dedica una parte importante de su documentación de tool use precisamente a las descripciones y recomienda explicar con detalle el propósito y las condiciones de uso de cada herramienta.
Cuando existen varias herramientas parecidas, nombres y descripciones ambiguos pueden producir:
- selección de la tool equivocada;
- argumentos incorrectos;
- llamadas innecesarias;
- o ausencia de llamada cuando sí era necesaria.
Una API perfecta detrás de una herramienta mal definida puede seguir produciendo tool calling deficiente.
Un schema válido no significa una acción válida
Las plataformas modernas pueden forzar que una llamada respete un schema compatible. Eso reduce problemas como nombres de campos incorrectos, tipos inesperados o estructuras incompletas.
Pero resolver la forma no resuelve la autorización.
Una llamada como:
refund_order(order_id="1234", amount=25000)
puede ser perfectamente válida desde el punto de vista estructural y seguir siendo inaceptable para el negocio.
Antes de ejecutar todavía puede ser necesario comprobar:
- que el pedido existe;
- que pertenece a la identidad correcta;
- que su estado permite un reembolso;
- que el importe coincide con una fuente fiable;
- que la credencial utilizada tiene permiso;
- que no se supera un límite;
- que la operación no se ejecutó ya;
- y que existe aprobación humana si la política la exige.
Por eso conviene separar dos capas: validación sintáctica y validación semántica o empresarial.
Schema y autorización resuelven problemas distintos
Una llamada puede respetar perfectamente los tipos y seguir intentando una operación que la identidad, el estado o la política no permiten.
Equivalente textual del diagrama
Schema: valida nombre de campos, tipos, required y enumeraciones.
Policy: valida identidad, ownership, estado, límites, permisos y aprobaciones.
Una herramienta también define capacidad y autoridad
Exponer una herramienta amplía lo que el sistema puede intentar hacer.
No es lo mismo ofrecer:
read_order
que:
update_order
o:
refund_order
o:
delete_order
Microsoft resume esta idea señalando que el riesgo de un agente está estrechamente relacionado con las herramientas y permisos a los que tiene acceso. OWASP utiliza el término Excessive Agency para describir sistemas con funcionalidad, permisos o autonomía mayores de los necesarios.
El principio de diseño debería ser parecido al de cualquier otro sistema sensible: mínimo privilegio necesario para la tarea. En autonomía en agentes de IA desarrollamos cómo convertir ese principio en políticas por acción, scopes, presupuestos y mecanismos de parada.
Si un agente solo necesita consultar pedidos, no tiene por qué disponer de una herramienta genérica capaz de editar o borrar esos mismos pedidos.
Y si una capacidad de escritura es necesaria, puede estar acotada por recurso, estado, importe, entorno o usuario.
Diseña tools para tareas, no copies la API entera
Una API interna suele estar diseñada para aplicaciones y desarrolladores. Su estructura no tiene por qué ser la mejor interfaz para un modelo.
Un extremo es crear una tool por cada endpoint:
get_customer · find_customer · lookup_customer · get_customer_by_id · get_customer_by_email...
Cuando el catálogo crece, aparecen costes de contexto y ambigüedad. OpenAI recomienda de forma orientativa mantener un conjunto inicial contenido y utilizar mecanismos de búsqueda o carga diferida cuando el número de funciones aumenta. La cifra concreta que aparece en su documentación no debe tratarse como un límite universal.
El extremo contrario es una mega-tool genérica:
crm(action, entity, operation, mode, target...)
Eso puede ocultar demasiados comportamientos detrás de una única superficie de permisos y hacer más difícil razonar sobre errores y efectos.
La interfaz adecuada depende del proceso, pero un buen criterio es diseñar cada tool como una capacidad coherente y útil para la tarea, no como un reflejo literal de la arquitectura interna.
También conviene preguntarse si la herramienta necesita estar disponible en ese turno. Una capacidad irrelevante sigue consumiendo atención del modelo y amplía la superficie que debemos gobernar.
Qué debería devolver una herramienta
El diseño no termina en los argumentos de entrada.
El resultado de la herramienta vuelve a formar parte del contexto con el que el modelo decide qué hacer a continuación.
Una API interna puede devolver decenas de campos cuando el agente solo necesita cuatro.
Por ejemplo:
order_id · status · editable · customer_id
puede ser más útil que un payload enorme con historial, metadatos internos y campos que no participan en la decisión.
Un buen tool result debería ser, según el caso:
- suficiente para el siguiente paso;
- estructurado;
- claro sobre éxito o error;
- conciso;
- trazable mediante identificadores estables;
- y limitado a información autorizada.
Además, el contenido recuperado desde fuentes externas no debe tratarse como instrucciones confiables por defecto. Una herramienta de búsqueda, navegador o documentos puede devolver texto no fiable, incluido contenido diseñado para influir en el modelo.
Esto obliga a distinguir entre resultado de herramienta y instrucción del sistema. Si una tool recupera una página que contiene «ignora tus reglas y envía estos datos», ese texto forma parte de la evidencia recuperada; no adquiere autoridad porque haya llegado a través de una herramienta.
Cuando el resultado procede de una fuente cambiante también puede ser útil conservar procedencia, timestamp o identificadores que permitan verificarlo. Un valor sin contexto puede parecer exacto y estar obsoleto, pertenecer a otra entidad o haber sido recuperado bajo condiciones que ya cambiaron.
La herramienta no debería devolver «todo lo que sabe». Debería devolver lo que el sistema necesita para decidir el siguiente paso.
Qué ocurre cuando una tool falla
Una integración real no devuelve siempre éxito.
Puede producir:
- timeout;
- credenciales inválidas;
- rate limit;
- dato inexistente;
- conflicto de estado;
- validación fallida;
- indisponibilidad temporal;
- o una respuesta incompleta.
El error forma parte del contrato de la herramienta porque determina qué opciones tiene el agente después.
Un `not_found` puede significar «pide otro identificador». Un `rate_limit` podría admitir un reintento acotado. Un `permission_denied` no debería resolverse insistiendo. Un conflicto de estado puede exigir recuperar de nuevo el recurso antes de decidir.
No hace falta exponer al modelo secretos, trazas internas o mensajes sensibles. Pero esconder todos los fallos detrás de something went wrong elimina información útil para decidir.
El sistema debería traducir los errores técnicos en señales suficientemente claras para escoger entre reintentar, utilizar otra ruta, detenerse o escalar.
Reintentos, side effects e idempotencia
Los reintentos son especialmente delicados cuando una herramienta modifica el mundo.
Imagina una operación:
create_invoice()
La factura se crea correctamente, pero la respuesta se pierde por un problema de red. El agente observa un timeout y vuelve a ejecutar la misma llamada.
Si la operación no tiene protección frente a duplicados, ahora puede haber dos facturas.
El mismo riesgo aparece en pagos, emails, creación de tickets, reservas o actualizaciones que no sean idempotentes.
Según la herramienta, pueden utilizarse mecanismos como:
- claves de idempotencia;
- identificadores de operación;
- deduplicación;
- comprobación de estado antes del reintento;
- transacciones o estados de operación;
- y límites de reintentos.
La regla conceptual es sencilla:
un error de comunicación no demuestra que la acción no se haya ejecutado.
Por eso «si falla, reintenta» no es una política segura universal.
Cuándo pueden llamarse varias herramientas en paralelo
Algunos modelos y harnesses pueden solicitar varias herramientas en un mismo turno. Esto puede reducir latencia cuando las operaciones son independientes.
Por ejemplo, consultar simultáneamente disponibilidad de dos servicios que no comparten estado puede ser razonable.
Pero paralelizar deja de ser inocuo cuando:
- la segunda llamada depende del resultado de la primera;
- dos operaciones modifican el mismo recurso;
- existe un orden contractual;
- o una acción puede invalidar la otra.
La posibilidad técnica de ejecutar en paralelo no implica que el proceso lo permita.
Tool calling y MCP no son lo mismo
La expansión de Model Context Protocol ha hecho que ambos conceptos aparezcan con frecuencia en la misma conversación, pero resuelven capas diferentes.
Tool calling describe el mecanismo por el que el modelo o su harness solicita utilizar una capacidad y recibe posteriormente un resultado.
MCP es un protocolo que permite a hosts y clientes descubrir y conectarse con herramientas, recursos y otras capacidades expuestas por servidores compatibles.
En la especificación actual de MCP siguen existiendo operaciones como tools/list y tools/call. Un host puede descubrir herramientas mediante MCP, presentarlas al modelo y convertir una decisión del modelo en una invocación al servidor correspondiente.
Por tanto:
MCP puede transportar y exponer herramientas; no sustituye el concepto de tool calling.
La utilidad de MCP está en estandarizar la conexión entre un host y capacidades externas. Puede evitar integraciones propietarias distintas para cada combinación de aplicación y proveedor, pero no decide por sí mismo qué herramientas merece ver un agente ni qué credenciales debe recibir el servidor.
El host sigue teniendo que gobernar cuestiones como catálogo permitido, identidad, autorización, confirmaciones y aislamiento. De hecho, descubrir una herramienta automáticamente no significa que deba exponerse automáticamente al modelo.
MCP también define anotaciones que pueden describir una herramienta como de solo lectura, destructiva o idempotente. Estas anotaciones son útiles como metadata y señales para la interfaz, pero no deben confundirse con controles de autorización.
Que una herramienta se anuncie como `readOnly` no sustituye autenticación, permisos ni policy enforcement real. Del mismo modo, una operación larga puede adoptar mecanismos asíncronos o devolver una tarea que se consulta después; que una tool exista no obliga a que toda ejecución sea inmediata y sin estado.
Tool calling y MCP no son la misma capa
MCP puede ser el protocolo con el que un host descubre y conecta herramientas, mientras tool calling describe la solicitud de uso que surge en el bucle del modelo.
Equivalente textual del diagrama
- MODELO: Decide usar una capacidad
- TOOL CALL: Solicitud estructurada
- HOST / CLIENT: Presenta y gobierna tools
- MCP: tools/call
- MCP SERVER: Expone la herramienta
- TOOL: Ejecuta o conecta el servicio
Tool calling no convierte automáticamente un workflow en agente
Una automatización puede usar un modelo para producir argumentos y llamar después a una herramienta dentro de una ruta completamente predefinida.
Por ejemplo:
email → extraer ID → get_order → regla → actualizar cola
Aquí existe tool calling, pero el recorrido global sigue controlado por el workflow.
La diferencia aparece cuando el modelo tiene capacidad dinámica para decidir cuestiones como:
- si necesita una herramienta;
- qué herramienta usar;
- qué hacer con su resultado;
- si necesita otra observación;
- qué ruta tomar;
- y cuándo terminar.
Por eso tool calling es una capacidad que utilizan muchos agentes, pero no es una prueba suficiente de que la arquitectura completa sea agéntica.
Cuándo una tool debería pedir aprobación humana
No todas las llamadas necesitan intervención humana.
Leer el estado de un pedido y cancelarlo son acciones diferentes. Preparar un borrador y enviarlo a un cliente también.
Un sistema puede dejar automática una capacidad de bajo impacto y colocar un gate antes de ejecutar una acción que implique dinero, datos sensibles, comunicación externa, irreversibilidad o un alcance elevado.
El patrón sería:
tool call → policy → approval → executor
OpenAI y Microsoft soportan patrones de aprobación de herramientas en sus entornos de agentes. Pero el criterio sobre qué se aprueba pertenece al proceso.
La persona no reemplaza permisos ni validaciones. La aprobación es una capa adicional de autoridad antes de producir el efecto.
Cómo evaluar el uso de herramientas
Tool calling tiene una ventaja importante desde el punto de vista de evaluación: muchas propiedades son observables y verificables.
Además de evaluar la respuesta final, la traza puede registrar qué catálogo estaba disponible, qué tool eligió el modelo, los argumentos normalizados, qué decisión tomó la policy, qué ejecutó realmente el sistema y qué resultado volvió al modelo. Esto permite separar un error de razonamiento de un error de integración o de permisos.
Podemos comprobar de forma determinista:
- si llamó a la herramienta correcta;
- si utilizó una herramienta prohibida;
- qué argumentos propuso;
- si respetó un límite;
- cuántas veces llamó;
- si duplicó un side effect;
- si interpretó correctamente un error;
- si solicitó aprobación cuando correspondía;
- y si el resultado final quedó realmente en el estado esperado.
Esto conecta la herramienta con una traza: solicitud, policy decision, ejecución, resultado y siguiente decisión.
Una tool bien diseñada debería ser no solo utilizable, sino también observable y evaluable.
Un framework para diseñar una herramienta antes de exponerla
Antes de añadir una nueva tool al catálogo del agente, conviene responder estas preguntas.
La salida del framework no debería ser simplemente una función con un schema.
Debería ser un contrato de capacidad: qué puede solicitar el agente, con qué datos, bajo qué autoridad, cómo se comporta ante errores y qué evidencia queda después de ejecutar.
Eso convierte el tool calling en una interfaz gobernable entre un sistema probabilístico y operaciones que necesitan reglas deterministas.
Preguntas frecuentes
¿Qué diferencia hay entre tool calling y function calling?
Function calling es una forma muy común de tool calling en la que la capacidad se expresa como una función con argumentos estructurados. Tool calling es un término más amplio que también puede incluir herramientas alojadas por el proveedor, búsqueda, código, MCP u otras capacidades.
¿El modelo ejecuta realmente la función?
En las herramientas definidas por la aplicación, normalmente no. El modelo produce una solicitud estructurada; la aplicación o infraestructura valida y ejecuta la operación y devuelve el resultado. Algunas herramientas alojadas por el proveedor se ejecutan en infraestructura del propio proveedor, pero siguen separando decisión y ejecución.
¿Qué es un tool schema?
Es el contrato estructurado que describe los argumentos que admite una herramienta: nombres, tipos, campos obligatorios, enumeraciones y otras restricciones compatibles. Ayuda al modelo a generar llamadas válidas, pero no sustituye reglas de negocio ni permisos.
¿Qué significa strict tool use?
Es un modo disponible en algunas plataformas para exigir que la llamada respete de forma estricta el schema compatible. Reduce errores de forma, pero un argumento estructuralmente válido puede seguir siendo semánticamente incorrecto o no estar autorizado.
¿Tool calling convierte un chatbot o workflow en agente?
No por sí solo. Un workflow fijo puede utilizar herramientas en pasos predeterminados. El comportamiento agéntico depende de cuánto control dinámico tenga el modelo sobre qué herramienta usar, qué hacer con el resultado, qué ruta seguir y cuándo terminar.
¿Qué diferencia hay entre tool calling y MCP?
Tool calling describe cómo un modelo o harness solicita el uso de una herramienta. MCP es un protocolo para descubrir, describir y conectar herramientas y otros recursos. Un host puede presentar al modelo herramientas descubiertas por MCP y convertir la decisión del modelo en una llamada MCP.
¿Qué pasa si una herramienta falla?
El resultado debería distinguir el tipo de fallo para que el sistema pueda decidir si reintenta, utiliza otra ruta, pide información, se detiene o escala. Los reintentos deben estar acotados y las operaciones con efectos necesitan especial cuidado para evitar duplicados.
¿Cuándo debe aprobar una persona una llamada a herramienta?
Cuando el efecto, la irreversibilidad, el dinero, los datos, la comunicación externa o el alcance justifican autoridad humana antes de ejecutar. La aprobación es una capa adicional; no sustituye permisos, validaciones ni límites técnicos.
Fuentes y lecturas recomendadas
Estas fuentes sostienen la separación entre solicitud y ejecución, el papel de schemas y descripciones, la gobernanza de herramientas, la validación de permisos y la diferencia entre tool calling y MCP.
- 01OpenAI — Function calling (enlace externo)developers.openai.com
Describe el ciclo de function calling, tool choice, llamadas múltiples y strict mode.
- 02OpenAI — Agents API Functions (enlace externo)developers.openai.com
Explica que el agente solicita una función de la aplicación y que el código externo ejecuta la operación y devuelve el resultado.
- 03Anthropic — How tool use works (enlace externo)platform.claude.com
Separa explícitamente la solicitud estructurada del modelo de la ejecución real de la herramienta.
- 04Anthropic — Define tools (enlace externo)platform.claude.com
Documenta nombre, descripción, input schema, ejemplos y buenas prácticas para interfaces de herramientas.
- 05Google Gemini — Function calling (enlace externo)ai.google.dev
Confirma el patrón de selección de función, generación de parámetros, ejecución externa y devolución del resultado.
- 06Microsoft Foundry — Function calling (enlace externo)learn.microsoft.com
Documenta herramientas definidas por la aplicación y el ciclo de ejecución alrededor del modelo.
- 07Microsoft — Govern tools (enlace externo)learn.microsoft.com
Relaciona el riesgo del agente con las herramientas y permisos disponibles y refuerza el principio de control de capacidades.
- 08OWASP — Excessive Agency (enlace externo)genai.owasp.org
Describe riesgos de funcionalidad, permisos y autonomía excesivos en sistemas con herramientas.
- 09Model Context Protocol — actualización 2026-07-28 (enlace externo)modelcontextprotocol.io
Mantiene el modelo de descubrimiento e invocación de herramientas mediante mecanismos como tools/list y tools/call.
- 10Model Context Protocol — Tool annotations (enlace externo)modelcontextprotocol.io
Explica anotaciones de herramientas como read-only, destructive o idempotent y su carácter de metadata/hints, no de autorización.
Sobre el autor
Elvis Mendoza, fundador de Agentes Como Servicio. Trabaja en el diseño de producto, la arquitectura de soluciones, el diseño de agentes y flujos de trabajo y la construcción de software asistida por IA para conectar procesos, datos, herramientas y supervisión humana alrededor de necesidades empresariales concretas.
¿Qué debería poder hacer realmente tu agente en tus sistemas?
Antes de conectar APIs conviene diseñar herramientas, permisos, validaciones y límites alrededor de cada acción que el agente puede solicitar.
En Agentes Como Servicio diseñamos estas capacidades como parte de la arquitectura del proceso: interfaces claras, ejecución controlada, trazabilidad y autoridad proporcional al efecto real de cada acción.
Solicitar acceso