Récapitulatif : Model Context Protocol

Le module MCP se referme : outils, ressources et prompts fonctionnent de bout en bout dans votre chatbot. Avant de passer aux applications Anthropic, fixons les points essentiels — la grille de lecture qui vous permettra, dans vos projets, de choisir la bonne primitive sans hésiter.

Les trois composants d’un serveur MCP

Les analogies de la colonne centrale sont vos repères mentaux — mais la vraie clé de répartition est ailleurs : qui contrôle la primitive. Les outils sont contrôlés par le modèle (Claude décide de les appeler au fil de son raisonnement), les ressources par l’application (votre code les lit pour l’interface ou le contexte — la mention @ du chatbot), et les prompts par l’utilisateur (un geste explicite les déclenche — la commande /format). Trouvez qui doit décider, vous avez trouvé la primitive.

Architecture globale

Votre application
      │
      ▼
  MCP Client (pont de communication)
      │
      ▼
  MCP Server
  ├── Outils    → exécutés par le serveur
  ├── Ressources → données exposées
  └── Prompts   → templates de messages

Deux propriétés de ce schéma valent d’être gravées. D’abord, le client est un pont générique : il découvre dynamiquement ce que le serveur propose — rien n’est codé en dur, et n’importe quel client compatible fonctionne avec n’importe quel serveur. Ensuite, Claude n’apparaît pas dans le schéma, et c’est normal : le modèle ignore l’existence de MCP — il voit des outils et des résultats, comme toujours ; le protocole est une affaire de plomberie entre votre application et les sources de capacités.

Ce que vous avez construit

Dans ce module, vous avez créé :

1. Un serveur MCP avec outils (lecture/modification), ressources (liste/contenu) et prompt (reformatage markdown)
2. Un client MCP capable de lister/appeler outils, lire ressources, récupérer prompts
3. Une application CLI complète qui combine client MCP et API Claude

Le tout en couches testées séparément — le serveur validé par l’inspecteur avant le client, le client validé seul avant l’intégration : la méthode compte autant que le résultat, et elle se transpose telle quelle à vos futurs serveurs.

À retenir pour vos projets

Trois réflexes pour la suite. Dans les projets réels, vous implémenterez soit un client, soit un serveur — rarement les deux : le double rôle de ce module était pédagogique, pour voir les deux faces du protocole. Créez des serveurs MCP pour exposer vos services — vos données, vos API internes — à d’autres équipes ou à Claude Code : c’est le cas d’usage le plus fréquent, et la prochaine section montrera justement Claude Code consommer votre serveur. Et gardez l’inspecteur mcp dev comme premier réflexe de débogage : chaque outil, ressource ou prompt ajouté se valide là, en isolation, avant toute intégration.

Points clés à retenir

• La clé de répartition MCP : qui contrôle ? modèle → outils, application → ressources, utilisateur → prompts
• Le client est générique et découvre tout dynamiquement — aucun couplage client/serveur
• Claude ignore MCP : il voit des outils et des résultats, le protocole est votre plomberie
• En production : un client OU un serveur — et le serveur est le cas le plus fréquent
• L’inspecteur mcp dev reste votre banc d’essai à chaque évolution du serveur