Llamada a funciones (function calling): qué es

La llamada a funciones o function calling es el mecanismo por el que un modelo de IA solicita usar una función o herramienta mediante datos estructurados. El modelo propone el nombre y los argumentos; la aplicación valida permisos, ejecuta la operación y devuelve el resultado al modelo. No significa que el modelo ejecute código por sí solo ni que la llamada sea segura sin controles.

Actualizado: 13 de julio de 2026.

Cómo funciona function calling paso a paso

Function calling convierte una intención en una solicitud estructurada, pero la aplicación conserva la autoridad para ejecutar. El ciclo habitual tiene cinco pasos:

1. La aplicación envía al modelo el mensaje del usuario y las herramientas disponibles.
2. El modelo responde con una llamada que contiene el nombre de la herramienta y sus argumentos.
3. La aplicación valida esquema, identidad, permisos, límites y estado actual.
4. Si la operación está autorizada, la aplicación la ejecuta y devuelve el resultado como mensaje de herramienta.
5. El modelo usa ese resultado para responder o solicitar otra herramienta.

La guía oficial de function calling de OpenAI describe precisamente este flujo. La documentación de tool use de Anthropic distingue además herramientas del cliente, ejecutadas por tu aplicación, y herramientas del servidor, ejecutadas por el proveedor.

El detalle más importante es el paso 3. Una salida del modelo es entrada no confiable. Aunque los argumentos cumplan el JSON Schema, todavía pueden pedir una acción indebida, usar un identificador que el usuario no controla o repetir una operación ya ejecutada.

Ejemplo de llamada a una función

Imagina una herramienta de solo lectura para consultar el estado de un pedido:

{
  "name": "consultar_pedido",
  "description": "Devuelve el estado de un pedido que pertenece al usuario autenticado",
  "parameters": {
    "type": "object",
    "properties": {
      "pedido_id": { "type": "string" }
    },
    "required": ["pedido_id"],
    "additionalProperties": false
  },
  "strict": true
}

Ante “¿Dónde está mi pedido A-204?”, el modelo podría solicitar:

{
  "name": "consultar_pedido",
  "arguments": { "pedido_id": "A-204" }
}

La aplicación no debe consultar el pedido inmediatamente. Primero comprueba que el usuario inició sesión y que A-204 le pertenece. Después ejecuta la consulta y devuelve un resultado mínimo:

{
  "pedido_id": "A-204",
  "estado": "en reparto",
  "actualizado_at": "2026-07-13T09:30:00Z"
}

El modelo redacta la respuesta final a partir de esos datos. Si la consulta falla, la herramienta devuelve un error tipado; no conviene esconder el fallo ni pedir al modelo que invente un estado probable.

Funciones, herramientas, APIs y salidas estructuradas

Una salida estructurada no implica una acción. Puedes pedir una factura en JSON sin ejecutar nada. Function calling, en cambio, señala la intención de usar una capacidad externa. Tampoco toda función necesita una API remota: puede calcular un impuesto, consultar memoria local o leer una base de datos mediante una capa de servicio.

Function calling vs. MCP

El Model Context Protocol no sustituye el tool calling. Resuelve otra capa del sistema:

• el servidor MCP publica herramientas y recursos;
• el cliente descubre sus nombres, descripciones y esquemas;
• el cliente presenta las herramientas pertinentes al modelo;
• el modelo solicita una mediante function calling;
• el cliente autoriza, ejecuta y devuelve el resultado.

MCP reduce integraciones a medida, pero no elimina la política de seguridad. Un servidor puede exponer una herramienta válida y aun así ser demasiado poderosa para cierto usuario. La aplicación debe decidir qué servidor es confiable, qué herramientas se habilitan y qué argumentos se permiten.

Seguridad: controles antes de ejecutar

strict: true ayuda a que los argumentos coincidan con el esquema, pero conformidad sintáctica no equivale a autorización ni verdad. Un identificador puede tener el formato correcto y pertenecer a otra cuenta. La seguridad vive en el servicio que ejecuta, no en la descripción escrita para el modelo.

Para acciones sensibles, separa herramientas de lectura y escritura. buscar_cliente y actualizar_cliente deberían tener permisos distintos. Una vista previa antes de confirmar también permite mostrar exactamente qué cambiará.

Cómo diseñar una buena herramienta

1. Nombre específico: crear_borrador_factura es más claro que procesar.
2. Descripción de frontera: explica cuándo usarla y cuándo no.
3. Esquema pequeño: pide solo los campos necesarios y limita valores con enum cuando corresponda.
4. Resultado compacto: devuelve estado, evidencia y errores útiles, no objetos enormes.
5. Errores tipados: distingue “no encontrado”, “sin permiso” y “entrada inválida”.
6. Efecto observable: registra quién solicitó la acción, qué cambió y con qué idempotency key.
7. Prueba sin efectos: ofrece modo borrador o dry_run cuando la operación lo permita.

Las descripciones compiten por atención dentro de la ventana de contexto. Cargar cientos de herramientas similares puede reducir precisión y aumentar coste. Conviene seleccionar las relevantes por tarea o usar mecanismos de búsqueda de herramientas cuando el proveedor los soporte.

Cómo evaluar function calling

No midas solo si el modelo eligió una herramienta. Separa al menos estas métricas:

• selección: eligió la herramienta correcta o respondió sin llamar cuando no hacía falta;
• argumentos: produjo campos válidos y semánticamente correctos;
• autorización: el sistema bloqueó accesos indebidos;
• ejecución: la función produjo el estado esperado una sola vez;
• uso del resultado: la respuesta final no contradijo ni exageró la salida;
• recuperación: manejó errores, datos ausentes y timeouts sin inventar;
• coste y latencia: número de ciclos, tokens y llamadas externas por tarea.

Construye un conjunto de casos normales, ambiguos, maliciosos y de fallo. Incluye peticiones que no deberían activar herramientas: una buena precisión requiere reducir tanto llamadas omitidas como llamadas innecesarias.

Cuándo usarlo y cuándo no

Function calling encaja cuando el modelo necesita datos actuales, cálculos reproducibles o acciones con estado: consultar inventario, reservar una cita, buscar documentos, crear un borrador o ejecutar una prueba.

No hace falta para una transformación local y determinista que tu código puede resolver sin modelo. Tampoco debe ser la única barrera de seguridad para pagos, permisos, salud o decisiones legales. En esos casos, el modelo puede ayudar a preparar la acción, pero reglas del servidor y revisión humana deciden si se ejecuta.

Para practicar, revisa cómo se relacionan una API de IA, una herramienta y un agente de IA. La secuencia útil es: describir la función, validar la llamada, ejecutar con permisos mínimos y verificar el cambio real.

Fuentes oficiales

• OpenAI Developers — Function calling.
• Anthropic — Tool use with Claude.
• Model Context Protocol — Architecture.