← ClaudeAtlas

mcp-driverlisted

Runtime debugging and live project inspection via godot-mcp. Use when headless tools cannot diagnose the problem: code compiles but runtime behavior is wrong, tests pass but the game does not work as expected, or you need to inspect live state (node tree, console output, rendering). Escalation trigger: a task has failed 2+ times through the headless path (headless-build, gdunit-driver), or the issue is inherently runtime-only (visual glitches, input not responding, physics behaving unexpectedly at runtime). DO NOT use for: syntax/compile errors (use headless-build), unit test failures (use gdunit-driver), API lookups (use godot-api). Requires: godot-mcp MCP server registered as "godot" (@coding-solo/godot-mcp).
RandallLiuXin/GodotMaker · ★ 219 · AI & Automation · score 79
Install: claude install-skill RandallLiuXin/GodotMaker
# MCP Driver — Runtime Debug & Inspection $ARGUMENTS ## When to use this skill MCP is the **upgrade path** when faster tools hit a wall. The fast loop handles most issues: | Problem type | Fast path (no MCP) | |---|---| | Syntax / parse error | headless-build | | Unit test failure | gdunit-driver | | API lookup | godot-api | Escalate to MCP when: - **Compile-pass / runtime-fail** — headless-build says OK but something is wrong when the game actually runs - **Test-pass / behavior-wrong** — unit tests pass but the game does not behave correctly in practice - **Visual issue** — screen is black, sprites missing, z-order wrong, camera not following - **Input not working** — keys/mouse/gamepad produce no response at runtime - **Physics misbehavior at runtime** — objects pass through each other, wrong gravity, jittery movement - **Need live state** — want to see the actual node tree, console output, or runtime errors - **Repeated headless failure** — a fix has been attempted 2+ times via headless path without success If none of these apply, use the fast path skill instead. ## Debug-fix loop (overview) When you escalate to MCP, follow this loop. Max **3 iterations** before asking the user for help. ``` 1. RUN — run_project (optionally with a specific scene) 2. CAPTURE — get_debug_output → collect errors, warnings, prints 3. ANALYZE — parse output, identify root cause 4. FIX — modify code / scene / config to address the issue 5. VERIFY — stop_project → run_proj