OpenWebUI explique comment connecter System Prompt, Skills et MCP Tools pour la validation de liens

L'écosystème OpenWebUI a démontré en pratique pourquoi un seul prompt système n'est pas suffisant pour un assistant IA fiable. En utilisant un bot d'assistance technique comme exemple, les auteurs ont expliqué comment répartir les rôles entre le modèle, le post-traitement et les outils externes pour que le bot ne fournisse pas aux utilisateurs des URL cassées.

Trois Couches de Logique

L'article de HOSTKEY ne parle pas d'un nouveau modèle, mais de l'architecture qui l'entoure. Les auteurs prennent un problème typique de l'assistance technique : un assistant répond à partir d'une base de connaissances, crée des liens vers la documentation et doit non seulement deviner la bonne adresse, mais confirmer qu'elle s'ouvre réellement. C'est là que naît la division en trois niveaux.

System Prompt établit le comportement du modèle, explique le format des réponses et enseigne même comment assembler des URL à partir de noms internes de documents, mais ne peut pas naviguer sur le réseau par lui-même.

« System Prompt est une description de poste d'un employé. »

Ensuite, une Skill est ajoutée à la chaîne — une couche de post-traitement qui reçoit un brouillon de réponse déjà préparé. Elle peut extraire les liens du texte, appeler un outil externe, vérifier le résultat par rapport aux règles et retourner une version nettoyée à l'utilisateur.

Le troisième niveau est un MCP Tool, c'est-à-dire un code exécutable distinct qui effectue une action réelle : dans ce cas, envoie une requête HTTP et signale si le lien fonctionne ou non.

• System Prompt est responsable du rôle, du ton, des contraintes et de l'algorithme de construction des liens.
• Skill analyse la réponse du modèle, coordonne la vérification et modifie le texte final.
• MCP Tool exécute une requête réseau et retourne un résultat structuré : état, temps de réponse, erreur.
• Ensemble, ces couches fournissent un schéma prévisible au lieu de tenter de tout résoudre avec un seul prompt.

Comment Fonctionne la Vérification

L'article analyse un scénario réel : un utilisateur demande comment configurer une interface réseau dans le panneau Invapi. Le modèle avec un prompt système trouve le bon document dans la base de connaissances, transforme le nom du fichier interne en une adresse de documentation publique et insère le lien dans la réponse. À ce stade, tout semble encore plausible, mais cela ne garantit pas que la page existe et ne mène pas à un 404.

Après la génération, la Skill url-validator-with-mcp est activée. Elle analyse la réponse, trouve les URL et les envoie une à une à l'outil MCP. L'outil lui-même est implémenté en tant que service Python sur fastmcp : il valide d'abord le format de l'adresse, puis effectue une requête HEAD, peut suivre les redirections, vérifie SSL et gère les timeouts. L'exemple utilise un timeout standard de cinq secondes, et la réponse est retournée sous forme de JSON avec des champs tels que status_code, response_time_ms, final_url et error.

Si l'outil reçoit une réponse correcte du serveur, la Skill laisse le lien dans le texte et vérifie également le formatage. Si la vérification retourne 404, une erreur SSL ou un timeout, la Skill supprime entièrement le lien cassé et n'affiche pas à l'utilisateur des ordures techniques. En dernier recours, le bot peut laisser un chemin sûr, par exemple un lien vers l'assistance technique, au lieu d'une instruction inventée.

Pourquoi C'est Important

Le point principal de l'article est que System Prompt, Skills et MCP Tools ne sont pas en concurrence. Ils couvrent différentes classes de tâches. Le prompt connaît le contexte du dialogue et les règles métier, mais n'a pas un accès direct au réseau. Skill voit la réponse terminée et peut organiser la vérification, mais ne télécharge rien par lui-même. MCP Tool sait comment travailler avec le monde extérieur, mais ne comprend pas de quoi parlait la conversation avec l'utilisateur et comment la réponse finale devrait se présenter.

Pour les équipes qui construisent des assistants appliqués, c'est un schéma utile. La compétence peut être réutilisée avec différents modèles et l'outil externe peut être connecté non seulement à ce scénario, mais également à d'autres pipelines. L'article souligne spécifiquement que la même Skill est déjà utilisée dans les traducteurs pour éviter que des liens cassés n'apparaissent dans la sortie. Cela rend l'architecture non seulement élégante sur un diagramme, mais pratique en production : il est plus facile de tester les couches séparément, de journaliser les erreurs et de modifier un seul composant sans réécrire tout l'assistant.

Ce que Cela Signifie

L'analyse de HOSTKEY montre bien où va l'écosystème des outils IA : la valeur ne réside plus dans l'LLM elle-même, mais de plus en plus dans la combinaison de règles, de vérifications et d'actions externes. Si un produit a besoin de fiabilité, une seule « réponse intelligente » ne suffit plus — vous avez besoin d'une couche qui vérifiera le résultat dans le monde réel avant que l'utilisateur ne le voie.