ygopro-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| CONTROL_URL | Yes | HTTP control endpoint of the YGOPro client the MCP server should control, e.g. http://127.0.0.1:7788 for the host or http://127.0.0.1:7789 for the guest. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| control_stateB | Get the full duel state: turn, phase, LP, hand/field/grave/deck counts with card details, pending prompt counters. |
| control_wait_promptB | Long-poll until it is this client's turn to respond. Returns the prompt: seq (pass it back to control_act), curMsg (what kind of decision), and candidate counters. This is the main agent loop primitive. |
| control_actB | Submit a response for the prompt with the given seq. Use either i (int32 encoded response, e.g. idle (index<<16)|cmd, -1 for chain decline) or hex (raw response bytes, e.g. card selection "0100" = select 1 card at index 0). |
| control_readyA | Send CTOS_HS_READY (click the Ready button) for the current room. |
| control_actionsA | List the semantic actions available for the current prompt (id + kind + human label, e.g. summon/special summon/attack/chain/zone). The caller only picks an id; the client encodes the kernel response itself. |
| control_act_idB | Execute one of the actions returned by control_actions, by id. |
| control_lobbyA | Room/prep-screen state: our seat (0=host,1=guest), whether we are host, readiness of both seats, deck loaded, raw HS status bytes. Use this before ready/start. |
| control_deckA | Preload a deck by name (file under deck/*.ydk). Call before control_ready so the deck update is valid. |
| control_startA | Click "Start" (CTOS_HS_START). Only valid when we are the host (seat 0) and both players are ready. |
| control_surrenderB | Surrender the current duel (CTOS_SURRENDER). |
| control_chatB | Recent server chat / system messages (useful to see why a room was rejected or a duel was kicked). |
| control_joinB | Connect to a game server (LAN or a matchmade room). |
| control_msgA | Last raw server message (id, length, hex) - debug only. |
| control_healthC | Health check of the control layer. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 14 tools
Most tools map to distinct duel-control lifecycle stages (lobby, deck, ready, start, prompt, act, surrender), so selection is usually clear. The main overlap is the prompt-response group: control_act and control_act_id both submit a decision and differ mainly by encoding, though the raw-vs-semantic descriptions help.
All names share a consistent control_ namespace and snake_case formatting, making the set easy to scan. However, suffixes mix nouns (state, lobby, chat) and verbs (act, start, join) rather than following a pure verb_noun pattern.
Fourteen tools are well within a reasonable range for controlling a duel client, and each covers a distinct concern: session setup, prompt loop, action submission, state inspection, surrender, chat, and health. The debug/health/msg tools are minor extras but do not feel like bloat.
The surface covers join, deck preload, ready, start, prompt handling, action execution, state inspection, surrender, and chat, which is most of the duel session lifecycle. Minor gaps remain around explicit disconnect/leave and room creation or listing, with some room state visible only through chat or raw messages.