Récapitulatif MCP

Le serveur est construit, le client aussi, et les trois primitives sont en place. Revenons maintenant sur ces trois primitives fondamentales pour comprendre quand employer chacune. L’insight à emporter est simple à formuler et vous servira bien au-delà de cette section : chaque primitive est contrôlée par une partie différente de votre stack applicatif.

Les outils, contrôlés par le modèle

Les outils sont entièrement contrôlés par Claude. C’est le modèle qui décide quand appeler ces fonctions, et les résultats qu’elles retournent lui reviennent directement pour accomplir la tâche en cours. Vous ne planifiez pas la séquence d’appels, vous vous contentez de rendre les capacités disponibles.

Ils conviennent donc lorsque vous voulez donner à Claude des capacités supplémentaires qu’il puisse utiliser de façon autonome. Si vous lui demandez de « calculer la racine carrée de 3 en JavaScript », c’est lui qui détermine qu’un outil d’exécution JavaScript est nécessaire, qui l’appelle avec le bon code et qui interprète le résultat. Dans notre projet, read_doc_contents et edit_document relèvent de cette logique : Claude les mobilise quand la question posée l’exige.

Les ressources, contrôlées par l’application

Les ressources, elles, sont contrôlées par votre code applicatif. C’est votre application qui décide quand récupérer les données et ce qu’elle en fait, typiquement pour alimenter des éléments d’interface ou pour ajouter du contexte à une conversation.

Nous les avons employées de deux manières dans cette section. La première consistait à récupérer des données pour remplir les options d’autocomplétion dans l’interface, quand l’utilisateur tape @. La seconde consistait à récupérer du contenu pour enrichir les prompts avec du contexte supplémentaire, une fois le document choisi. Dans les deux cas, Claude n’a rien demandé : la décision venait du code. Pensez à la fonctionnalité « Ajouter depuis Google Drive » dans l’interface Claude — c’est le code applicatif qui détermine quels documents afficher et qui gère l’injection de leur contenu dans le contexte du chat.

Les prompts, contrôlés par l’utilisateur

Les prompts sont déclenchés par les actions de l’utilisateur. Ce sont les personnes devant l’écran qui décident quand lancer ces workflows prédéfinis, via des interactions d’interface comme un clic de bouton, une sélection dans un menu ou une commande slash.

Ils sont donc l’outil de choix pour implémenter des workflows que les utilisateurs peuvent déclencher à la demande. Notre commande /format en est un exemple direct. Dans l’interface Claude, les boutons de workflow situés sous la zone de saisie en sont un autre : des enchaînements prédéfinis et optimisés que l’on démarre d’un clic, sans avoir à formuler quoi que ce soit.

Choisir la bonne primitive

Face à une fonctionnalité à concevoir, la question à se poser n’est pas technique mais organisationnelle : qui doit décider du déclenchement ?

Besoin de donner de nouvelles capacités à Claude ?
    → Utilisez des outils

Besoin de récupérer des données dans votre app pour l'UI ou le contexte ?
    → Utilisez des ressources

Vous voulez créer des workflows prédéfinis pour les utilisateurs ?
    → Utilisez des prompts

Vous pouvez d’ailleurs observer les trois primitives à l’œuvre dans l’interface officielle de Claude, ce qui constitue un bon exercice de lecture une fois la section terminée.

Ce que vous avez construit

Le chemin parcouru est plus substantiel qu’il n’y paraît. Vous avez écrit un serveur MCP doté d’outils de lecture et d’édition de documents, puis appris à le tester avec l’inspecteur sans monter d’application complète. Vous avez ensuite implémenté un client MCP avec list_tools() et call_tool(), avant d’ajouter des ressources dans leurs deux formes, directes et avec templates, et l’accès à ces ressources côté client avec le parsing du type MIME. Vous avez enfin défini des prompts paramétrés côté serveur et les méthodes qui les consomment côté client. Autrement dit : un système MCP complet, de bout en bout.

Aller plus loin

Si vous souhaitez approfondir, le cours MCP : Sujets avancés couvre les notifications de progression, l’élicitation, les transports STDIO et Streamable HTTP, c’est-à-dire précisément ce qui vous permettra de sortir du cadre local d’un client et d’un serveur sur la même machine ; il situe aussi le sampling et les roots, dépréciés depuis la version 2026-07-28. Pour brancher votre serveur sur les produits Claude, le cours Connecter vos outils de Claude 101 montre le côté utilisateur des connecteurs.

À vous de jouer

1. Reprenez le service et les cinq opérations de la leçon 50 : écrivez le squelette du serveur (noms, descriptions, URI, un prompt), sans implémentation. Combien de lignes ?
2. Branchez le serveur du projet sur Claude Desktop ou Claude Code (fichier de configuration MCP, commande uv run mcp_server.py) et posez-lui une question sur les documents dans l’application.
3. Passez le quiz sur MCP du cours officiel.

Sources officielles : MCP review (Claude Academy) · Aperçu de l’architecture MCP · Registre des fonctionnalités dépréciées (2026-07-28)

Points clés à retenir

• Outils : contrôlés par le modèle ; ressources : par l’application ; prompts : par l’utilisateur.
• Face à une fonctionnalité, la question n’est pas technique mais organisationnelle : qui doit décider du déclenchement ?
• Vous avez construit un système MCP complet : serveur avec les trois primitives, inspecteur, client avec list_tools, call_tool, read_resource, list_prompts, get_prompt.
• Les trois primitives se voient dans claude.ai : boutons de workflow (prompts), Google Drive (ressources), exécution de code et recherche web (outils).

Testez vos connaissances

Validez les fondamentaux du protocole avant le quiz du cours officiel.

1. Quelles sont les trois primitives d'un serveur MCP, et qui contrôle chacune ?

Réponse : Les outils (contrôlés par le modèle : Claude décide de les appeler), les ressources (contrôlées par l’application : votre code les lit), les prompts (contrôlés par l’utilisateur : déclenchés par un geste explicite comme une commande slash).

2. Que génère le SDK à partir d'une fonction décorée avec @mcp.tool ?

Réponse : Le schéma JSON complet de l’outil — types depuis les annotations, descriptions depuis les Field — si bien que le schéma ne peut jamais diverger de l’implémentation.

3. Comment tester un serveur MCP sans écrire de client ?

Réponse : Avec l’Inspector MCP : mcp dev mcp_server.py ouvre une interface navigateur (URL avec jeton de session) qui liste et exécute outils, ressources et prompts et enregistre chaque message JSON-RPC ; c’est un client MCP générique, disponible aussi en CLI et en TUI.

4. Que renvoie get_prompt côté client ?

Réponse : Des messages prêts à être envoyés à Claude, déjà interpolés côté serveur — le client ne voit jamais le texte du template.

5. Dans un projet réel, implémente-t-on un client, un serveur, ou les deux ?

Réponse : Généralement l’un ou l’autre : un serveur pour exposer ses services aux clients existants (Claude Code, Claude Desktop), un client si l’on développe sa propre application. Les deux dans cette section, à des fins pédagogiques.

Si les cinq réponses sont venues sans effort, vous êtes prêt pour MCP : Sujets Avancés — sampling, notifications, transports distants.