OpenWebUI desglosa cómo conectar System Prompt, Skills y MCP Tools para validación de enlaces

El ecosistema de OpenWebUI demostró en la práctica por qué un único prompt de sistema no es suficiente para un asistente IA confiable. Usando un bot de soporte técnico como ejemplo, los autores explicaron cómo dividir roles entre el modelo, postprocesamiento y herramientas externas para que el bot no entregue URLs rotos a los usuarios.

Tres Capas de Lógica

El artículo de HOSTKEY no trata sobre un nuevo modelo, sino sobre la arquitectura que lo rodea. Los autores toman un problema típico de soporte técnico: un asistente responde desde una base de conocimiento, construye enlaces a documentación y debe no solo adivinar la dirección correcta, sino confirmar que realmente se abre. Aquí es donde surge la división en tres niveles.

System Prompt establece el comportamiento del modelo, explica el formato de las respuestas e incluso enseña cómo ensamblar URLs a partir de nombres internos de documentos, pero no puede navegar por la red por sí solo.

"System Prompt es una descripción de puesto de un empleado."

A continuación, se añade una Skill a la cadena — una capa de postprocesamiento que recibe un borrador de respuesta ya preparado. Puede extraer enlaces del texto, llamar a una herramienta externa, verificar el resultado contra reglas y devolver una versión limpia al usuario.

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

• System Prompt es responsable del rol, tono, restricciones y el algoritmo para construir enlaces.
• Skill analiza la respuesta del modelo, coordina la verificación y cambia el texto final.
• MCP Tool ejecuta una solicitud de red y devuelve un resultado estructurado: estado, tiempo de respuesta, error.
• Juntas, estas capas proporcionan un esquema predecible en lugar de intentar resolver todo con un único prompt.

Cómo Funciona la Verificación

El artículo analiza un escenario en vivo: un usuario pregunta cómo configurar una interfaz de red en el panel Invapi. El modelo con un prompt de sistema encuentra el documento correcto en la base de conocimiento, transforma el nombre del archivo interno en una dirección de documentación pública e inserta el enlace en la respuesta. En esta etapa, todo sigue siendo plausible, pero no garantiza que la página exista y no lleve a un 404.

Después de la generación, se activa la Skill url-validator-with-mcp. Analiza la respuesta, encuentra URLs y las envía una por una a la herramienta MCP. La herramienta en sí se implementa como un servicio Python en fastmcp: primero valida el formato de la dirección, luego realiza una solicitud HEAD, puede seguir redirecciones, verifica SSL y maneja timeouts. El ejemplo utiliza un timeout estándar de cinco segundos y la respuesta se devuelve como JSON con campos como status_code, response_time_ms, final_url y error.

Si la herramienta recibe una respuesta correcta del servidor, la Skill mantiene el enlace en el texto y verifica adicionalmente el formato. Si la verificación devuelve 404, error de SSL o timeout, la Skill elimina completamente el enlace roto y no muestra al usuario basura técnica. Como opción de respaldo, el bot puede dejar una ruta segura, por ejemplo un enlace al soporte técnico, en lugar de una instrucción inventada.

Por Qué Esto Es Importante

El punto principal del artículo es que System Prompt, Skills y MCP Tools no compiten entre sí. Cubren diferentes clases de tareas. El prompt conoce el contexto del diálogo y las reglas comerciales, pero no tiene acceso directo a la red. Skill ve la respuesta terminada y puede organizar la verificación, pero no descarga nada por sí solo. MCP Tool sabe cómo trabajar con el mundo externo, pero no entiende de qué se trataba la conversación con el usuario o cómo debería verse la respuesta final.

Para equipos que construyen asistentes aplicados, este es un patrón útil. La habilidad puede reutilizarse con diferentes modelos y la herramienta externa puede conectarse no solo a este escenario, sino también a otros pipelines. El artículo enfatiza específicamente que la misma Skill ya se utiliza en traductores para evitar que aparezcan enlaces rotos en la salida. Esto hace que la arquitectura sea no solo elegante en un diagrama, sino práctica en producción: es más fácil probar las capas por separado, registrar errores y cambiar un solo componente sin reescribir todo el asistente.

Qué Significa Esto

El análisis de HOSTKEY muestra bien hacia dónde se dirige el ecosistema de herramientas de IA: el valor cada vez más no está en el LLM en sí, sino en la combinación de reglas, verificaciones y acciones externas. Si un producto necesita confiabilidad, una única "respuesta inteligente" ya no es suficiente — necesita una capa que verifique el resultado en el mundo real antes de que el usuario lo vea.