DesyncedMCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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 | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| game_statusA | Connect to the running game's Lua debugger and report a live snapshot: tick, whether a map is loaded, player faction, entity counts. Fails gracefully when the game is not running with -moddev. |
| game_logsA | Return the recent output captured live from the running game (print(), errors, warnings, BOOT lines) via the debugger link. The buffer accumulates while this MCP server stays connected; it survives game crashes up to the moment of death. |
| game_evalA | Execute a Lua chunk inside the running game's VM through the debugger and return its result. Use 'return ' to get values back. Full game API available (Map, Game, data, UI...). The VM answers only while executing Lua (in menu or paused game it can time out). Simulation writes from here can desync multiplayer — fine in single player. |
| game_reloadA | Trigger Debug.Reload() in the running game: reloads all mod Lua from disk exactly like pressing F7 in-game. Use after deploying mod changes to the game's mods directory. |
| search_lua_apiA | Search the official Desynced Lua API reference (modules Action/Debug/Game/Input/Map/Tool/Twitch/UI/View and metatables Component/Entity/Faction/ItemSlot/ModPackage/Register/Widget). Returns matching lines with trailing context (signatures + descriptions). |
| search_game_sourceA | Regex search over the Lua/JSON source of the base game ('main' package) and all mods in the workspace. Returns file:line matches with context. Use to find how the base game defines/uses something before overriding it in a mod. |
| get_game_logsC | Tail the newest Desynced log file (game must run with -log for a log file to be written; -moddev recommended too). Shows Lua errors, warnings and print() output. Optionally filter lines by regex. |
| list_modsA | List mods in the game's mods directory (what the game will actually load) with id/name/version from each def.json, plus mods present in the workspace, to spot version drift between both. |
| read_game_fileB | Read a file from the workspace (base game 'main' package or any mod) by relative path, with optional line range. Example: 'main/ui/FrameView.lua'. |
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 9 tools
Most tools are clearly distinct: game_status, game_reload, and game_eval each target different game actions, while search_lua_api and search_game_source have separate scopes. The only potential confusion is between game_logs (live debugger buffer) and get_game_logs (tail log file), but their descriptions clarify the difference. Overall, boundaries are well-defined with one minor overlap.
The naming pattern is largely verb_noun in snake_case (e.g., search_lua_api, list_mods, read_game_file), but there is a minor inconsistency: game_logs vs get_game_logs both refer to logs but use different prefixes. The game_ prefix for three tools and separate prefixes for others is slightly mixed but still predictable and readable.
With 9 tools, the set is well-scoped for a game modding/debugging server. Each tool serves a concrete function—checking status, reloading, evaluating, searching, reading files, listing mods, and retrieving logs—without unnecessary bloat. This falls comfortably within the ideal 3-15 range.
The tool surface covers the core workflows for mod development and debugging: connecting, inspecting state, executing code, searching reference and source, retrieving logs from two sources, and managing mods. Minor gaps include lack of write/update operations for game files and no direct tool to manage mod installation, but these are not essential for the stated purpose and can be worked around.