Loading ToolBench
MCP server for interfacing with Godot game engine. Provides tools for launching the editor, running projects, and capturing debug output.
This server has significant definition quality gaps. While tool names follow verb_noun conventions (launch_godot_editor, run_project, etc.), the descriptions are moderately detailed but many lack actionable context for LLM selection. Parameter schemas are present and mostly well-typed, but several descriptions lack sufficient detail about constraints, formats, and dependencies. Error handling is minimal, tools return basic success/failure without recovery guidance. Tool composition is reasonable but some tools combine multiple concerns (e.g., run_debug handles both execution and breakpoint setup). The server provides full TypeScript implementations visible in src/index.ts, though the provided snippet cuts off before showing complete tool handlers. No evidence of secret injection patterns, audit trails, or permission gates. Output schemas for most tools are not documented in the source provided.
Capture a screenshot from a Godot project
Get Godot development best practices and recommendations
Get detailed information about a Godot class from documentation
Launch the Godot editor for a project
Scan a Godot project for missing asset references
Dump the scene tree structure from a running Godot project
Run a project with debug session monitoring and breakpoint support
Missing output schemas: Tool definitions declare input schemas but no visible documentation of output structure (e.g., what does run_debug return? What fields are in DebugSession?). LLMs cannot plan downstream calls without knowing what they receive.
Insufficient parameter constraint documentation: Parameters like 'checkTypes' (list_missing_assets) accept an enum but the description does not explicitly list valid values or explain what happens if invalid values are passed. For 'toggle_debug_draw.mode', the enum is extensive but not all valid modes are documented in the description.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 57 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Run a Godot project
Run a specific scene from a Godot project
Search Godot documentation for classes, methods, properties, and signals
Toggle debug visualization modes in a running Godot project
Weak error handling: No evidence of recovery guidance in error messages. Tools do not document what to do if a project path is invalid, a scene is missing, or Godot executable is not found. Error responses should guide the LLM to alternative actions (e.g., 'Path not found. Try listing available projects with ...').
Missing descriptions or trivial descriptions: 'get_best_practices' has description 'Get Godot development best practices and recommendations' (54 chars), lacks context for when to call it vs. get_class_info or search_documentation. 'get_class_info' is even briefer (45 chars). Descriptions should explain the use case and how this tool differs from similar ones.
Parameter dependency not documented: 'run_debug' accepts 'breakpoints' with script and line number, but does not explain whether scripts must exist, whether line numbers are 1-indexed or 0-indexed, or what happens if a breakpoint is invalid. 'remote_tree_dump' has nested filters but interdependencies (e.g., 'depth' + 'nodeType') are not clarified.
Tool composition concern: 'run_debug' combines execution, breakpoint setup, and output capture. If the agent only wants to run with debugging enabled (no breakpoints), does it still work? Can breakpoints be set without running? Consider splitting into separate tools: 'set_breakpoints' + 'run_with_debugging' or exposing finer control.
No security/permission declaration: Tools that execute Godot editor or run projects ('launch_godot_editor', 'run_project', 'run_debug', etc.) are inherently destructive (they can modify project state, compile code, etc.) but do not declare required permissions. No audit trail mechanism visible for logging which agent called what and when.