Qué es tool calling y por qué importa en agentes de IA

Tool calling es la capacidad de un modelo de IA para pedir la ejecución de una herramienta externa. En vez de responder solo con texto, el modelo puede indicar que necesita llamar una función, consultar una API, buscar información o ejecutar una acción.

Es una pieza central de los agentes de IA. Sin tool calling, un modelo conversa. Con tool calling, puede operar sistemas reales bajo reglas definidas.

Tool calling vs function calling

Function calling fue el nombre común para describir llamadas estructuradas a funciones. Tool calling es un concepto más amplio: la herramienta puede ser una función local, una API REST, un buscador web, un servidor MCP, un navegador, una base de datos o un sistema interno corporativo.

En ambos casos, el flujo es similar:

1. defines las herramientas disponibles con su esquema de parámetros,
2. el modelo decide si necesita una herramienta para responder,
3. devuelve una llamada estructurada (nombre + argumentos),
4. tu sistema ejecuta la herramienta,
5. el resultado vuelve al modelo como contexto,
6. el modelo responde al usuario o continúa el flujo.

El modelo no ejecuta código por sí mismo. Solicita una acción. Tu aplicación decide si la ejecuta y cómo.

Ejemplo práctico

Supongamos que el usuario pregunta:

¿Cuántos tickets abiertos tiene el cliente Acme?

El modelo podría pedir una herramienta:

{
  "tool": "get_open_tickets",
  "arguments": {
    "customer": "Acme"
  }
}

Tu backend ejecuta esa función, consulta la base de datos y devuelve:

{
  "openTickets": 7,
  "urgent": 2
}

Luego el modelo redacta una respuesta natural con esos datos: "El cliente Acme tiene 7 tickets abiertos, de los cuales 2 son urgentes."

Por qué importa tool calling

Los LLM son buenos generando lenguaje, pero no tienen acceso automático a tus sistemas. Tool calling crea ese puente entre lenguaje natural y acciones estructuradas.

Permite:

• consultar datos en tiempo real (stock, estado de pedidos, métricas),
• ejecutar acciones (crear registros, enviar mensajes, actualizar estados),
• validar información contra fuentes externas,
• crear documentos o tareas en sistemas externos,
• buscar en la web con resultados estructurados,
• combinar varias herramientas en un solo flujo.

La diferencia entre un asistente y un agente suele estar aquí: el agente puede usar herramientas para avanzar hacia un objetivo, no solo conversar.

Cómo diseñar buenas herramientas

Una buena herramienta debe tener una responsabilidad clara. Es mejor una herramienta llamada create_support_ticket que una herramienta genérica llamada do_anything.

Buenas prácticas:

• Nombre descriptivo: el nombre debe indicar qué hace sin necesidad de leer la descripción.
• Descripción precisa: explica qué hace, cuándo usarla y cuándo no. El modelo usa esto para decidir.
• Parámetros estrictos: usa JSON Schema con tipos, enum, required y validaciones.
• Validación en servidor: nunca confíes en que el modelo envíe parámetros válidos. Valida siempre.
• Errores claros: devuelve mensajes estructurados que el modelo pueda interpretar y comunicar al usuario.
• Permisos por usuario: cada herramienta debe respetar el contexto del usuario que la invoca.
• Logs de ejecución: registra qué herramienta se llamó, con qué parámetros y qué resultado devolvió.
• Límites de costo y tiempo: establece timeouts y límites de uso para evitar llamadas infinitas.
• Resultados breves y estructurados: no devuelvas 50KB de JSON si 500 bytes bastan. El modelo procesa mejor la información concisa.

El modelo necesita entender cuándo usar la herramienta. Tu sistema necesita controlar qué puede hacer.

Tool calling no reemplaza permisos

Un error común es confiar en que el prompt impedirá acciones peligrosas. Eso no basta. El modelo puede ignorar instrucciones, especialmente en casos borde o cuando el prompt es ambiguo.

Si una herramienta puede borrar datos, enviar correos o publicar contenido, debe tener controles reales en la infraestructura:

• Autenticación: verificar identidad del usuario que origina la acción.
• Autorización: verificar que el usuario tiene permisos para esa acción específica.
• Confirmación humana: para acciones destructivas o sensibles, requerir aprobación explícita.
• Validación de inputs: sanitizar y validar todos los parámetros antes de ejecutar.
• Rate limits: limitar frecuencia de llamadas para prevenir abuso o bucles.
• Auditoría: registrar quién, qué, cuándo y con qué resultado.
• Rollback cuando sea posible: si la acción falla a mitad de camino, poder deshacer cambios.

El modelo puede decidir mal. La infraestructura debe limitar el daño.

Tool calling y RAG

RAG puede implementarse como una herramienta. El modelo decide que necesita buscar documentos, llama una herramienta de retrieval y recibe fragmentos relevantes. Después responde usando esos fragmentos.

Esto permite que un agente combine varias acciones en un solo flujo:

1. buscar documentos en la base de conocimiento (RAG como tool),
2. consultar una API externa para datos actualizados,
3. generar una respuesta basada en ambas fuentes,
4. crear una tarea de seguimiento en el CRM.

Esta composición de herramientas es lo que hace a los agentes verdaderamente potentes.

Tool calling y MCP

MCP (Model Context Protocol) estandariza cómo exponer tools y resources a clientes de IA. En vez de registrar manualmente funciones para cada aplicación, un servidor MCP puede declarar herramientas reutilizables que cualquier cliente compatible puede descubrir y usar.

Tool calling es el patrón. MCP es una forma de empaquetar y distribuir herramientas para agentes. Juntos, permiten un ecosistema donde las integraciones son portables entre distintos asistentes.

Riesgos comunes

Riesgo 1: Exponer tools demasiado poderosas. Una herramienta genérica para ejecutar SQL libre es peligrosa si no hay sandbox y permisos. Solución: herramientas específicas con queries predefinidas y parametrizadas.

Riesgo 2: Resultados ambiguos. Si la tool devuelve texto desordenado, el modelo puede interpretarlo mal. Solución: respuestas estructuradas (JSON) con campos claros.

Riesgo 3: No manejar fallos. APIs caen, timeouts ocurren y datos pueden faltar. Solución: manejo de errores con mensajes interpretables y reintentos controlados.

Riesgo 4: Encadenar muchas tools sin observabilidad. Cuando algo sale mal, necesitas saber qué llamada falló y por qué. Solución: tracing distribuido y logs estructurados.

Cómo evaluar una herramienta

Antes de poner una herramienta en producción, prueba:

• parámetros válidos (caso feliz),
• parámetros inválidos (tipos incorrectos, valores fuera de rango),
• usuarios sin permiso,
• respuestas vacías o nulas,
• timeouts de la API subyacente,
• errores 500/503 de la API,
• datos sensibles en la respuesta (¿se filtran al modelo?),
• llamadas repetidas (¿hay idempotencia?),
• costo por ejecución.

Una herramienta confiable no solo funciona en el caso feliz. También falla bien.

Preguntas frecuentes

¿El modelo ejecuta la función?

No. El modelo solicita la llamada. Tu aplicación ejecuta la herramienta y devuelve el resultado. El modelo nunca tiene acceso directo a tu infraestructura.

¿Tool calling es necesario para agentes?

Para agentes prácticos, casi siempre sí. Sin herramientas, el agente no puede operar sistemas externos y se queda en conversación.

¿Tool calling es lo mismo que integración de APIs?

No exactamente. La API es el sistema externo. Tool calling es la interfaz estructurada que permite al modelo pedir usarla. La API existe independientemente del modelo; tool calling es cómo el modelo accede a ella.

¿Cuántas herramientas puedo definir?

Depende del modelo. Típicamente puedes definir decenas de herramientas, pero demasiadas pueden confundir al modelo. Es mejor agrupar herramientas relacionadas o usar MCP para descubrimiento dinámico.

Fuentes y recursos recomendados

• OpenAI: Function calling — guía oficial para llamadas estructuradas a herramientas.
• OpenAI: Tools — documentación sobre herramientas disponibles para modelos.
• Model Context Protocol — protocolo para exponer tools y resources a clientes de IA.

Conclusión

Tool calling convierte a los modelos en interfaces activas para sistemas reales. Es el puente entre lenguaje natural y acciones estructuradas. Su valor depende del diseño de herramientas: cuanto más claras, limitadas y auditables sean, más confiable será el agente que las usa.

Si estás construyendo un agente, invierte tiempo en diseñar buenas herramientas. Es donde se gana o se pierde la calidad del sistema completo.