Les prompts dans le client

La leçon précédente a défini des prompts côté serveur ; il reste à les rendre accessibles depuis l’application. C’est la dernière pièce de notre client MCP : après les outils et les ressources, les prompts complètent le trio de fonctionnalités que le protocole standardise. Comme pour les deux autres, le travail côté client se résume à envelopper des appels de session — toute l’intelligence reste sur le serveur.

Lister les prompts

Première méthode : découvrir ce que le serveur propose.

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

Cette découverte dynamique est le cœur du modèle MCP : le client n’a aucune liste de prompts codée en dur. Il interroge le serveur au démarrage et obtient, pour chaque prompt, son nom, sa description et ses arguments attendus. Si l’équipe qui maintient le serveur ajoute demain un prompt « summarize » à côté du prompt « format », votre client l’affichera sans qu’une seule ligne de son code ne change. C’est exactement le mécanisme qui permet à un même client de fonctionner avec des serveurs MCP écrits par des tiers.

Récupérer un prompt spécifique

Deuxième méthode : demander un prompt précis, avec ses arguments.

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

Le point décisif se joue dans ce que cette méthode retourne. Les arguments fournis — par exemple l’identifiant du document à formater — sont envoyés au serveur, qui les injecte dans son template et renvoie non pas du texte brut, mais une liste de messages prêts à être transmis à Claude. Le client n’a donc jamais à connaître le contenu du prompt, ni à faire d’interpolation lui-même : il reçoit un bloc de conversation clé en main, qu’il ajoute à l’historique comme n’importe quel message utilisateur.

Utilisation dans le CLI

Dans notre application en ligne de commande, ces deux méthodes alimentent une expérience familière : quand l’utilisateur tape un slash (/), la liste des prompts disponibles apparaît comme un menu de commandes — exactement le comportement des commandes slash de Claude Code ou de Slack. La sélection d’un prompt comme « format » demande ensuite les valeurs de ses arguments, ici le document à formater. Le système enchaîne alors :

1. Récupère le prompt avec les arguments interpolés
2. Envoie le prompt complet à Claude
3. Claude exécute les appels d’outils nécessaires
4. Retourne le résultat formaté

Notez que l’étape 3 combine les fonctionnalités MCP entre elles : le prompt renvoyé par le serveur demande typiquement à Claude de lire puis réécrire un document, ce que le modèle accomplit en appelant les outils read_doc_contents et edit_document — exposés par le même serveur. Prompts et outils ne sont pas deux mondes séparés : les premiers orchestrent les seconds.

Ce que cette architecture apporte

Prenez du recul sur ce qui vient d’être construit. La logique du prompt — sa formulation, ses étapes, ses garde-fous — vit sur le serveur, à côté des données et des outils qu’elle mobilise, là où l’équipe qui connaît le domaine peut l’affiner. L’exécution, elle, reste côté client et Claude. Cette séparation nette a une conséquence très concrète : améliorer un prompt ne demande de redéployer aucun client. Le serveur change, tous les clients qui s’y connectent bénéficient immédiatement de la nouvelle version — le prompt engineering devient un service centralisé plutôt qu’un copier-coller dispersé dans chaque application.

Points clés à retenir

• list_prompts découvre dynamiquement les prompts du serveur — rien n’est codé en dur côté client
• get_prompt envoie les arguments au serveur et reçoit des messages prêts pour Claude, déjà interpolés
• Dans le CLI, les prompts deviennent des commandes slash, avec saisie guidée des arguments
• Un prompt MCP orchestre souvent les outils du même serveur — les fonctionnalités se combinent
• La logique des prompts est centralisée côté serveur : l’améliorer ne redéploie aucun client