Concevoir des MCP Serveurs Efficaces 🚀

ok l'objectif de cette vidéo c'est de comprendre comment les mcp serveurs des apps fonctionnent plus dans le détail on a déjà vu pas mal de choses sur la dernière vidéo mais là on va aller plus dans le détail surtout comment un peu les designer comment les penser parce que il ya un vrai sujet là dessus Donc le rôle du MCP serveur en fait c'est de connecter chaque GPT à vos données, à une logique métier et d'expliquer en fait ce qu'il faut renvoyer comme espace utilisateur.

Les technologies que vous pouvez utiliser, bon globalement là j'ai mis Python, TypeScript, Node.js mais il me semble que vous pouvez, je crois qu'il y a des SDK pour tous les langages, Ruby et tout.

Xano permet de faire des MCP, il y a d'autres outils comme N8n qui permettent de faire des MCP mais il n'y a pas la possibilité de faire des ressources, c'est que des tools.

Mexano a la possibilité de créer des ressources et on verra dans la dernière vidéo exactement comment le faire et globalement, comme je vous le disais, n'importe quel langage qui permet d'exposer une API HTTP et implémenter le protocole MCP.

Les deux composants qu'on a vu, les tools et les ressources.

Ce qu'on va voir, et il y a toutes les données dans la partie sur Xano, avec tous les éléments à copier et coller dans Xano, en fait c'est ce petit truc là, méta.

En fait, méta, c'est des métadescriptions.

Les métadescriptions, en informatique en général, c'est des informations données entre logiciels qui permettent de mieux comprendre ce que c'est.

Il y a plein de métadonnées dans le serveur MCP qui sont expliquées dans la documentation.

On ira plus en détail sur ces éléments-là peut-être dans cette vidéo mais c'est sûr sur la partie dans Xano.

Et donc vous voyez ici vous avez le titre, la description, les métadescriptions qui sont toujours OpenAI, un slash comme ça et OutputTemplate Donc là c'est un type de description qui indique que ce tool-là, RegisterTool qui sert à lister des tâches, doit actionner la ressource ui2.html.

Sauf que, il faut la créer cette ressource.

Et donc la ressource comme on la crée, en code, donc là c'est du javascript, serveur.registerresource Voyez la register tool, ça a enregistré la ressource, là on met le nom du widget et ici on met l'URI qui est la même que celle-là.

Comme ça en fait l'IA code elle appelle ce tool-là, elle sait qu'il faut afficher dans cette ressource.

Et donc la ressource, et on verra comment le faire dans Xano, retourne toujours trois éléments, l'URI pour aller chercher le code, le MIME TIP qui doit toujours être TEXT-HTML-SKYBRIDGE et le texte c'est le code HTML je vous montrerai exactement comment le faire dans Xano maintenant on va voir plus des questions de conception de design plutôt que du code pour que vous ayez des bonnes pratiques et que vous ne fassiez pas n'importe quoi Faut pas essayer de créer un genre de super tool qu'on appellerait « gérer des tâches » avec un paramètre « action » qui permet de créer, mettre à jour des lettres, supprimer, lister des tâches.

En fait, ça, ça fonctionne pas parce que ça serait trop trop compliqué à maintenir au niveau du code et au niveau de Xano, ça serait un enfer.

Et aussi, il faut comprendre exactement comment ChetJPT utilise chaque tool.

Un autre principe qui est bon à garder en tête, et ça, ça va amener à un paramètre qui n'est pas disponible encore sur Xano, c'est qu'en fait, il faut créer des tools pour la lecture qui permettent d'afficher des éléments, donc lister des produits, voir des produits, rechercher clients, vraiment pour afficher des données et des tools d'écriture.

Pourquoi on fait ça ?

Parce que dans les tools de lecture, ce qu'on peut faire c'est mettre dans la description du tool, je vous invite à aller voir sur la documentation du SDK MCP ce que c'est une annotation, vous pouvez mettre la notation read-only-hint deux petits points et la mettre en true ce qui fait que là vous voyez dans la démonstration à chaque appel mcp il faut valider mais si vous mettez read only int il n'y a plus besoin de valider ce qui permet d'éviter tous ces clics qui pour afficher des données ne sont pas très très utiles mais vous pouvez le mettre en false lorsque ça va modifier des données par exemple pour envoyer un brief pour créer une tâche pour ce genre de choses ok ?

Il faut toujours que ça retourne des données structurées.

Pourquoi ?

Parce que sinon, le composant ne va pas pouvoir remplir les données.

Par exemple, si vous dites, montre moi les tâches que j'ai à faire, et que là le MCP vous répond que vous avez 5 tâches, faire les courses, appel.

Vous pouvez le faire en code, 1 c'est une galère 2 ça sert à rien mais pour ceux qui auraient l'idée saugrenue de le faire ne le faites pas et il faut retourner ça en données structurées donc vous voyez les tâches là on a un tableau l'id de la tâche le titre et le statut ok ça si vous préférez c'est comme un tableau excel là les deux crochets c'est pour faire une liste d'éléments ça c'est un élément et ça c'est ce que contient l'élément ok faire les courses dessus tout doux machin ok Ok.

Cette partie là, elle est à nuancer.

Je vous invite à aller le lire, je ne vais pas m'attarder là-dessus, c'est vraiment si vous creusez à fond le sujet.

mais globalement depuis le widget vous pouvez modifier les données de deux manières en utilisant OpenAI CallTool qui va réappeler le mcp serveur comme ça le tool response est modifié et le tlgpt est modifié ou sinon vous pouvez faire un call dans le widget sans le tool mcp et ensuite ça va mettre à jour ce qu'on appelle le widget state ce qui sont les données que chaque GPT va pouvoir voir par rapport à votre widget.

Mais ça, le widget state, on va s'étaler un peu plus après.

Donc voilà, c'est exactement ce que je viens de vous expliquer.

Voilà, là vous avez toutes les métadonnées, widget accessible, le read-only-in, une adotation de cette manière, toute l'invocation.

Voilà, c'était ça qui est extrêmement important.

C'est qu'en fait, lorsque vous avez un widget, il faut que tous les tools qui soient liés à ce widget revoient la même structure de données.

Pour ceux qui sont des devs plus avancés, vous savez qu'il y a des solutions pour pallier à ça mais quoi que non en fait non non non pas du tout pas du tout ça rendrait le code pas très efficace donc pas du tout mais voilà gardez en fait cette logique c'est que vous voyez là par exemple on a deux tools, lister les produits et voir un produit qui vont être reliés au même widget Et vous voyez, là le format de réponse Product, Select Product, Product et List, c'est pas les mêmes.

En fait, il faut toujours que ça rende exactement le même truc.

Product, Selected Product, Product, Selected Product.

Ok ?

C'est pas écrit ici, mais en fait il y a plusieurs trucs qui sont pas vraiment vraiment expliqués dans la doc mais en faisant des tests on a découvert ça c'est qu'en fait vous avez deux formats de vue du note chat gpt enfin il y en a trois mais il y en a une où on n'a pas expérimenté avec c'est inline et fullscreen inline c'est dire que vous avez l'iframe qui est dans la conversation et fullscreen qui est sur un bouton et l'application prend tout l'écran et vous avez juste la barre de chat qui est en fond.

Quand vous êtes en fullscreen et que vous faites un appel à un tool mcp qui est relié à ce widget, ça ne crée pas de nouveau widget.

C'est-à-dire que vous pouvez mettre à jour les données avec windows.openAI.tooloutput comme on en a vu dans la section précédente de ce widget.

Sauf que, prenons cet exemple de lister les produits, voir les produits.

ça vous fait une sélection de produits, vous voulez en voir plus, vous cliquez sur la fiche produits, ça vous met en full screen, et vous avez la liste des autres produits à gauche ou en dessous, d'accord ?

vous sélectionnez un autre produit machin, et vous dites non finalement je veux changer de catégorie de produits, je veux pas voir des souris, je veux voir des claviers d'ordinateur, ok ?

vous le mettez dans le chat, et bien en fait, là ça va réappeler le tool lister les produits, non c'est pas un bon exemple.

L'exemple que je voulais faire avec la marque alface mais avec xano c'est pas possible parce qu'il faut tout le temps valider, il y a un problème d'affichage, je vais pas m'étaler là dessus mais il y a un problème d'affichage qui fait que c'est pas vraiment possible et j'aurais du le faire en code et le temps ne m'était pas permis.

Mais globalement Vous avez votre liste d'agence, vous cliquez sur une agence, ça vous met en fullscreen, vous avez la liste des agences qui est à gauche, vous avez la fiche agence, et en dessous vous avez quelque chose pour remplir le brief.

Et vous pouvez dire, ah ok cette agence me convient, remplis le brief.

Là ça appelle le tool, ça appelle le tool du coup, ça appelle le tool Prefile Brief, comme ce qu'on va voir dans l'app Exano.

et ça remplit les inputs du formulaire sur le même widget.

Sauf que dans cette réponse, il faut qu'on liste aussi la liste d'agences qui était là.

Donc il faut qu'on ait l'agency list, l'agence sélectionnée et le brief dans la réponse du tool.

Donc il faut toujours regarder à l'esprit que pour tout le output template toujours la même structure content sinon ça ne fonctionne pas ou sinon vous allez avoir des données qui vont disparaître il y a des petites solutions mais ne vous attardez pas là dessus ou sinon contactez nous pour qu'on vous aide à mettre ça en place tac tac tac Définissez un schéma de réponse par widget où il faut vous anticiper tous les éléments possibles sur ce widget.

Vous avez une petite check list des bonnes pratiques et maintenant on va passer à l'host API Windows.OpenAI.