Function calling

Definición

Function calling (también llamado tool use o tool calling) es la capacidad de un LLM moderno para invocar funciones o herramientas externas estructuradas: decidir cuándo llamarlas, qué función llamar y con qué argumentos. En lugar de limitarse a generar texto, el modelo produce una salida estructurada que el sistema puede ejecutar (llamar a una API, ejecutar código, consultar una base de datos, mandar un email).

Es la pieza técnica que permite construir agentes IA reales y conectar LLMs con el mundo exterior: el modelo se convierte en cerebro de un sistema que puede actuar, no solo conversar.

Function calling nativo lo introdujeron OpenAI (junio 2023), Anthropic, Google y otros. Hoy es una capability estándar en cualquier LLM frontera: GPT-5, Claude Opus 4, Gemini 2, Llama 4, Mistral Large, DeepSeek-V3.

Cómo funciona

El flujo típico:

1. Defines las herramientas disponibles como esquemas (típicamente JSON Schema): nombre, descripción, parámetros aceptados.

2. Pasas la conversación + lista de herramientas al modelo en cada llamada.

3. El modelo elige:

   • Responder texto al usuario directamente, O
   • Llamar a una o más funciones, generando JSON con función + argumentos.

4. Tu código ejecuta las funciones llamadas, captura los resultados.

5. Le devuelves los resultados al modelo en la siguiente llamada.

6. El modelo continúa: puede llamar más funciones, o ya generar la respuesta final al usuario.

Ejemplo práctico

Imaginemos un asistente para el equipo comercial de IMDICA.

Definición de herramientas:

[
  {
    "name": "buscar_cliente",
    "description": "Busca un cliente en el CRM por nombre, NIF o ID",
    "parameters": {
      "type": "object",
      "properties": {
        "query": { "type": "string", "description": "Nombre, NIF o ID del cliente" }
      },
      "required": ["query"]
    }
  },
  {
    "name": "historico_pedidos",
    "description": "Devuelve los últimos N pedidos de un cliente con sus importes y fechas",
    "parameters": {
      "type": "object",
      "properties": {
        "cliente_id": { "type": "string" },
        "limite": { "type": "integer", "default": 20 }
      },
      "required": ["cliente_id"]
    }
  },
  {
    "name": "stock_producto",
    "description": "Consulta stock actual de un producto por referencia",
    "parameters": {
      "type": "object",
      "properties": {
        "ref": { "type": "string" }
      },
      "required": ["ref"]
    }
  }
]

Conversación:

Usuario: "¿Cuánto ha facturado este año Construcciones Soler? Y dime si tenemos stock del destornillador GBH-18V que suelen pedir."

LLM (paso 1) genera:

[
  { "tool": "buscar_cliente", "args": { "query": "Construcciones Soler" } }
]

Sistema ejecuta → devuelve { "cliente_id": "8821", "nombre_completo": "Construcciones Soler S.L." }.

LLM (paso 2) genera:

[
  { "tool": "historico_pedidos", "args": { "cliente_id": "8821", "limite": 50 } },
  { "tool": "stock_producto", "args": { "ref": "GBH-18V" } }
]

Sistema ejecuta ambas en paralelo → devuelve historico (lista de pedidos) y stock (35 unidades disponibles).

LLM (paso 3) genera respuesta final al usuario:

"Construcciones Soler ha facturado 47.890€ en lo que va de 2026 (18 pedidos). El destornillador GBH-18V tiene 35 unidades en stock, así que podemos servir su pedido habitual sin problema."

Todo esto en unos segundos. El LLM ha orquestado tres llamadas a APIs internas decidiendo qué herramientas necesitaba y cuándo.

Anatomía de una función bien definida

Un schema de tool de calidad cumple:

1. Nombre claro: buscar_cliente, no bc1 ni do_search.
2. Descripción rica: el modelo decide qué herramienta usar leyendo la descripción. Cuanto más concreta, mejor.
3. Parámetros tipados: types JSON Schema válidos.
4. Descripciones de parámetros: "Nombre completo del cliente" vs solo "string".
5. Required claros: distinguir qué es obligatorio.
6. Ejemplos en la descripción si ayuda: "Ejemplo de uso: cuando el usuario pregunta por un cliente concreto".
7. Pocas tools por petición: 10-30 es manejable. >50 → el modelo se confunde, mejor agrupar o filtrar dinámicamente.

Tool use vs function calling vs API calling

Los términos se usan casi indistintamente, pero hay matices:

• Function calling: término OpenAI original. Una función concreta.
• Tool use: término Anthropic. Más genérico, puede incluir herramientas no estrictamente funciones (búsqueda web, ejecución de código).
• API calling: cualquier llamada a API externa, no necesariamente desde un LLM.

Hoy "tool use" es el término dominante en literatura moderna.

Parallel tool calls

Los modelos modernos pueden llamar varias funciones simultáneamente en una sola respuesta. Esto es crítico para eficiencia:

• Mal: llamar historico_pedidos → esperar → llamar stock_producto → esperar → responder. (3 round-trips)
• Bien: llamar ambas a la vez → esperar → responder. (2 round-trips)

GPT-4 Turbo, Claude 3+, Gemini 2 todos soportan parallel tool calls. Aprovecharlo reduce latencia significativamente.

Streaming con tool use

En la mayoría de APIs modernas, los tool calls pueden venir streamed: el modelo te va indicando "voy a llamar a esta tool" antes de tener completados todos los argumentos. Esto permite preparar la ejecución y mejorar UX percibida.

MCP: el estándar emergente

Model Context Protocol (MCP) de Anthropic es un estándar abierto (2024-2026) para que agentes IA se conecten a herramientas, datos y entornos de forma uniforme. En vez de cada empresa definiendo su tool schema custom, MCP estandariza el contrato. Adoptado rápidamente: Cursor, Zed, Replit, muchas integraciones nativas.

Es básicamente "USB-C para LLMs": un mismo conector estandarizado para que cualquier herramienta se enchufe a cualquier modelo.

Errores comunes en function calling

• Descripciones de tool pobres: el modelo no sabrá cuándo llamarlas. Invierte tiempo aquí.
• Tool con muchísimos parámetros opcionales: confunde al modelo. Tools deben ser simples y específicas.
• Una mega-tool para todo: do_everything(action, params) es peor que 5 tools concretas.
• No validar los argumentos: el modelo puede inventar args malformados. Valida antes de ejecutar.
• Esperar fiabilidad 100%: los modelos top fallan el ~5% de llamadas. Diseña retries, fallbacks.
• No registrar las llamadas: sin logs no puedes debuggear ni mejorar tools.
• Exponer tools peligrosas sin guardrails: una tool exec_shell o delete_user puede causar desastres. Principio de mínimo privilegio.
• Demasiadas tools simultáneas: si das 100 tools, el modelo se pierde. Usa tool filtering dinámico o jerarquía.

Seguridad y validación

Function calling abre vectores de riesgo nuevos:

• Prompt injection vía tool results: si un tool devuelve contenido malicioso ("ignora todas las instrucciones anteriores..."), el modelo puede obedecer.
• Tools peligrosas: delete, send_email, transfer_money necesitan confirmación humana o sandboxing.
• Argumentos malformados: validar siempre antes de ejecutar.
• Rate limiting: un agente en bucle puede hacer 1000 llamadas/segundo a una tool. Limita.
• Logging y auditoría: registrar cada llamada para incidents post-hoc.

Cuándo usar function calling

Sí, úsalo cuando:

• Necesitas que el LLM acceda a datos en tiempo real (CRM, base de datos, APIs).
• Construyes un agente IA que ejecuta tareas.
• Quieres respuestas basadas en hechos verificables, no en memoria del modelo.
• Tu producto integra LLM con sistemas existentes.

No es necesario si:

• Tu caso de uso es conversacional puro sin necesidad de datos externos.
• Quieres simplicidad máxima y el modelo solo y RAG basta.

Referencias

• OpenAI · Function calling guide — referencia oficial original
• Anthropic · Tool use documentation — implementación de Anthropic, con buenas prácticas
• Model Context Protocol (MCP) — el estándar emergente para conectar agents a tools