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 ce cours : 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 ce cours. 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 le cours terminé.

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 le sampling, les notifications de progression, les roots (racines), ainsi que les transports STDIO et StreamableHTTP — 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.

Pour obtenir votre certification officielle, rendez-vous sur Anthropic Academy.

Testez vos connaissances

Clôturez le cours en validant les fondamentaux du protocole.

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’inspecteur : mcp dev mcp_server.py ouvre une interface navigateur qui liste et exécute outils, ressources et prompts — c’est un client MCP générique.

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 ce cours, à 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.