Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-defold build and launch my game, press space, then show screen"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server for driving Defold games through an in-game debug bridge. An MCP client can build the game, launch it, start a run, press inputs, and read the screen, state, and logs. Enough to playtest.
I built it because tests and simulators kept passing on builds of my own games that were actually broken or unplayable. Making the agent play the real build caught what they missed.
Tool | What it does |
| Build with the bridge enabled and launch, detached. Returns when the bridge answers a ping from this server, not merely when the run script says it should — the one exception being a ping that never leaves the per-port queue, which means another call is already connected there. Refuses instead of launching a second engine when anything is holding the port — a bridge that answers, and one that accepts the dial and then says nothing; |
| Quit the running game cleanly. |
| Skip the front-end (title/chargen) and begin a run. |
| Press input triggers in order, then return the screen. |
| The current screen as a composed text frame. |
| Compact game-state JSON (fields are game-defined). |
| Tail of the game's mirrored debug log. |
| Raw passthrough for game-specific bridge commands. |
| Run the project's headless test suite, if configured. A non-zero exit is a tool error, not a result. |
Related MCP server: godot-test-mcp
git clone https://github.com/haksanlulz/mcp-defold
cd mcp-defold
npm install
cp projects.example.json projects.json # register your gameRuns directly with tsx; no build step. PowerShell 7 (pwsh, cross-platform) runs the run and test scripts, and the unit suite spawns it too. Skip the projects.json step and the server still starts: the first tool call is what tells you to copy the example.
Two Node floors, and they are different numbers.
Runtime: package.json declares engines: >=18 and the single runtime dependency agrees, but that bound is declared, not measured. CI runs 20 and 22; nothing here has been run on 18.
Development: higher, and measured. npm install pulls vitest (4.1.11 as locked, engines: ^20.0.0 || ^22.0.0 || >=24.0.0), which pulls vite (8.2.2, ^20.19.0 || >=22.12.0). Without engine-strict that is a warning rather than a refusal, and this repo ships no .npmrc, so an install on 18 is untested rather than known-broken.
Node 20 or newer to work on it. Below that, treat the runtime bound as unverified.
{
"mcpServers": {
"defold": {
"command": "npx",
"args": ["tsx", "/absolute/path/to/mcp-defold/index.ts"]
}
}
}Env: MCP_DEFOLD_PROJECTS overrides the registry path; MCP_DEFOLD_DEFAULT picks the default project.
Four calls take an agent from nothing to a readable game. The frame below is real output from a private project, with its proper nouns replaced.
defold_run builds with the bridge compiled in, launches the engine detached, and returns once the bridge answers a ping from this server (with the queue exception noted in the table above):
== bob build (variant debug, bridge port 17890) ==
bob build OK
== launching dmengine (detached, log: .defold-tools/last-bridged-run.out) ==
pid 30032
== bridge LIVE on 127.0.0.1:17890 ==defold_start begins a run. It exists because injected input cannot reach a GUI front-end: a title screen or character creator has to be skipped through the bridge rather than driven. options is whatever your game's bridge accepts, here {"mode": "casual"}:
{"ok":true,"started":true}defold_input presses triggers in order and returns the screen. This is {"triggers": ["key_w", "key_w"]}, two steps north into a fountain:
== village | Day 1, Hour 08 ==
HP 17 / 17 | Stamina 25 / 25
...................>....................
.,,,,,,.,,,,,,,,,,.:.,,,,,.,,,,,,,,,,,,.
.,,,,,.,,,,,,,,,,,.:.,,,,,,,,,,,,,,,,,,.
.,,,,,,,,,,,,,,,,,.:..,,,,,,,,,,,,,,,,,.
.,,,,,,,,,,,,,,,::::.,,,,,,,,,,,,,,,,,,.
..........T^^^^^:######^^^^^..........T.
T..........^^^T^:#__p_#^^^^^..........T.
...........^^^^^:##+###^^^^^............
T.........T.....::::...........T........
...................:....................
...............v.v.:....................
...................:....................
...................:...::::::::.........
.........::::::%v%%%%%v%.#####:.........
.........:#####%%%%%%%%%.#___#:.........
.........:#_S_#%%%%%%%%%.+_H_#:.........
>:::::::::#___+%%%%O%%%%.#___#:::::::::>
..........#_N_#%%%%@%%%%v#___#..........
..........#####%%%%v%%%%.#####..........
...............%%%%%%%%%................
....................:%..................
.................%K%:%%M%%..............
.................%%%:%%%%%..............
.................#+#:#+#.#+#............
.................#_#:#_#.#_#............
.................###:###.###............
....................:...................
~~~~~~~~~~~~~~~~*=========~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~*=========~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~>~~~~~~~~~~~~~~~~~~
Contract: clear the west field — 0/3 — 14s
On the stone road | Silver 0 | Talents: none
The fountain bars the way.The last line is the game's answer to the second press. Nothing here is rendered by this server: the frame is text the game's own bridge composes, so an agent reads whatever a player would. defold_screen returns the same frame without pressing anything, defold_state returns the fields the game chooses to expose as JSON, and defold_stop quits the game cleanly.
Two things, both on the game side (this server is just the client):
An in-game bridge: newline-delimited JSON over localhost TCP answering ping / screen / state / input / start / log / quit. Protocol in PROTOCOL.md; working skeleton in example/bridge.lua. Gate it behind a debug flag so it never ships in release builds.
A run script: builds with the bridge compiled in, launches the engine detached, prints bridge LIVE on <port>.
The screen is text on purpose: compose whatever view carries your game's state (an ASCII map + HUD for a roguelike, a score readout for an arcade game).
Screens are text frames composed by the game's bridge; there are no pixel screenshots.
defold_input presses and releases each trigger; nothing can be held down.
Bridge input drives the in-game controller, not the GUI front-end; defold_start exists because injected input can't get past menus.
Run and test scripts are invoked through pwsh; there is no other runner.
Bridge calls are serialized per port, because the bridge answers one client per frame. Parallel tool calls queue rather than overlap, and each one's timeout covers its wait as well as its socket time.
That serialization is per call, not per tool. defold_input makes one call per trigger plus one for the screen, so a defold_screen fired in parallel can return a frame from the middle of the sequence. Drive one tool at a time when the order matters.
npm test # vitest: tool handlers against a fake in-process bridge (no Defold needed)
npm run smoke # spawn the real server over stdio and exercise its error paths (offline)
npm run typecheckTwo tiers, both offline. npm test is the unit tier: 66 tests in 2 files, run in about twenty seconds. Ten of them spawn a real pwsh to exercise the exit-code, marker and skip_build paths, so PowerShell 7 is a requirement of the unit tier as well as of the run scripts. One of the ten spends eight of those seconds waiting out a real queue timeout, which is the behaviour it is there to pin. npm run smoke spawns the real server as a child process over stdio and checks its error paths and the run-script marker contract; it needs no Defold install and no network. npm run typecheck reads index.ts, server.ts, smoke.ts and the tests, so the smoke harness is typechecked by the step that runs before it.
Counts, measured 2026-09-15:
app: 744 lines (find . -maxdepth 1 -name '*.ts' -not -name '*.test.ts' -not -name 'smoke.ts' | xargs wc -l; index.ts + server.ts). smoke.ts is another 298 lines of test harness.
tests: 1228 lines (find test -name '*.test.ts' | xargs wc -l), 66 it() blocks.
What they cover, by layer. The TCP bridge layer: timeout, unreachable port, non-JSON reply, a reply that parses into something other than an object (null, a number, a string, an array), a 70 KB reply split across chunks, a bridge that hangs up before replying (what a game quitting mid-request produces), a frame field that is not a string, five concurrent calls against a bridge that serves one at a time, a queued call's deadline, that a call which gives up while queued still frees the slot behind it, and which cause and which figure a timeout message carries in each of the two cases (queued, and dialed after a wait — the second also measured as elapsed time, so the remaining-budget arithmetic cannot be dropped without a test noticing). The registry loader: missing file, missing fields, non-string testScript, duplicate ports. The marker scan: each of its three verdicts, the precedence between them, and both of the paths that reach defold_run (failure marker, and an exit with no marker at all). The tool handlers: every tool driven through a real MCP client against a fake bridge that speaks the wire protocol, including input ordering, the failing-trigger message, argument validation on every argument the tools take (triggers, options, args and cmd, the wrong-typed tail and skip_build that are rejected rather than coerced, and project, where both a non-string and an empty string are errors rather than a silent fall-back to the default), a project name that is an Object.prototype key, the refuse-to-double-launch preflight in three cases (the ping answered, a ping that never leaves the queue, and a port that accepts the dial and never answers), the post-marker confirmation in all three of its outcomes (a bridge that answers, a port with nothing on it, and a ping still queued behind another call), the missing-root check, defold_log's tail default, defold_run's skip_build, defold_bridge's frame-or-JSON branch, and MCP_DEFOLD_DEFAULT project selection. defold_test's exit-code handling runs real pwsh scripts. A source-level guard pins the import surface to the stdio transport and the runtime dependency list to one entry.
Mutation probes, both re-run against the 66-test suite on 2026-09-15. Swapping the spread order in defold_start, so a caller's options.cmd overrides the fixed start command, turned exactly one test red: defold_start options cannot override the start command, with the other 65 green. Inverting the precedence in markerVerdict, so a failure marker outranks a success marker, turned exactly one test red: lets success outrank a failure printed earlier in the run, with the other 65 green. The source was restored after each run. Every fix in this suite's history carries its own probe in the commit that added it; these two are re-measured here because a green count is only true of the suite it was counted on.
Assertion policy: assert behavior and payloads, never that a function was called. A grep for toHaveBeenCalled finds zero sites in this suite; nothing was pruned.
This project was built with AI assistance (Claude). Correctness was established by the test suite (tool handlers driven end-to-end through a real MCP client against a fake in-process bridge that speaks the actual wire protocol, plus failure-path tests for the TCP layer), an offline smoke run that spawns the real server over stdio and checks its error paths (npm run smoke), and playtesting my own games with it. I review the code and am responsible for it.
MIT © Abishai James. Defold is a trademark of the Defold Foundation; this project is unofficial.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| cmd | Yes | Bridge command (e.g. 'ping', 'screen', 'advance') | |
| args | No | Extra fields merged into the request | |
| project | No | Registered project to target. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that args are merged into the request and that the return is the frame or JSON response. It doesn't mention error behavior, side effects, or whether this can mutate state, but for a passthrough tool the disclosed behavior is reasonable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no waste. The purpose, usage, and return behavior are all covered compactly, and the most important framing (fallback) is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a generic passthrough tool with 100% schema coverage and no output schema, the description covers the essential behavior: what it does, how args behave, and what it returns. It could mention error cases or the fact that cmd examples are in the schema, but it's largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all three parameters. The description adds a little meaning by explaining that args are merged and cmd is the command string, but it doesn't go beyond the schema's own descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('passthrough') and resource ('bridge command'), and explicitly frames it as a fallback for anything the named tools don't cover. It distinguishes itself from siblings by positioning itself as the catch-all, though it doesn't name a specific sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use this when the named tools don't cover the command. It doesn't enumerate exclusions or alternatives, but the fallback framing is explicit enough for an agent to route correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| project | No | Registered project to target. | |
| triggers | Yes | Trigger ids pressed in order, e.g. ["key_w","key_w","key_e"] |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool returns the screen after pressing, that triggers are action ids, and that it affects the in-game controller not the GUI. It misses edge cases like game-not-running or failure handling, but covers the core behavioral traits well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no fluff. The main purpose is front-loaded, followed by a critical note about usage order. Every sentence earns its place, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two parameters and no output schema, the description covers the essentials: what it does, how triggers are defined, what it returns, and a prerequisite. It could mention error conditions (e.g., game not running) but these are minor gaps for a straightforward input tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters. The description adds meaning by explaining that trigger ids are action ids from input bindings and giving an example, which goes beyond the schema's generic description. This is a meaningful addition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action (press input triggers) on a specific resource (the running game's action ids), and clarifies that it drives the in-game controller rather than the GUI. This clearly distinguishes it from sibling tools like defold_start or defold_screen, even without naming them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear usage context (press triggers in order) and a prerequisite (use defold_start to get past menus first). It does not explicitly list alternatives or when-not-to-use, but the note about bridge input vs GUI provides directional guidance. This is above average.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tail of the running game's mirrored debug log.
| Name | Required | Description | Default |
|---|---|---|---|
| tail | No | Lines from the end (default 40) | |
| project | No | Registered project to target. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It implies a read-only operation by using 'tail', but it does not explicitly state that it does not modify state, nor does it explain the 'mirrored' aspect, potential side effects, timeout behavior, or what happens if no game is running. The minimal description leaves key behavioral details unaddressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero wasted words. It immediately conveys the tool's core function. It is appropriately sized for a two-parameter tool with no annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with two optional parameters, the description is minimally enough to understand its purpose. However, it omits any mention of output format (plain text vs structured), whether the log is continuous, and edge-case behavior (e.g., game not running). Given no annotations or output schema, a bit more context would be needed for full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both 'tail' and 'project' are fully documented in the schema. The description adds no additional parameter meaning beyond what the schema already provides. Baseline 3 is appropriate because the schema handles the burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Tail of the running game's mirrored debug log' clearly identifies the tool as retrieving the end of a debug log for the running game. 'Tail' acts as a specific verb, and the resource (debug log) is explicit. It is easily distinguished from sibling tools like run/stop/start, which are lifecycle actions, so the intent is clear without being tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, nor any mention of when it should not be used. The description simply states what it does without routing the agent to a better fit or providing context like 'use this to check the game's recent output.' An agent must infer the use case entirely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| project | No | Registered project to target. | |
| skip_build | No | Skip the build; launch the existing build output (default false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses build time (~30-90s), that it waits for bridge response, and that launch is windowed/detached. It does not cover failure modes or error handling, but the core behavioral traits are well communicated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The action is front-loaded, timing is given, and the skip_build tip is integrated naturally. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 2 params and no output schema, the description covers build/launch behavior, timing, skip_build option, and prerequisite of stopping an existing game. Nothing essential for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds meaning beyond schema by explaining skip_build=true relaunches last build fast, and project is understood as the registered project. This extra context justifies a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: build with debug bridge and launch windowed/detached. It explicitly distinguishes from siblings by referencing defold_stop for stopping an existing game, so an agent can tell this is the launch/run tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage guidance: mentions skip_build=true for fast relaunch, and instructs to stop a running bridged game first with defold_stop. This gives clear when-to-use and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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).
| Name | Required | Description | Default |
|---|---|---|---|
| project | No | Registered project to target. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It explains the composed text frame nature and gives examples, but does not disclose whether the game must be running, what happens if no game is running, or whether this is a read-only operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence with a colon and parenthetical examples. It is front-loaded with the core purpose and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only screen inspection tool with one optional parameter, the description is mostly adequate. However, it does not state prerequisites (e.g., game must be running) or error behavior, which an agent might need to know.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single 'project' parameter, so the schema already documents it. The description adds no additional meaning about the parameter beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the running game's current screen as a composed text frame, with concrete examples (ASCII map + HUD, score readout). This distinguishes it from siblings like defold_state or defold_log.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies it is for inspecting the current visual screen of a running game, but does not explicitly state when to use it versus defold_state or defold_log. No exclusions or alternatives are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Begin a run, skipping the game's front-end (title menu / character creation) via the bridge start command, which GUI input can't reach. options is passed through to the game's bridge; what it accepts is per-game (a new-game seed, a character build, a scenario id).
| Name | Required | Description | Default |
|---|---|---|---|
| options | No | Game-defined start options, merged into the bridge start request | |
| project | No | Registered project to target. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It explains the mechanism (bridge `start` command), the bypass behavior, and the per-game nature of options. However, it does not disclose potential side effects, such as whether an existing run is stopped or whether the game must be in a particular state, leaving some behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The core behavior is front-loaded, and the follow-up sentence adds meaningful detail about options. Every phrase earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two optional parameters and no output schema, the description plus schema cover the essential invocation details: what the tool does, why it exists, and how options behave. The missing side-effect disclosure prevents it from being fully complete, but little else is absent for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline for this dimension is 3. The description adds meaning beyond the schema by providing concrete examples of per-game options (seed, character build, scenario id) and clarifying that options are passed through to the bridge. The `project` parameter is not mentioned, but the schema already describes it sufficiently.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific action ('Begin a run') and clearly specifies the distinguishing scope: skipping the game's front-end via the bridge `start` command. It also notes that GUI input cannot reach this path, which helps separate it from other start/run mechanisms.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use the tool: when you want to start a run and bypass the title menu/character creation. It explains why the bridge command is needed (GUI can't reach it), but it does not explicitly name alternative sibling tools or state a when-not-to-use condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compact state of the running game as JSON. Fields are game-defined (position, health, score, flags, whatever the bridge reports).
| Name | Required | Description | Default |
|---|---|---|---|
| project | No | Registered project to target. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It does disclose the JSON output format, game-defined fields, and that values come from the bridge, but it omits details about freshness, side effects, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tight sentence that communicates the core purpose and dynamic-field caveat without wasted words. The informal 'whatever' is minor but does not hurt clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple state-read tool with one optional parameter Footnote: this is adequate but minimal. It explains output format and field variability, but without an output schema or usage guidance, an agent still lacks some context about when to invoke it and what to expect beyond high-level JSON.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'project' is fully described in the schema as 'Registered project to target.' The description adds no additional meaning beyond that, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as returning the running game's state as JSON and notes that fields are game-defined. This differentiates it enough from siblings like defold_run, defold_input, and defold_log, though it lacks an explicit verb such as 'gets' or 'reads'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. It implies state retrieval but does not explain when to choose it over defold_screen, defold_log, or defold_bridge, nor does it mention any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Quit the running bridged game cleanly (sends the bridge quit command).
| Name | Required | Description | Default |
|---|---|---|---|
| project | No | Registered project to target. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavior. It adds the 'cleanly' qualifier and reveals the 'bridge quit command', but it does not state side effects, whether stopping is reversible, what happens if no game is running, or whether errors may occur. This is a thin behavioral description for a control action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence conveys the action and mechanism without any filler. Every word serves a purpose, making it appropriately concise and structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool, the description covers the core action and mechanism, and the schema fully documents the parameter. However, it omits usage context, preconditions, and consequence details that would help an agent safely invoke it, especially given the lack of annotations and output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with 'project' described as 'Registered project to target.' The tool description adds no additional parameter meaning beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Quit') and resource ('the running bridged game'), and clarifies the mechanism ('sends the bridge quit command'). It clearly distinguishes this from siblings like defold_run or defold_start, which naturally have the opposite purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus alternatives, nor does it mention prerequisites (e.g., a game must be running). It only implies usage through the verb 'Quit', which is insufficient for an agent deciding among several sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 tail when the failing assertion is further up than the default window. Can take minutes.
| Name | Required | Description | Default |
|---|---|---|---|
| tail | No | Lines from the end of the output (default 12) | |
| project | No | Registered project to target. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: it returns the tail on success, returns a tool ERROR with exit code on failure, warns that execution can take minutes, and explains the tail parameter's effect. This covers output format, error handling, and timing – all beyond what any structured annotation would provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each carrying essential information: the action, the success/error output, and the duration warning. It is front-loaded with the primary purpose and avoids any redundant phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the main behavior, error handling, and timing. It does not state what happens if no testScript is registered (only that it runs 'if' one is), but this is a minor omission. There is no output schema, yet the return behavior is described, so an agent can confidently call the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (both parameters described), so baseline is 3. The description adds value by advising to 'Widen `tail`' when the failure is further up, giving practical guidance beyond the schema's generic 'Lines from the end of the output'. This extra context justifies a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Run the project's headless test suite') with a clear resource ('the project') and distinguishes itself from siblings by focusing on tests rather than running/stopping the game. It also clarifies the condition ('if a testScript is registered'), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies usage (when you want to run tests) and notes a prerequisite (testScript registered), but it does not explicitly name alternatives or say when NOT to use this tool. The guidance is clear but not comparative; an agent could infer the distinction from the purpose but the description does not call out sibling tools like defold_run.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0defold_bridgedefold_inputdefold_logdefold_rundefold_screendefold_startdefold_statedefold_stopdefold_testScored 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.
MCP server to assist with JxBrowser development.
The MCP server for Azure DevOps, bringing the power of Azure DevOps directly to your agents.
The official MCP Server for the Mux API
