Démo : Connecter Pokémon Showdown en MCP

Apprendre par le jeu

Pour illustrer concrètement la création et l’utilisation d’un connecteur MCP personnalisé, nous prenons un cas ludique mais instructif : connecter Pokémon Showdown, le célèbre simulateur de combats Pokémon en ligne, à Le Chat via MCP. Ce cas d’étude, présenté par l’équipe Mistral AI lors de ses sessions live, met en œuvre des principes directement transposables à n’importe quelle intégration professionnelle. Le sujet est léger, les leçons techniques ne le sont pas.

Le concept

Pokémon Showdown est une plateforme web où des joueurs s’affrontent dans des combats stratégiques au tour par tour. L’objectif du serveur MCP est de permettre à Le Chat de se connecter à la plateforme en tant que joueur, de lancer un défi contre un adversaire, d’analyser l’état du combat — Pokémon en jeu, PV, attaques disponibles — et de choisir la meilleure action à chaque tour. L’exercice est intéressant parce qu’il concentre quatre difficultés rarement réunies : communication en temps réel, gestion d’état, prise de décision séquentielle et guidage du modèle par les retours d’outils.

Architecture du serveur MCP

Le serveur expose d’abord un outil battle_player, qui initie un combat. Il prend en paramètre un nom d’utilisateur et retourne un identifiant de combat unique, l’état initial du combat (Pokémon de chaque équipe, PV, etc.) et des instructions destinées au modèle sur les outils à appeler ensuite. Ce troisième élément n’a rien d’anecdotique : inclure des instructions de workflow dans les valeurs de retour d’un outil est un pattern avancé de conception MCP, et nous y revenons plus bas.

Vient ensuite l’outil d’action de combat. À chaque tour, Le Chat doit choisir entre attaquer, changer de Pokémon ou utiliser un objet. L’outil reçoit l’identifiant du combat, le type d’action et l’identifiant de l’attaque ou du Pokémon à envoyer, puis retourne le nouvel état du combat après l’action. Le cycle se répète jusqu’à la fin de la partie, chaque retour servant de point de départ à la décision suivante.

Le pattern de guidage par retour

La leçon la plus importante de cette démo est le guidage du modèle par les valeurs de retour. Plutôt que de compter sur le seul prompt utilisateur pour diriger le workflow, le serveur MCP glisse les consignes dans ses réponses :

Résultat : le combat a commencé. Votre Pokémon actif est Pikachu (PV : 100 %).
L'adversaire a envoyé Dracaufeu.

→ Utilisez l'outil 'choose_move' pour sélectionner une attaque,
  ou 'switch_pokemon' pour changer de Pokémon.
  Attaques disponibles : Tonnerre, Surf, Vive-Attaque, Protection.

Le modèle n’a plus à deviner l’étape suivante : elle lui est indiquée, avec les options valides du moment. Le comportement final naît alors d’une symbiose entre le prompt utilisateur, qui porte l’intention générale (« joue un combat Pokémon »), les descriptions d’outils, qui disent quand et comment utiliser chaque outil, et les retours d’outils, qui précisent quel outil appeler ensuite et avec quels arguments.

Avant de connecter ce serveur à Le Chat, l’équipe Mistral le passe au MCP Inspector : vérifier que battle_player répond correctement avec l’état initial du combat, tester les actions de combat une à une, s’assurer que les instructions de guidage sont bien présentes dans les retours, et valider le format JSON des paramètres et des réponses. Dans un jeu au tour par tour, la moindre erreur de format interrompt la partie ; l’Inspector permet de déboguer sans consommer de messages de conversation.

Principes applicables à vos projets

Le premier principe transposable est la gestion d’état dans les retours. Tout système qui évolue au fil des interactions — un processus de commande, un pipeline CI/CD, un workflow de validation — gagne à ce que le serveur retourne l’état actuel et les actions possibles à chaque étape. Un serveur MCP gérant des commandes retournerait ainsi l’état de la commande et les suites disponibles : valider le paiement, confirmer l’expédition, annuler.

Le deuxième est l’intégration des instructions de workflow dans les retours plutôt que dans le prompt utilisateur, où la logique serait longue à écrire et fragile à maintenir. Un serveur MCP de déploiement peut par exemple répondre, après une étape réussie : « Les tests sont passés. Utilisez l’outil ‘deploy_staging’ pour déployer en pré-production. »

Le troisième tient aux descriptions claires et typées. Chaque outil du serveur Pokémon possède une description précise, des paramètres typés et des valeurs de retour documentées, si bien que le modèle sait exactement ce que fait l’outil et quels arguments fournir. Appliqué au métier, cela signifie nommer explicitement (create_invoice plutôt que process), typer utilement (user_email: string plutôt que user: string) et décrire les retours attendus.

Le quatrième est la décomposition en outils spécialisés. Le serveur ne propose pas un unique outil « jouer_pokemon » qui gérerait tout : chaque action a son outil et sa responsabilité propre. De la même façon, préférez start_order, add_item, confirm_payment et track_shipment à un fourre-tout manage_order, plus difficile à décrire et donc plus souvent mal employé.

Les limites du temps réel

La démo met aussi en évidence une limite actuelle : les serveurs MCP dans Le Chat ne supportent pas encore nativement les tâches longues ni le streaming en temps réel, chaque appel d’outil attendant une réponse synchrone. Pour les systèmes nécessitant des mises à jour continues, le contournement recommandé consiste à exposer un outil start_task qui lance l’opération et un outil get_status que l’utilisateur appelle pour vérifier l’avancement.

Points clés à retenir

• Le cas Pokémon Showdown illustre des patterns MCP avancés applicables à tout projet
• Le guidage par retour d’outil est un pattern puissant pour orchestrer des workflows multi-étapes
• Les descriptions d’outils, les retours structurés et la décomposition en outils spécialisés sont les clés d’un bon serveur MCP
• Testez toujours avec le MCP Inspector avant d’intégrer à Le Chat
• Les principes sont identiques pour un jeu ou pour un processus métier complexe