Synthèse du MCP

Notre projet MCP est complet : outils, ressources et prompts fonctionnent de bout en bout. Le moment est bien choisi pour prendre de la hauteur, car les trois primitives peuvent sembler se ressembler — toutes exposent « quelque chose » du serveur au client. La grille de lecture qui les distingue tient en deux questions : qui les contrôle, et à quel usage elles sont destinées. Une fois cette grille en tête, choisir la bonne primitive devient un réflexe.

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

Les outils sont la primitive dont Claude décide. Vous les présentez, et c’est le modèle qui choisit, au fil de la conversation, quand les appeler et avec quels arguments ; les résultats lui reviennent directement pour accomplir sa tâche. Dans notre projet, c’est Claude qui a décidé d’appeler read_doc_contents quand on l’interrogeait sur un document — personne ne l’avait programmé explicitement.

Utilisez les outils quand vous voulez étendre les capacités de Claude : calculs, accès à des API, exécution de code, lecture et modification de données.

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 — Claude n’y touche pas de lui-même. Dans notre chatbot, c’est l’application qui interroge la ressource listant les documents pour alimenter l’autocomplétion avec @, et qui injecte le contenu d’un document mentionné dans le contexte de la conversation. Le modèle bénéficie des données, mais n’a jamais initié leur récupération.

Utilisez les ressources pour peupler l’autocomplétion, ajouter du contexte aux messages, afficher des listes de documents dans l’interface.

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 l’utilisateur déclenche par une action explicite dans l’interface — boutons, menus, commandes slash. Dans notre CLI, taper /format déclenche le prompt de reformatage : c’est un geste humain, pas une décision du modèle ni de l’application.

Utilisez les prompts pour des workflows prédéfinis, des starters de conversation, des templates de tâches spécialisées — partout où vous voulez offrir à l’utilisateur des actions de qualité constante, rédigées une fois côté serveur.

Guide de décision rapide

La formule à retenir : les outils servent le modèle, les ressources servent l’application, les prompts servent les utilisateurs. Les trois peuvent coexister dans le même serveur — c’est même leur combinaison qui fait la richesse d’une intégration MCP : notre prompt /format orchestre des outils, pendant que les ressources alimentent l’interface qui permet de le déclencher.

Au-delà du projet, cette architecture explique la portée du protocole : un serveur MCP bien conçu décrit une fois pour toutes comment accéder à un système — et n’importe quel client compatible, le vôtre comme Claude Desktop, en hérite intégralement.

Points clés à retenir

• La grille de lecture MCP : qui contrôle la primitive, et pour quel usage
• Outils = contrôle du modèle : Claude décide quand les appeler pour accomplir sa tâche
• Ressources = contrôle de l’application : votre code récupère les données pour l’interface ou le contexte
• Prompts = contrôle de l’utilisateur : workflows prédéfinis déclenchés par un geste explicite (slash, bouton)
• Les trois se combinent dans un même serveur, réutilisable tel quel par tout client compatible