MCP Apps vs sortie d’outil simple : quand une intégration IA a besoin d’une UI

Conservez une sortie d’outil simple lorsque le résultat peut être lu, cité ou transmis à l’étape suivante de manière fiable sous forme de texte compact ou de données typées. Choisissez une MCP App lorsque l’utilisateur doit explorer des données multidimensionnelles, gérer l’état d’un formulaire, examiner des médias riches ou travailler successivement sur de nombreux objets. L’extension officielle permet à un tool de déclarer une ressource UI interactive qu’un host compatible affiche dans la conversation.

Une MCP App ne rend pas le tool plus précis et ne lui accorde aucune autorité supplémentaire. Il s’agit d’une couche distincte de présentation et d’interaction au-dessus des capacités serveur. Si un tableau de dix lignes et une recommandation claire suffisent déjà, un iframe, un bundle JavaScript, un protocole d’événements et une surface de sécurité supplémentaire ne font qu’augmenter le coût. Commencez par l’analyse de la tâche : quelle action la personne ne peut-elle pas accomplir commodément ou sûrement via une réponse normale ?

• Réponse courte, citation ou handoff lisible par machine → sortie simple du tool.
• Filtres, drill-down, canvas, contrôles média ou review en plusieurs étapes → candidat pour une MCP App.
• Action à conséquences → policy côté serveur et confirmation explicite indépendamment de l’UI.
• Le host ne prend pas l’extension en charge → fallback texte ou structuré utile.
• Aucun bénéfice d’interaction mesurable → ne pas ajouter de couche app.

Dans le modèle de base, la définition du tool contient `_meta.ui.resourceUri`, qui pointe vers une ressource `ui://`. Le host récupère la ressource HTML, la rend généralement dans un iframe sandboxé et transmet le résultat du tool à la vue. L’UI et le host communiquent via JSON-RPC sur `postMessage` : l’app peut recevoir les résultats, demander au host d’appeler un tool serveur autorisé ou mettre à jour le contexte du modèle. Le tool et son schema restent le contrat canonique d’exécution.

Séparez trois types d’état. L’état métier faisant autorité vit dans le système de référence ; le résultat du tool est un snapshot versionné ou un handle ; l’état éphémère de la vue contient l’onglet sélectionné, un filtre ou un champ incomplet. Ne cachez pas l’unique identifiant d’une opération uniquement dans l’état navigateur. Après refresh, nouveau render ou fallback, l’utilisateur doit pouvoir restaurer le contexte via un resource ID explicite et une version vérifiée par le serveur.

Pour lire un fait, une liste de conclusions ou un petit ensemble de records, une sortie simple se conserve mieux dans le transcript, est plus facile à vérifier par le modèle et fonctionne dans davantage de clients. Pour explorer une cohort heatmap, une carte, une timeline ou un grand tableau, une UI avec tri et filtres locaux peut réduire les appels répétés au modèle. L’app ne doit transmettre au modèle que les décisions significatives de l’utilisateur, pas chaque hover ou scroll.

Pour quelques paramètres manquants, l’elicitation native du host ou le tour de conversation suivant suffit généralement. Une MCP App est justifiée pour des champs interdépendants, un live preview ou un review en plusieurs étapes. Pour les writes, l’UI prépare une proposition d’action exacte, mais le serveur revérifie identity, tenant, version de l’objet, scope et approval. Un bouton nommé Approve ne prouve pas l’autorisation et un champ role masqué n’est pas une assertion fiable.

• Un résultat et jusqu’à cinq champs simples → commencer par texte, structured content ou formulaire natif.
• Grand dataset avec exploration locale → app avec snapshot borné et provenance.
• Configuration dépendante avec preview → app, mais validation répétée côté serveur.
• Paiement, publish, delete ou changement production → proposal, policy gate, idempotency et reconciliation.
• Capacités client différentes → progressive enhancement, pas deux logiques métier.

Le modèle officiel isole l’app du DOM parent, des cookies du host et du local storage, et fait passer la communication par un canal contrôlé. Les metadata de ressource peuvent déclarer les origins de Content Security Policy et les permissions demandées. Le host décide quelles capacités accorder. L’app doit donc utiliser des allowlists minimales pour connect, resources et permissions ; microphone, camera, clipboard ou navigation externe ne doivent pas être demandés par précaution.

Traitez la ressource HTML ou JavaScript, le résultat du tool et les données d’autres tools comme des entrées non fiables distinctes. Le host valide resource URI, négociation de l’extension, origin du message, allowlist des méthodes, taille du payload et correlation ID. Le serveur ne se fie jamais à un bouton désactivé ni à une validation client. Secrets et bearer tokens n’entrent ni dans le contexte du modèle ni dans le bundle de la vue ; l’app appelle le tool serveur via le host et la frontière des credentials reste hors de l’iframe.

MCP Apps est une extension opt-in dont la prise en charge dépend du host et de la version. Un tool doit renvoyer un résultat sémantique utile même si l’UI n’est pas rendue : un résumé concis pour la personne, `structuredContent` pour le client ou le modèle et des identifiants stables pour l’appel suivant. Ne renvoyez pas seulement une instruction d’ouvrir le widget, car un échec de négociation de l’extension ou de render deviendrait alors une perte de fonctionnalité.

Progressive enhancement signifie une seule opération métier côté serveur avec plusieurs voies de présentation. L’app ne doit pas disposer d’un endpoint privilégié caché absent du flux client normal. Si l’interaction riche est intrinsèquement non portable, définissez un fallback minimal : résumé read-only, artifact téléchargeable ou lien sûr vers un produit autonome. Analytics doit distinguer les outcomes app, fallback et host non compatible sans considérer le render comme une action métier terminée.

La suite de contrat vérifie metadata du tool, ressource `ui://`, profil MIME, initialisation, livraison du résultat, validation des messages et dégradation correcte sans l’extension. Les tests navigateur couvrent sandbox, refus CSP, bundle lent, refresh, événement dupliqué, snapshot stale, état offline et deux vues simultanées. Les tests de sécurité tentent d’appeler un tool non déclaré, de substituer un object ID, d’imposer un origin externe et de rejouer une requête à conséquences.

La qualité d’interaction se teste avec navigation uniquement au clavier, ordre du focus, labels, annonce des erreurs, contraste des couleurs, zoom et viewport étroit. Un eval du modèle vérifie séparément que l’assistant choisit le bon tool, explique l’app et n’utilise que les sélections utilisateur pertinentes. Les signaux produit importants sont task completion, correction rate, délai jusqu’à un outcome vérifié et succès du fallback ; le nombre de clics ou de renders ne prouve pas à lui seul la valeur.

Choisissez un scénario principalement en lecture où l’UI apporte un avantage évident, par exemple l’exploration de dépenses avec filtres et drill-down. Enregistrez le baseline du flux plain-output, implémentez l’app en progressive enhancement et rejouez les deux sur des snapshots identiques. Limitez le canary aux tenants de test et aux tools read-only ; ouvrez les writes uniquement après tests négatifs, review d’accessibilité, preuves de policy et reconciliation idempotente.

Un feature flag doit pouvoir désactiver la ressource app séparément sans désactiver le tool de base. Le rollback arrête les nouveaux renders, restaure la réponse simple, invalide la version problématique de l’asset et réconcilie les opérations inachevées. L’audit relie serveur, tool, version de ressource, capacité du host, session de vue, action utilisateur, verdict de policy et outcome faisant autorité sans enregistrer les champs sensibles du formulaire. Supprimez l’app après rollout si elle n’améliore pas l’outcome défini ou crée une charge opérateur inacceptable.