Skip to main content
Glama
pzalutski-pixel

godotlens-mcp

by pzalutski-pixel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

debug_run

Runs the project from the open Godot editor and returns captured output, structured errors with call stacks, and exit status, so you can verify game behaviour without pressing F5.

Instructions

Run the project from the open Godot editor and collect what it prints. Returns: captured output, structured errors with call stacks, whether the game exited, and any stop reason. THIS CLOSES THE LOOP: edit, sync, run, and read the actual behaviour, without the developer pressing F5 or pasting console output back. The editor has ONE run slot: a second debug_run stops the first game. Set breakpoints with debug_set_breakpoints BEFORE calling this if you want execution to pause. Long-running games keep going - use debug_output to keep reading and debug_terminate to stop.

Input Schema

NameRequiredDescriptionDefault
argsNoExtra engine flags appended to the game's command line, e.g. ["--headless"] to run with no window, ["--fixed-fps", "60"], ["--debug-collisions"]
sceneNoWhich scene to run: 'main' (default), 'current', 'pinned', or a res:// path
collectNoSeconds to collect output before returning (default 10)
timeoutNoSeconds to wait for the game to start (default 60)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.2.0
    • addedInput schema / properties / args
      Added value: +{
+  "description": "Extra engine flags appended to the game's command line, e.g. [\"--headless\"] to run with no window, [\"--fixed-fps\", \"60\"], [\"--debug-collisions\"]",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
  2. Addedv1.1.1

TDQS

A4.1/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Adds substantial context beyond the annotations: the editor's single run slot means a second call kills the running game, the game keeps running after output is collected, and breakpoints must be set beforehand. With destructiveHint/idempotentHint already declaring a non-idempotent, non-read action, this adds the concrete state-interaction consequences an agent needs.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the core action and return values before the operational caveats. Slightly verbose and uses emphatic phrasing ('THIS CLOSES THE LOOP'), but every sentence conveys actionable information rather than filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description itself covers the return contract (captured output, errors with call stacks, exit flag, stop reason) plus the lifecycle of long-running games and the breakpoint prerequisite. Nothing essential to invoking and interpreting this tool is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and each parameter already carries a detailed description with examples (--headless, '--fixed-fps', '60', scene selectors like 'main'/'current'/'pinned'). The prose adds nothing about parameter syntax, so the baseline of 3 is correct.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Run the project from the open Godot editor and collect what it prints') and spells out what comes back (captured output, structured errors with call stacks, exit status, stop reason). However, it never distinguishes this from the closely-related sibling runtime_run, which an agent must disambiguate by opening both schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear conditional guidance: set breakpoints with debug_set_breakpoints BEFORE calling if pauses are wanted, use debug_output to keep reading a long-running game, and debug_terminate to stop it. It also warns that a second debug_run stops the first. It stops short of stating when to prefer this over runtime_run, so it is not fully exhaustive.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools