Loading ToolBench
MCP (Model Context Protocol) server for driving Defold games through an in-game debug bridge: build, launch, play, and read a running game from any MCP client.
Server defines 9 tools with complete input schemas and descriptions. Naming follows verb_noun convention (defold_run, defold_stop, defold_input). Descriptions are substantive (80-180 chars), explaining what each tool does and when to use it. However, output schemas are not documented, LLMs cannot predict return structure. Parameter descriptions are present but lack format constraints (e.g., 'triggers' array has no item type hint in description). Error handling is basic: BridgeQueueTimeout and BridgeSocketTimeout are custom error types but lack recovery guidance in tool descriptions. No tool annotations (readOnlyHint/destructiveHint) despite clear risk levels (WRITE, DESTRUCTIVE, READ_ONLY). Composition is sound, each tool has one responsibility and output IDs chain to inputs.
Send a raw command to the in-game debug bridge and return the response, for advanced use cases not covered by the standard tools.
Inject one or more input actions (triggers) as pressed and released, then optionally fetch the screen.
Fetch the last n lines of the game's log (if the game maintains a mirrored log).
Build and launch a Defold game with the debug bridge enabled, spawning the engine detached and waiting for it to report the bridge port.
Fetch the current screen as text, representing what the agent 'sees' in the running game.
Skip the front-end and begin a game run, bypassing title/menu screens with optional configuration.
Output schemas not documented. LLMs cannot predict return structure for any tool (defold_screen, defold_state, defold_log, defold_bridge). Agents must guess what fields are available, risking failed downstream reasoning.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite explicit risk levels. defold_stop is DESTRUCTIVE, defold_run/defold_start are WRITE, but LLMs have no machine-readable signal to avoid unsafe composition.
Parameter 'triggers' in defold_input lacks item type hint in description. Schema shows array of strings, but description does not explain format (e.g., 'trigger names like up, down, action').
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 60 | 2026-07-28+ | v2 |
Read the compact game state as a JSON object, containing fields an agent needs to reason about the game.
Kill a running Defold game engine by process ID, terminating the entire process tree (including child processes on Windows).
Run the project's test script (if defined in projects.json) and return the output.
Error handling lacks recovery guidance in tool descriptions. BridgeQueueTimeout and BridgeSocketTimeout are thrown but tool descriptions do not tell LLMs what to do next (retry? check project config? increase timeout?).
Parameter 'opts' in defold_start is typed as object with no schema. LLMs cannot know what fields are valid or required. Should define a schema or provide enum examples.