Loading ToolBench
MCP server that gives AI assistants eyes and hands in the Godot editor: scene editing, input injection, deterministic game-time control, and live runtime state for agent-driven playtesting
Godot MCP demonstrates solid foundational quality with 22 well-organized tools covering a complex domain (scene editing, runtime state, profiling). All tools have descriptions (avg 120 chars) and explicit input schemas with enums and type constraints. However, several patterns are underutilized: output schemas are not documented in tool definitions, error recovery guidance is absent, and parameter descriptions lack actionable constraints (ranges, formats, examples of valid values). The 'action' enum pattern (used across all tools) is pragmatic but creates a single point of ambiguity, LLMs must read descriptions to distinguish 'godot_scene open' from 'godot_scene_read get_tree'. Read-only tool duplication (godot_node vs godot_node_read, godot_scene vs godot_scene_read) adds cognitive load without clear separation benefits. Naming is verb-forward and clear; schemas are present but sparse on output documentation.
Animation query, playback, and editing: list animations, play/stop playback, and edit animation tracks
Read-only animation inspection: list animations and query animation data without modification
Fetch Godot Engine documentation with smart extraction: retrieve class docs, method signatures, and property descriptions
Editor control: run/stop the game, take screenshots, manage editor state, and access debug logs
Read-only editor inspection: query editor state, current scene, and debug information without modification
Run GDScript inside the running game for test scenario setup: one-shot state mutations plus persistent holder-managed nodes, behind a denylist accident guard
Deterministic game-clock control: freeze the running game, step a bounded slice of game time with inputs, then thaw — so observation is not racing ahead between tool calls
Output schemas not documented in tool definitions. LLMs cannot plan downstream calls or extract required fields without knowing what each action returns. E.g., godot_runtime_state.get_state returns structured JSON but the schema is not visible in the tool definition.
Parameter descriptions lack actionable constraints. E.g., 'path' parameters do not specify format (absolute vs relative, forward vs backslash), 'width'/'height' in godot_editor screenshot lack min/max bounds, 'delta_ms' in godot_game_time states max 50000 but no minimum. LLMs cannot validate inputs without explicit ranges.
Read-only tool duplication creates cognitive load. godot_node and godot_node_read, godot_scene and godot_scene_read, etc. are separate tools with overlapping names. LLMs must reason about which to call; a single tool with a 'read_only' mode or capability flag would be clearer.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 53 | 2025-06-18+ | v2 |
Input injection for testing running games: named actions, joypad buttons, analog axes, keyboard keys with modifiers, mouse-look, and text typing
Node manipulation: create, delete, rename, reparent, and inspect nodes in the scene tree
Read-only node inspection: query node properties, children, and metadata without modification
Performance profiling: capture profiler snapshots, analyze per-frame time series with spike detection, inspect active processes, and query signal connections
Project information: read project settings, check for staleness, and query project metadata
Read-only project inspection: query project settings and metadata without modification
Resource inspection: query SpriteFrames, TileSet, Materials, and other resource data
Read-only resource inspection: query resource data without modification
Observe live game entity state as structured JSON: positions, velocities, animation state, and custom _mcp_state() data. Works for both 2D and 3D scenes.
Scene management: open, save, create, close, and query scenes in the Godot editor
3D spatial information and bounding box tools: query 3D world data, compute bounds, and inspect spatial nodes
Read-only scene inspection: query scene structure, node hierarchy, and scene metadata
TileMapLayer and GridMap editing: paint tiles, erase tiles, and query tilemap data
Read-only tilemap inspection: query tilemap data without modification
Detect silently corrupt procedurally generated mesh data: inside-out winding, dropped triangles, degenerate UVs, NaN normals/tangents. Findings carry their likely cause and fix.
Error handling and recovery guidance absent. No tool descriptions explain what to do if a call fails (e.g., 'If scene not found, try godot_project get_settings to verify project path'). LLMs have no recovery path on errors.
godot_exec tool accepts arbitrary GDScript with only a denylist guard. Description does not explain what the denylist blocks, what happens on syntax errors, or how to debug failed scripts. High-risk tool needs clearer error guidance and constraint documentation.