OpenWebUI détaille comment associer System Prompt, Skills et MCP Tools pour vérifier les liens

Dans l'écosystème OpenWebUI, une démonstration concrète montre pourquoi un prompt système ne suffit pas pour un assistant IA fiable. À partir d'un bot de support technique, les auteurs expliquent comment répartir les rôles entre le modèle, le post-traitement et un outil externe afin que le bot ne renvoie pas d'URL cassées à l'utilisateur.

Trois couches de logique

L'article de HOSTKEY ne porte pas sur un nouveau modèle, mais sur l'architecture qui l'entoure. Les auteurs prennent un problème typique du support technique : l'assistant répond à partir d'une base de connaissances, construit des liens vers la documentation et ne doit pas se contenter de deviner la bonne adresse, mais confirmer qu'elle s'ouvre réellement. C'est là qu'intervient la séparation en trois niveaux.

Le System Prompt définit le comportement du modèle, explique le format des réponses et lui apprend même à assembler des URL à partir de noms internes de documents, mais il ne peut pas accéder au réseau par lui-même.

« Le System Prompt, c'est la fiche de poste d'un employé ».

Vient ensuite un Skill, une couche de post-traitement qui reçoit le brouillon de réponse déjà prêt. Il peut extraire les liens du texte, appeler un outil externe, confronter le résultat aux règles et renvoyer à l'utilisateur une version nettoyée.

Le troisième niveau est le MCP Tool, c'est-à-dire un code exécutable distinct qui accomplit une action réelle : ici, il envoie une requête HTTP et indique si le lien fonctionne.

• System Prompt gère le rôle, le ton, les contraintes et 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 la requête réseau et renvoie un résultat structuré : statut, temps de réponse, erreur.
• Ensemble, ces couches offrent un schéma prévisible plutôt qu'une tentative de tout résoudre avec un seul prompt.

Comment fonctionne la vérification

L'article décrit un scénario réel : un utilisateur demande comment configurer une interface réseau dans le panneau Invapi. Le modèle, guidé par le prompt système, trouve le bon document dans la base, convertit le nom de fichier interne en adresse publique de documentation et insère le lien dans la réponse. À ce stade, tout paraît plausible, mais cela ne garantit pas que la page existe et ne mène pas à une erreur 404.

Après la génération, le Skill url-validator-with-mcp se déclenche. Il analyse la réponse, repère les URL et les envoie une à une à l'outil MCP. L'outil est un service Python basé sur fastmcp : il valide d'abord le format de l'adresse, puis envoie une requête HEAD, peut suivre les redirections, vérifie le SSL et gère les timeouts. L'exemple utilise un timeout standard de cinq secondes, et la réponse revient en JSON avec des champs comme status_code, response_time_ms, final_url et error.

Si l'outil reçoit une réponse correcte du serveur, le Skill laisse le lien dans le texte et vérifie en plus la mise en forme. Si la vérification renvoie une 404, une erreur SSL ou un timeout, le Skill supprime entièrement le lien défaillant et n'affiche aucun déchet technique à l'utilisateur. En solution de repli, le bot peut laisser une voie sûre, par exemple un lien vers le support technique, plutôt qu'une instruction inventée.

Pourquoi c'est important

L'idée centrale de l'article est que System Prompt, Skills et MCP Tools ne se font pas concurrence. Ils couvrent des classes de tâches différentes. Le prompt connaît le contexte du dialogue et les règles métier, mais n'a pas d'accès direct au réseau. Le Skill voit la réponse finalisée et peut organiser une vérification, mais ne télécharge rien lui-même. Le MCP Tool sait travailler avec le monde extérieur, mais ne comprend ni le sujet de la conversation avec l'utilisateur ni l'aspect que doit avoir la réponse finale.

Pour les équipes qui conçoivent des assistants applicatifs, c'est un schéma utile. Un Skill peut être réutilisé avec différents modèles, et l'outil externe peut être branché non seulement à ce scénario, mais à d'autres pipelines. L'article souligne que ce même Skill est déjà utilisé dans des traducteurs pour éviter les liens cassés en sortie.

L'architecture n'est donc pas seulement propre sur le papier, elle est praticable en production : il est plus simple de tester les couches séparément, de journaliser les erreurs et de remplacer un composant sans réécrire tout l'assistant.

Ce que cela signifie

L'analyse de HOSTKEY montre la direction que prend l'écosystème des outils d'IA : la valeur réside de moins en moins dans le LLM lui-même et de plus en plus dans l'association de règles, de vérifications et d'actions externes. Si un produit exige de la fiabilité, une « réponse intelligente » ne suffit plus : il faut une couche qui vérifie le résultat dans le monde réel avant que l'utilisateur ne le voie.