Demo: Pokémon Showdown über MCP verbinden

Update vom 2. November 2026 — Le Chat ist nun Vibe. Seit dem 28. Mai 2026 wurde Le Chat in Vibe umbenannt (nach wie vor unter chat.mistral.ai): ein einzelner Agent für Arbeit und Code, der Ihre Gespräche, Einstellungen und Abonnements übernimmt. Die klassische Le Chat-Erfahrung bleibt im Chat-Modus verfügbar; im Work-Modus sind Agenten zu Fähigkeiten geworden (mit @ aufgerufen), Erinnerungen dienen als Wissensbasis und die Deep Search ist nun die Fähigkeit Deep Research. Pläne werden nun Mistral Free, Pro, Team und Enterprise genannt. Diese Lektion verwendet den Namen Vibe; beachten Sie, dass einige hier beschriebene Menüs möglicherweise andere Namen oder Positionen haben.

Lernen durch Spielen

Um das Erstellen und Nutzen eines benutzerdefinierten MCP-Connectors konkret zu veranschaulichen, nehmen wir uns einen unterhaltsamen, aber lehrreichen Fall vor: die Verbindung von Pokémon Showdown, dem berühmten Online-Pokémon-Kampfsimulator, mit Vibe über MCP. Dieser Fallstudienansatz wurde vom Mistral AI-Team während ihrer Live-Sitzungen vorgestellt und setzt Prinzipien um, die direkt auf jede professionelle Integration übertragbar sind. Das Thema ist leichtfüßig, aber die technischen Lehren sind es nicht.

Das Konzept

Pokémon Showdown ist eine Web-Plattform, auf der sich Spieler in strategischen, abwechselnden Kämpfen messen. Das Ziel des MCP-Servers ist es, Vibe zu ermöglichen, sich als Spieler mit der Plattform zu verbinden, einen Gegner herauszufordern, den Kampfunterstand zu analysieren – aktive Pokémon, HP, verfügbare Angriffe – und für jede Runde die beste Aktion zu wählen. Diese Übung ist wertvoll, weil sie vier Herausforderungen bündelt, die selten gemeinsam vorkommen: Echtzeit-Kommunikation, Zustandsverwaltung, sequenzielle Entscheidungsfindung und die Führung des Modells durch Tool-Antworten.

Architektur des MCP-Servers

Der Server stellt zunächst ein battle_player-Tool bereit, das einen Kampf initiiert. Es nimmt einen Benutzernamen als Parameter entgegen und gibt eine eindeutige Kampf-ID, den initialen Kampfunterstand (Pokémon jedes Teams, HP usw.) und Anweisungen für das Modell zurück, welche Tools als Nächstes aufgerufen werden sollen. Dieser dritte Aspekt ist keineswegs trivial: das Einbetten von Workflow-Anweisungen in Tool-Antwortwerte ist ein fortgeschrittenes MCP-Designmuster, auf das wir weiter unten noch einmal eingehen werden.

Als Nächstes folgt das Tool für Kampfaktionen. In jeder Runde muss Vibe zwischen einem Angriff, dem Wechseln von Pokémon oder dem Einsatz eines Items wählen. Das Tool erhält die Kampf-ID, die Aktionstyp und die ID des zu sendenden Angriffs oder Pokémon, gibt danach den neuen Kampfunterstand nach der Aktion zurück. Der Zyklus wiederholt sich, bis das Spiel endet, wobei jede Antwort als Ausgangspunkt für die nächste Entscheidung dient.

Das Muster der Antwort-Führung

Die wichtigste Lektion aus dieser Demo ist die Führung des Modells über Antwortwerte. Anstatt sich ausschließlich auf den Benutzerprompt zu verlassen, um den Workflow zu steuern, gleitet der MCP-Server Anweisungen in seine Antworten ein:

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.

Das Modell muss den nächsten Schritt nicht mehr raten: Es wird explizit informiert, zusammen mit den für den Moment gültigen Optionen. Das endgültige Verhalten entsteht aus einer Symbiose zwischen dem Benutzerprompt, der die allgemeine Absicht trägt („ein Pokémon-Kampf spielen”), den Tool-Beschreibungen, die erklären, wann und wie jedes Tool zu verwenden ist, und den Tool-Antworten, die angeben, welches Tool als Nächstes aufgerufen werden soll und mit welchen Argumenten.

Bevor dieses Server mit Vibe verbunden wird, führt das Mistral-Team es durch den MCP Inspector: Es wird überprüft, ob battle_player korrekt mit dem initialen Kampfunterstand antwortet, Kampfaktionen einzeln getestet, sichergestellt, dass Führungsanweisungen in den Antworten vorhanden sind, und das JSON-Format der Parameter und Antworten validiert. In einem abwechselnden Spiel stoppt schon die geringste Formatierungsfehler das Match; der Inspector ermöglicht das Debugging, ohne Konversationsnachrichten zu verbrauchen.

Übertragbare Prinzipien für Ihre Projekte

Das erste übertragbare Prinzip ist die Zustandsverwaltung in Antworten. Jedes System, das sich über Interaktionen hinweg entwickelt – ein Bestellprozess, eine CI/CD-Pipeline, ein Validierungsworkflow – profitiert davon, dass der Server den aktuellen Status und verfügbare Aktionen in jedem Schritt zurückgibt. Ein MCP-Server, der Bestellungen verwaltet, würde daher den Bestellstatus und die verfügbaren nächsten Schritte zurückgeben: Zahlung validieren, Versand bestätigen, Stornieren.

Das zweite Prinzip ist die Integration von Workflow-Anweisungen in Antworten statt in den Benutzerprompt, wo die Logik zu langwierig zu schreiben und fragil in der Wartung wäre. Ein Bereitstellungs-MCP-Server könnte beispielsweise nach einem erfolgreichen Schritt antworten: „Tests bestanden. Verwenden Sie das ‘deploy_staging’-Tool, um auf die Staging-Umgebung zu deployen.”

Das dritte Prinzip betrifft klare, typisierte Beschreibungen. Jedes Tool im Pokémon-Server verfügt über eine präzise Beschreibung, typisierte Parameter und dokumentierte Rückgabewerte, sodass das Modell genau weiß, was das Tool tut und welche Argumente bereitgestellt werden müssen. Übertragen auf Geschäftslogik bedeutet dies, explizit zu benennen (create_invoice statt process), nützlich zu typisieren (user_email: string statt user: string) und erwartete Rückgaben zu beschreiben.

Das vierte Prinzip ist die Zerlegung in spezialisierte Tools. Der Server bietet kein einziges play_pokemon-Tool an, das alles erledigt: Jede Aktion hat ihr eigenes Tool und ihre eigene Verantwortung. Ebenso sollten Sie start_order, add_item, confirm_payment und track_shipment bevorzugen gegenüber einem Alleskönner manage_order, der schwerer zu beschreiben ist und daher häufiger missbraucht wird.

Einschränkungen in Echtzeit

Die Demo hebt auch eine aktuelle Einschränkung hervor: MCP-Server in Vibe unterstützen noch nicht nativ langlaufende Aufgaben oder Echtzeit-Streaming, da jeder Tool-Aufruf auf eine synchrone Antwort wartet. Für Systeme, die kontinuierliche Updates erfordern, wird als empfohlener Workaround ein start_task-Tool ausgesetzt, das die Operation startet, und ein get_status-Tool, das der Benutzer aufruft, um den Fortschritt zu überprüfen.

Kernaussagen

• Der Fall Pokémon Showdown veranschaulicht fortgeschrittene MCP-Muster, die auf jedes Projekt übertragbar sind
• Antwort-Führung ist ein mächtiges Muster zur Orchestrierung mehrstufiger Workflows
• Tool-Beschreibungen, strukturierte Antworten und die Zerlegung in spezialisierte Tools sind die Schlüssel für einen guten MCP-Server
• Testen Sie immer mit dem MCP Inspector, bevor Sie mit Vibe integrieren
• Die Prinzipien sind identisch für ein Spiel oder einen komplexen Geschäftsprozess