Loading ToolBench
MCP server for managing and interacting with Godot Engine projects, including scene creation, project execution, exports, and editor control
This Godot MCP server has functional tool definitions with schemas and descriptions present, but significant gaps in LLM-optimization, parameter descriptions, error handling, and output documentation. Tool naming is generally clear (verb_noun pattern) and schemas use proper JSON types, but descriptions lack depth and actionability. Many parameters lack descriptions entirely. Error responses provide some guidance but are inconsistent. The server operates at a 'fair/poor' level, typical of community implementations that prioritize functionality over LLM ergonomics.
Create a new Godot scene at the specified path with the given root node type. The scene will be created inside the project located at 'project_path'. Returns: ToolResponse.model_dump(by_alias=True)
Export meshes from a scene as a MeshLibrary resource.
Return the version string of the Godot executable.
Retrieve comprehensive information about a Godot project.
Get the file and directory structure of a Godot project.
Return the version string of the Godot executable.
Launch the Godot editor for a specific project. Opens the Godot editor in edit mode (-e flag) for the project at the given path. The editor runs asynchronously and does not wait for it to close.
Duplicate tools: get_version and get_godot_version are identical. One should be removed to avoid LLM confusion.
get_project_info has no visible input schema in provided code. Tool definition shows description but schema is not documented. LLM cannot determine parameter requirements.
Parameter descriptions missing or minimal across multiple tools. E.g. 'scene' in run_project lacks description entirely; 'root_node_type' in create_scene lacks constraints (what node types are valid?); 'max_depth' lacks explanation of behavior when -1 vs positive integers.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 52 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 35 | - | v1 |
Recursively search for all Godot projects in a directory.
Load a sprite texture into a Sprite2D, Sprite3D, or TextureRect node in a scene.
Run the Godot project and capture output.
Save changes to a scene file, optionally to a new path.
Tool descriptions are generic and lack LLM-actionable guidance. Examples: 'Run the Godot project and capture output' (50 chars) doesn't explain when to use vs launch_editor, what output is captured, or error recovery. 'Retrieve comprehensive information about a Godot project' (59 chars) doesn't specify what 'comprehensive' includes or what fields the response contains.
No output schemas documented. Tools like get_project_structure, get_project_info, and list_projects return complex nested structures, but no schema is provided for what fields the LLM should expect. This forces LLM to infer from name alone.
Error handling is reactive but not prescriptive. export_mesh_library returns structured errors with suggestions, but other tools (e.g. run_project, load_sprite) have no visible error handling. When these tools fail, LLM has no guidance on recovery.
No pagination or limits on result-returning tools. list_projects may return hundreds of results unbounded. get_project_structure accepts max_depth but no limit on total result size. Large responses will exhaust LLM context and dilute signal.
Destructive operations (create_scene, save_scene, export_mesh_library) lack confirmation or dry-run support. Agents can create unwanted files or overwrite existing ones without safeguards. No dry_run parameter offered.