Demo: Connecting Pokémon Showdown via MCP

Update November 2, 2026 — Le Chat is now Vibe. As of May 28, 2026, Le Chat has been rebranded as Vibe (still at chat.mistral.ai): a single agent for work and code, carrying over your conversations, settings, and subscriptions. The legacy Le Chat experience remains available in Chat mode; in Work mode, agents have become skills (invoked with @), memories serve as the knowledge base, and deep search is now the Deep Research skill. Plans are now called Mistral Free, Pro, Team, and Enterprise. This lesson uses the name Vibe; note that some menus described here may have changed names or locations.

Learn by playing

To concretely illustrate creating and using a custom MCP connector, we’ll tackle a fun but instructive case: connecting Pokémon Showdown, the famous online Pokémon battle simulator, to Vibe via MCP. This case study, presented by the Mistral AI team during their live sessions, implements principles directly transferable to any professional integration. The subject is lighthearted, but the technical lessons are not.

The concept

Pokémon Showdown is a web platform where players face off in strategic, turn-based battles. The goal of the MCP server is to allow Vibe to connect to the platform as a player, challenge an opponent, analyze the battle state—active Pokémon, HP, available moves—and choose the best action each turn. This exercise is valuable because it concentrates four challenges rarely found together: real-time communication, state management, sequential decision-making, and guiding the model through tool responses.

MCP server architecture

The server first exposes a battle_player tool that initiates a battle. It takes a username as a parameter and returns a unique battle ID, the initial battle state (each team’s Pokémon, HP, etc.), and instructions for the model on which tools to call next. This third element is far from trivial: embedding workflow instructions in tool return values is an advanced MCP design pattern, which we will revisit below.

Next comes the battle action tool. Each turn, Vibe must choose between attacking, switching Pokémon, or using an item. The tool receives the battle ID, the action type, and the ID of the move or Pokémon to send out, then returns the new battle state after the action. The cycle repeats until the game ends, with each response serving as the starting point for the next decision.

The response-guidance pattern

The most important lesson from this demo is guiding the model via return values. Instead of relying solely on the user prompt to direct the workflow, the MCP server slips instructions into its responses:

Result: Battle started. Your active Pokémon is Pikachu (HP: 100%).
The opponent sent out Charizard.

→ Use the 'choose_move' tool to select an attack,
  or 'switch_pokemon' to change Pokémon.
  Available moves: Thunderbolt, Surf, Quick Attack, Protect.

The model no longer has to guess the next step: it is told explicitly, along with the valid options for the moment. The final behavior emerges from a symbiosis between the user prompt, which carries the general intent (“play a Pokémon battle”), the tool descriptions, which explain when and how to use each tool, and the tool responses, which specify which tool to call next and with what arguments.

Before connecting this server to Vibe, the Mistral team runs it through the MCP Inspector: verifying that battle_player responds correctly with the initial battle state, testing battle actions one by one, ensuring guidance instructions are present in the responses, and validating the JSON format of parameters and responses. In a turn-based game, the slightest formatting error stops the match; the Inspector allows debugging without consuming conversation messages.

Principles applicable to your projects

The first transferable principle is state management in responses. Any system that evolves over interactions—an order process, a CI/CD pipeline, a validation workflow—benefits from the server returning the current state and available actions at each step. An MCP server managing orders would thus return the order status and available next steps: validate payment, confirm shipment, cancel.

The second is integrating workflow instructions in responses rather than in the user prompt, where the logic would be lengthy to write and fragile to maintain. A deployment MCP server might, for example, respond after a successful step: “Tests passed. Use the ‘deploy_staging’ tool to deploy to staging.”

The third concerns clear, typed descriptions. Each tool in the Pokémon server has a precise description, typed parameters, and documented return values, so the model knows exactly what the tool does and what arguments to provide. Applied to business logic, this means naming explicitly (create_invoice rather than process), typing usefully (user_email: string rather than user: string), and describing expected returns.

The fourth is decomposition into specialized tools. The server does not offer a single “play_pokemon” tool that handles everything: each action has its own tool and responsibility. Similarly, prefer start_order, add_item, confirm_payment, and track_shipment over a catch-all manage_order, which is harder to describe and therefore more often misused.

Real-time limitations

The demo also highlights a current limitation: MCP servers in Vibe do not yet natively support long-running tasks or real-time streaming, as each tool call waits for a synchronous response. For systems requiring continuous updates, the recommended workaround is to expose a start_task tool that launches the operation and a get_status tool that the user calls to check progress.

Key takeaways

• The Pokémon Showdown case illustrates advanced MCP patterns applicable to any project
• Response guidance is a powerful pattern for orchestrating multi-step workflows
• Tool descriptions, structured responses, and decomposition into specialized tools are the keys to a good MCP server
• Always test with the MCP Inspector before integrating with Vibe
• The principles are identical for a game or a complex business process