Les prompts côté client — Introduction au MCP

Il ne reste qu’une pièce à poser pour terminer notre client MCP : les fonctionnalités de prompts. Deux méthodes suffisent, l’une pour lister tous les prompts disponibles sur le serveur, l’autre pour récupérer un prompt précis avec ses variables déjà remplies. À la fin de cette leçon, vous saurez les écrire, les brancher sur des commandes slash, et vous aurez implémenté les trois primitives de bout en bout.

Découvrir les prompts disponibles

La méthode list_prompts ne réserve aucune surprise et reprend mot pour mot la structure de list_tools écrite plus tôt : elle appelle la fonction de liste de prompts de la session et retourne les prompts.

async def list_prompts(self) -> list[types.Prompt]:
    result = await self.session().list_prompts()
    return result.prompts

C’est cette méthode qui alimentera le menu des commandes slash de votre CLI. Le serveur reste ainsi la source unique de vérité : ajoutez un prompt côté serveur, il apparaît côté client sans qu’une ligne de l’application n’ait été modifiée.

Récupérer un prompt instancié

La méthode get_prompt est plus intéressante, car c’est elle qui gère l’interpolation de variables. Quand vous demandez un prompt, vous fournissez des arguments qui sont passés à la fonction de prompt comme arguments mot-clé.

async def get_prompt(self, prompt_name, args: dict[str, str]):
    result = await self.session().get_prompt(prompt_name, args)
    return result.messages

Reprenons le prompt de la leçon précédente. Si votre serveur expose un prompt format_document qui attend un paramètre doc_id, le dictionnaire d’arguments contiendra {"doc_id": "plan.md"}. Cette valeur est interpolée dans le template du prompt côté serveur, et ce que vous récupérez n’est donc pas un modèle à trous mais des messages complets, prêts à partir vers Claude. Remarquez que la méthode retourne result.messages et non le résultat brut : votre application n’a plus qu’à ajouter ces messages à la conversation en cours.

Essayer depuis la ligne de commande

Une fois les deux méthodes implémentées, testez la fonctionnalité via la CLI. Tapez un slash (/) et les prompts disponibles apparaissent sous forme de commandes. Sélectionnez « format » : l’interface vous invite alors à choisir parmi les documents disponibles, en s’appuyant sur la ressource d’autocomplétion construite deux leçons plus tôt.

Après la sélection du document, le système envoie le prompt complet à Claude. Le modèle reçoit à la fois les instructions de formatage et l’identifiant du document, puis mobilise les outils disponibles pour récupérer et traiter le contenu. Vous voyez ici les trois primitives coopérer dans une seule action de l’utilisateur : un prompt déclenché par un slash, une ressource qui remplit la liste de choix, et des outils appelés par Claude pour faire le travail.

Le trajet complet d’un prompt

Serveur MCP
  └─► Définit le prompt avec @mcp.prompt
      └─► Template avec variables (doc_id, etc.)

Client MCP
  └─► Appelle list_prompts() pour découvrir les prompts
  └─► Appelle get_prompt(name, args) pour récupérer un prompt instancié
      └─► Reçoit les messages prêts à envoyer à Claude

Application
  └─► Présente les prompts à l'utilisateur (ex: commandes slash)
  └─► Envoie les messages à Claude

Le cycle de vie se lit dans le même ordre. Tout commence par un travail d’auteur : vous écrivez et évaluez un prompt pertinent pour votre domaine, puis vous le définissez dans votre serveur MCP avec @mcp.prompt. À partir de là, les clients peuvent demander ce prompt à tout moment via list_prompts(). Lorsqu’un client en instancie un, les arguments qu’il fournit deviennent des arguments mot-clé dans votre fonction Python, et celle-ci retourne des messages formatés, prêts pour le modèle IA.

Les trois primitives, réunies

Avec les prompts côté client, vous avez implémenté l’intégralité du protocole vu dans ce cours. Le tableau ci-dessous rassemble ce que vous avez écrit et rappelle qui décide de quoi.

Primitive	Contrôlée par	Méthodes client
Outils	Claude	`list_tools()`, `call_tool()`
Ressources	L’application	`read_resource()`
Prompts	L’utilisateur	`list_prompts()`, `get_prompt()`

Ce que vous obtenez au bout du compte, ce sont des prompts réutilisables et paramétrés, qui maintiennent la cohérence tout en autorisant la personnalisation par les variables. C’est particulièrement précieux pour les workflows complexes, là où vous voulez garantir que l’IA reçoit à chaque fois des instructions correctement structurées. Sur notre poste, avec le SDK 2.3.0, list_prompts() renvoie ['format'] et get_prompt("format", {"doc_id": "plan.md"}) une liste dont le premier message a le rôle user et contient le texte interpolé.

À vous de jouer

Ajoutez list_prompts et get_prompt au client, puis, dans le harnais, affichez le rôle et les 60 premiers caractères du message rendu pour format sur plan.md.
Dans main.py, tapez /, choisissez format, puis un document : suivez dans la réponse de Claude l’appel à edit_document, et relisez le document avec read_doc_contents pour vérifier qu’il est bien en Markdown.
Exposez votre prompt summarize de la leçon 10 : apparaît-il dans le menu slash sans que vous ayez touché à main.py ?

Sources officielles : Prompts in the client (Claude Academy) · Aperçu de l’architecture : primitives

Points clés à retenir

list_prompts() alimente le menu des commandes slash ; le serveur reste la source unique de vérité.
get_prompt(name, args) renvoie des messages déjà interpolés côté serveur, prêts à être ajoutés à la conversation.
Une action utilisateur peut mobiliser les trois primitives : prompt déclenché par /, ressource pour la liste de choix, outils appelés par Claude.
Outils contrôlés par Claude, ressources par l’application, prompts par l’utilisateur : la clé de lecture du protocole.