OpenWebUI explica cómo combinar System Prompt, Skills y MCP Tools para verificar enlaces

En el ecosistema de OpenWebUI se ha mostrado en la práctica por qué un prompt de sistema no basta para un asistente de IA fiable. Con un bot de soporte técnico como ejemplo, los autores explican cómo repartir los roles entre el modelo, el posprocesamiento y una herramienta externa para que el bot no entregue URL rotas al usuario.

Tres capas de lógica

El artículo de HOSTKEY no trata de un modelo nuevo, sino de la arquitectura que lo rodea. Los autores parten de un problema típico del soporte técnico: el asistente responde a partir de una base de conocimiento, construye enlaces a la documentación y no debe limitarse a adivinar la dirección correcta, sino confirmar que realmente abre. Ahí aparece la división en tres niveles.

El System Prompt define el comportamiento del modelo, explica el formato de las respuestas e incluso le enseña a montar URL a partir de nombres internos de documentos, pero no puede acceder a la red por sí mismo.

«El

System Prompt es la descripción del puesto de un empleado».

Después se añade a la cadena un Skill, una capa de posprocesamiento que recibe el borrador de respuesta ya generado. Puede extraer los enlaces del texto, llamar a una herramienta externa, contrastar el resultado con las reglas y devolver al usuario una versión depurada.

El tercer nivel es la MCP Tool, es decir, código ejecutable independiente que realiza una acción real: en este caso envía una petición HTTP e informa de si el enlace funciona o no.

• System Prompt se encarga del rol, el tono, las restricciones y el algoritmo para construir enlaces.
• Skill analiza la respuesta del modelo, coordina la comprobación y modifica el texto final.
• MCP Tool ejecuta la petición de red y devuelve un resultado estructurado: estado, tiempo de respuesta, error.
• En conjunto, estas capas ofrecen un esquema predecible en lugar de intentar resolverlo todo con un solo prompt.

Cómo funciona la comprobación

El artículo analiza un escenario real: un usuario pregunta cómo configurar una interfaz de red en el panel Invapi. El modelo, con su prompt de sistema, encuentra el documento adecuado en la base, convierte el nombre interno del archivo en una dirección pública de documentación e inserta el enlace en la respuesta. En esta fase todo parece verosímil, pero eso no garantiza que la página exista y no lleve a un 404.

Tras la generación entra en juego el Skill url-validator-with-mcp. Analiza la respuesta, localiza las URL y las envía una a una a la herramienta MCP. La herramienta es un servicio en Python basado en fastmcp: primero valida el formato de la dirección, luego hace una petición HEAD, puede seguir redirecciones, comprueba SSL y gestiona timeouts. El ejemplo usa un timeout estándar de cinco segundos, y la respuesta llega en JSON con campos como status_code, response_time_ms, final_url y error.

Si la herramienta recibe una respuesta correcta del servidor, el Skill deja el enlace en el texto y comprueba además el formato. Si la comprobación devuelve un 404, un error de SSL o un timeout, el Skill elimina por completo el enlace roto y no muestra al usuario ruido técnico. Como alternativa, el bot puede dejar una vía segura, por ejemplo un enlace al soporte técnico, en lugar de una instrucción inventada.

Por qué importa

La idea central del artículo es que System Prompt, Skills y MCP Tools no compiten entre sí. Cubren clases de tareas distintas. El prompt conoce el contexto de la conversación y las reglas de negocio, pero no tiene acceso directo a la red. El Skill ve la respuesta terminada y puede organizar una comprobación, pero por sí solo no descarga nada. La MCP Tool sabe trabajar con el mundo exterior, pero no entiende de qué trataba la conversación con el usuario ni qué aspecto debe tener la respuesta final.

Para los equipos que construyen asistentes aplicados, es un patrón útil. Un Skill se puede reutilizar con distintos modelos, y la herramienta externa se puede conectar no solo a este escenario, sino a otros pipelines. El artículo destaca que ese mismo Skill ya se usa en traductores para que la salida no contenga enlaces rotos.

Eso hace que la arquitectura no sea solo ordenada en un diagrama, sino práctica en producción: es más fácil probar las capas por separado, registrar errores y cambiar un componente sin reescribir todo el asistente.

Qué significa

El análisis de HOSTKEY muestra hacia dónde va el ecosistema de herramientas de IA: el valor está cada vez menos en el propio LLM y más en la combinación de reglas, comprobaciones y acciones externas. Si un producto necesita fiabilidad, ya no basta con una «respuesta inteligente»: hace falta una capa que verifique el resultado en el mundo real antes de que lo vea el usuario.