Récapitulatif MCP

Notre chatbot MCP est complet : outils, ressources et prompts y fonctionnent ensemble. Avant de quitter la section, récapitulons les trois primitives d’un serveur MCP et — surtout — le critère qui permet de choisir entre elles sans hésiter. L’insight clé tient en une phrase : chaque primitive est contrôlée par une partie différente de votre stack applicatif. Trouvez qui doit décider, vous avez trouvé la primitive.

Outils : contrôlés par le modèle

Les outils sont entièrement contrôlés par Claude. Le modèle décide quand appeler ces fonctions — vous les proposez, il dispose — et les résultats lui reviennent directement pour accomplir sa tâche. Dans notre projet, personne n’a jamais codé « si l’utilisateur parle du rapport, lire le rapport » : Claude a choisi seul d’appeler read_doc_contents quand la conversation le justifiait.

Utilisez les outils quand vous voulez donner des capacités supplémentaires à Claude. Par exemple, si vous demandez à Claude de calculer la racine carrée de 3 en JavaScript, il décidera automatiquement d’utiliser un outil d’exécution JavaScript — c’est sa décision, prise au fil du raisonnement, et c’est exactement la signature d’un outil.

Ressources : contrôlées par l’application

Les ressources renversent le contrôle : c’est votre code applicatif qui décide quand récupérer les données et comment les utiliser — typiquement pour l’interface utilisateur ou pour ajouter du contexte aux conversations. Claude n’initie jamais rien ici ; il bénéficie de données que l’application est allée chercher.

Utilisez les ressources quand vous avez besoin d’intégrer des données dans votre app :

• Remplir les options d’auto-complétion dans l’interface
• Récupérer des documents pour un sélecteur de fichiers
• Ajouter du contexte aux messages avant de les envoyer à Claude

Notre mention @ cochait les trois cases : l’application interrogeait la liste des documents pour l’autocomplétion, puis injectait le contenu du document choisi dans le prompt — sans qu’aucun outil ne soit appelé.

Prompts : contrôlés par l’utilisateur

Troisième détenteur du contrôle : l’utilisateur final. Les prompts sont des workflows prédéfinis que les utilisateurs déclenchent via des actions directes — cliquer sur des boutons, sélectionner des options de menu, utiliser des commandes slash. Notre /format en était l’exemple type : un geste humain explicite, qui déclenche un prompt rédigé et maintenu côté serveur.

Utilisez les prompts quand vous voulez implémenter des workflows prédéfinis facilement accessibles aux utilisateurs — des actions de qualité constante, écrites une fois, évaluées une fois, offertes à tous.

Choisir la bonne primitive

La grille de décision complète :

Ce sont des lignes directrices générales, pas des cloisons étanches — notre propre projet les a combinées : le prompt /format (contrôle utilisateur) orchestrait des outils (contrôle modèle), pendant que les ressources (contrôle application) alimentaient l’interface. La formule à retenir : les outils servent le modèle, les ressources servent l’application, et les prompts servent les utilisateurs. Un serveur MCP bien conçu pense aux trois publics — et c’est ce qui le rend immédiatement utile à n’importe quel client qui s’y connecte.

Points clés à retenir

• Le critère de choix MCP : qui contrôle ? modèle → outils, application → ressources, utilisateur → prompts
• Outils = capacités que Claude mobilise seul, au fil de son raisonnement
• Ressources = données que l’application récupère (interface, contexte), sans décision du modèle
• Prompts = workflows déclenchés par un geste utilisateur explicite (slash, bouton, menu)
• Les primitives se combinent dans un même serveur — chacune sert son public