Loading ToolBench
MCP backend for Godot 4 game engine development, providing tools for parsing, generating, and validating Godot scenes, scripts, and projects
Server has 14 well-named tools with consistent verb_noun patterns (list_, read_, parse_, scaffold_, validate_, analyze_, inspect_, run_, stop_). Descriptions are present and moderately detailed (avg ~120 chars), explaining WHAT each tool does. However, parameter schemas lack depth: most complex params (children, tree, signals, exports, methods) are typed as 'object' with only inline descriptions of nested structure, no formal JSON Schema for nested fields. Output schemas are entirely undocumented. Error handling is not visible in the provided code. Security considerations (path traversal, input validation) are not evident. Composition is strong, tools are single-responsibility and chainable (e.g., list_project → parse_scene → validate_scene). STDIO transport caps protocol readiness at 50.
Analyze coding conventions used across GDScript files in a project
Inspect a Godot scene tree by loading it headless and dumping the node hierarchy as JSON
List files in a Godot project directory, optionally filtered by type (scenes, scripts, resources)
Parse a .tscn or .tres file into a structured representation with nodes, resources, and connections
Read and parse the project.godot configuration file
Read and parse a GDScript (.gd) file, extracting class info, signals, exports, methods
Launch a Godot project (opens the game window or runs headless). Returns the PID for later stop.
Complex nested parameters (children, tree, signals, exports, methods) are typed as 'object' with only inline text descriptions of structure. No formal JSON Schema for nested fields, making it impossible for LLMs to understand the exact shape of nested objects or validate them programmatically.
Output schemas are completely undocumented. Tools like parse_scene, read_script, and inspect_runtime return structured data, but the response format is not specified. LLMs cannot plan downstream tool calls or extract fields without guessing.
No error handling guidance visible. Tools like run_project and validate_with_godot have timeouts but no documented error responses, recovery steps, or error classification (retryable vs fatal). LLMs cannot self-correct on failure.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 56 | 2026-07-28+ | v2 |
Generate a behavior tree resource (.tres) from a tree specification
Generate a .tscn scene file from a specification (root type, children, scripts)
Stop a previously launched Godot project instance
Validate a .tscn scene file: check resource paths, node types, parent references, duplicate names
Heuristic validation of a GDScript file: extends class, signal syntax, export types, brackets, indentation
Validate a GDScript file using Godot's own parser (more accurate than heuristic validation)
Generate and write a GDScript (.gd) file from a specification
Path traversal and input validation not evident. Tools accept 'projectPath' and 'filePath' parameters without documented constraints. LLMs could pass '../../../etc/passwd' or absolute paths outside the project, risking security issues.
Destructive operations (write_script, scaffold_scene, scaffold_behavior_tree) lack confirmation or dry-run support. An LLM mistake could overwrite user files. No idempotent hints or confirmation patterns visible.