mcp-defold
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| MCP_DEFOLD_DEFAULT | No | Picks the default project | |
| MCP_DEFOLD_PROJECTS | No | Overrides the path to the projects registry file |
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 |
|---|---|
| defold_runA | Build the target project with the debug bridge enabled and launch it (windowed, detached). Returns when the bridge answers (~30-90s with a build). Pass skip_build=true to relaunch the last build fast. If a bridged game is already running, stop it first with defold_stop. |
| defold_stopB | Quit the running bridged game cleanly (sends the bridge quit command). |
| defold_startA | Begin a run, skipping the game's front-end (title menu / character creation) via the bridge |
| defold_inputA | Press one or more input triggers in the running game, in order, then return the screen. Trigger ids are the game's action ids from its input bindings (e.g. key_w, key_e, key_space). NOTE: bridge input drives the in-game controller, not the GUI front-end; use defold_start to get past menus first. |
| defold_screenA | The running game's current screen as a composed text frame: whatever view the game's bridge composes (an ASCII map + HUD for a glyph game, a score readout for an arcade game). |
| defold_stateB | Compact state of the running game as JSON. Fields are game-defined (position, health, score, flags, whatever the bridge reports). |
| defold_logB | Tail of the running game's mirrored debug log. |
| defold_bridgeA | Raw bridge command passthrough for anything the named tools don't cover. cmd = the bridge command string; args = an object merged into the request. Returns the frame (if any) or the JSON response. |
| defold_testA | Run the project's headless test suite (if a testScript is registered). Returns the tail of the output when the suite passes; a non-zero exit is a tool ERROR carrying the exit code and the same tail. Widen |
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
Each tool targets a distinct action or output channel, and the descriptions clarify the differences between launching, starting past menus, input, and observation. The only mild ambiguity is between defold_run and defold_start, since both relate to beginning a session, but their roles are clearly separated by the front-end skip distinction.
All tools share the defold_ prefix and use lowercase snake_case, which makes the set feel uniform. However, the second part mixes imperative verbs (run, stop, start, test) with nouns (input, screen, state, log, bridge), so the pattern is not perfectly consistent.
Nine tools is well-scoped for a game debugging bridge: build/launch, control, screen/state/log introspection, raw passthrough, and test execution are all covered without unnecessary duplication or bloat.
The tool surface covers the full lifecycle of a bridged Defold session: launching, stopping, advancing past menus, sending input, reading frames/state/logs, issuing arbitrary bridge commands, and running headless tests. The raw bridge passthrough fills any long-tail gaps, so there are no obvious dead ends.