¿Qué es la llamada a función?

El servidor MCP sin scrapear expone capacidades web y de navegador que un anfitrión de agente puede presentar a un modelo a través de interfaces de llamada a función.

Por qué importa este tema

La llamada a función es un patrón que permite a una aplicación describir herramientas a un modelo de lenguaje y recibir una solicitud estructurada para usar una de ellas. La documentación sobre llamadas a función de OpenAI explica que las definiciones de herramientas utilizan esquemas y que la aplicación ejecuta la función seleccionada. El modelo produce una propuesta; no obtiene acceso directo a un servidor, base de datos, navegador o credencial.

Esta separación hace que los modelos de lenguaje sean útiles dentro del software. La intención en lenguaje natural puede mapearse a una operación tipada, mientras que el código de aplicación existente retiene la autorización y las reglas comerciales. La llamada a función puede impulsar búsqueda de solo lectura, cálculos, búsqueda de registros, operaciones de navegador o transacciones. El riesgo y la validación requeridos dependen del efecto secundario, no de cuán limpio se vea el JSON.

El ciclo de vida de la llamada a función

El anfitrión envía al modelo una solicitud de usuario y un conjunto de definiciones de herramientas disponibles. Cada definición tiene un nombre, descripción y esquema de entrada. El modelo puede responder directamente o devolver una llamada a la herramienta con argumentos estructurados. El anfitrión analiza esa llamada, la verifica, ejecuta el código correspondiente y envía el resultado de vuelta bajo la identidad de llamada correcta.

El modelo puede entonces usar el resultado para producir una respuesta final o solicitar otra herramienta. El uso de herramientas en múltiples pasos crea un bucle agente, pero la llamada a función en sí es solo la interfaz entre el modelo y el anfitrión. La planificación, la memoria, la autorización, la programación y la política de errores son preocupaciones de aplicación separadas.

Una herramienta bien diseñada representa una capacidad significativa. Una herramienta vaga como `hacer_algo` oculta permisos y le da al modelo demasiadas combinaciones de argumentos. Una función de búsqueda estrecha, búsqueda de clientes u operación de navegación de navegador es más fácil de describir, validar, observar y otorgar de forma independiente.

Qué hace una buena definición de herramienta

• Nombre claro. Usa un verbo y objeto que distingan la capacidad de herramientas cercanas.
• Descripción centrada en la decisión. Explica cuándo se debe usar la herramienta, qué devuelve y exclusiones importantes.
• Esquema restringido. Requiere campos necesarios y usa enums, formatos, límites y objetos anidados deliberadamente.
• Resultado tipado. Devuelve campos estables, evidencia de origen, estado de acción y errores legibles por máquina.
• Efecto secundario explícito. Haz que el comportamiento de lectura, escritura, envío, eliminación, envío y compra sea obvio para el anfitrión y el modelo.

Llamada a función, APIs y MCP

Estos conceptos operan en diferentes capas y a menudo trabajan juntos en lugar de competir.

Implementar un bucle de llamada de función segura

Trata cada llamada de herramienta como entrada no confiable propuesta por el modelo. Aplica la misma autorización y validación que se espera de cualquier otro cliente.

1. Inventario de capacidades. Divide las operaciones por recurso, efectos secundarios y permisos para que cada herramienta tenga un contrato comprensible.
2. Diseña esquemas a partir de funciones reales. Haz coincidir las entradas requeridas y los campos de salida reales en lugar de inventar parámetros amigables con el modelo que el código no pueda honrar.
3. Valida contexto y autoridad. Verifica identidad, propiedad de recursos, estado actual, valores permitidos, presupuestos y aprobaciones antes de la ejecución.
4. Devuelve resultados precisos. Incluye identificadores estables, evidencia y categorías de error estructuradas sin exponer secretos o trazas internas.
5. Registra el intercambio completo. Registra la versión de definición de la herramienta, argumentos solicitados, resultado de validación, resultado de ejecución y respuesta visible para el modelo.

Evalúa el uso de herramientas

Una evaluación de llamada de herramienta debería distinguir selección, formación de argumentos, ejecución y uso de respuesta final.

• Precisión de selección. ¿El modelo eligió la herramienta correcta o evitó correctamente el uso de la herramienta?
• Validez del argumento. ¿Cumplió la llamada con el esquema y las restricciones semánticas específicas de la tarea?
• Comportamiento de autorización. ¿Bloqueó el anfitrión los recursos no permitidos y requirió aprobaciones en el límite correcto?
• Uso del resultado. ¿Interpretó el modelo los campos y la evidencia devueltos sin agregar reclamaciones no soportadas?
• Control de bucle. ¿Detuvo el uso de múltiples pasos en la finalización, no progreso o agotamiento de presupuesto?

Riesgos de llamar funciones

La salida estructurada mejora el análisis pero no hace que las decisiones del modelo sean confiables por sí mismas. El Marco de Gestión de Riesgos de IA de NIST suministra un marco de gobernanza, mientras que la especificación de semántica HTTP recuerda a los implementadores que las respuestas de red tienen semánticas precisas que el anfitrión debe interpretar. La seguridad sigue siendo responsabilidad de la aplicación.

• Herramientas excesivamente amplias. Grandes capacidades hacen que la autorización de mínimo privilegio y la evaluación significativa sean difíciles.
• Invalidación semántica. Los argumentos pueden pasar JSON Schema pero referirse a la cuenta incorrecta, registro obsoleto o objetivo prohibido.
• Inyección a través de los resultados de la herramienta. El contenido externo puede contener instrucciones. Devuélvelo como datos y preserva la precedencia de la política del sistema.
• Fugas de secretos. Las definiciones y resultados de las herramientas no deben exponer credenciales, enrutamiento privado o datos personales innecesarios.
• Efectos secundarios duplicados. El anfitrión debe usar identidades de operación y verificaciones de estado actual para que las llamadas al modelo repetidas no creen escrituras no deseadas.

Casos de uso de llamadas a funciones

De piloto a producción

Un piloto útil para la llamada a funciones debe ser lo suficientemente pequeño como para inspeccionar registro por registro. Comience con capacidades de inventario: Divida operaciones por recurso, efecto secundario y permiso para que cada herramienta tenga un contrato comprensible. Luego aplique esquemas de diseño de funciones reales: Alinee las entradas y campos de salida requeridos en lugar de inventar parámetros amigables para el modelo que el código no puede honrar. Mantenga el primer conjunto de evaluación deliberadamente mezclado, incluyendo casos ordinarios, casos ambiguos, evidencia faltante y una acción que el sistema debe rechazar o transferir. Esto revela si el flujo de trabajo comprende su límite antes de que un mayor volumen oculte errores de diseño dentro de métricas agregadas.

La preparación para producción requiere un propietario para cada medida y artefacto. Rastrear exactitud de selección para responder si el modelo eligió la herramienta correcta o evitó correctamente el uso de herramientas. Rastrear validez de argumentos para determinar si la llamada satisfizo restricciones semánticas específicas de esquema y tarea. Agregar comportamiento de autorización para que el equipo pueda ver si el anfitrión bloqueó recursos no permitidos y requirió aprobaciones en el límite correcto. Estas medidas deben estar vinculadas a registros subyacentes en lugar de existir solo como totales de panel. Un revisor necesita moverse de una métrica cambiada a la consulta exacta, fuente, observación o acción que la produjo.

Los controles operativos deben dirigirse a los modos de falla más propensos a cambiar una decisión empresarial. La primera regla de revisión debe cubrir herramientas demasiado amplias: Las grandes capacidades dificultan la autorización de menor privilegio y la evaluación significativa. La revisión de salida debe cubrir efectos secundarios duplicados: El anfitrión debe usar identidades de operación y verificaciones de estado actual para que las llamadas al modelo repetidas no creen escrituras no deseadas. Asigne un propietario de respuesta, defina qué evidencia resuelve el problema y registre si el resultado cambia datos, sugerencias, herramientas, permisos o política de origen. Ese registro evita que el mismo defecto sea redescubierto como una fluctuación de calidad inexplicada.

Expanda solo después de que el piloto se comporte de manera predecible. Un equipo puede comenzar con información actual, donde el trabajo es permitir que el modelo solicite búsqueda o recuperación y reciba resultados con fuente. Una segunda fase puede agregar búsqueda comercial, donde el flujo de trabajo debe traducir una pregunta del usuario en una consulta validada contra un servicio aprobado. Mantenga el conjunto de pruebas original en funcionamiento a medida que se expande el alcance. Nuevas fuentes, mercados, herramientas y permisos deben ser introducidos un límite a la vez para que las regresiones se puedan asignar a un cambio específico en lugar de una reescritura simultánea de la plataforma.

Conclusión

La llamada a funciones brinda a los modelos de lenguaje una forma tipada de solicitar capacidades de software. Su fiabilidad proviene del anfitrión circundante: esquemas precisos, validación semántica, menor privilegio, autorización determinista, resultados estables y trazas completas. El modelo selecciona; la aplicación sigue siendo responsable.

Comience con herramientas de solo lectura y un conjunto de capacidades limitado. Evalúe selección y argumentos en tareas reales antes de agregar efectos secundarios. Esa secuencia convierte la flexibilidad del lenguaje natural en un comportamiento de software controlado.