Loading ToolBench
MCP server that provides tools to integrate with Godot game engine, enabling project management, scene manipulation, and editor control
This server has fundamental definition quality gaps across multiple dimensions. Tool names follow verb_noun convention reasonably well (write_file, read_file, godot_version, etc.), but descriptions are uniformly generic and lack LLM-optimization per pattern:tool-description baseline (target 50-200 chars; these are 20-40 chars, hitting the hard floor). Parameter descriptions exist but are minimal ('Absolute path to the file to write' is merely restating the parameter name, not explaining WHEN or WHY to use it). Output schemas are completely undocumented, there is no specification of what fields are returned or their types, violating pattern:tool and pattern:response-shaper. Error handling is present in code but not documented in schema/descriptions, LLMs cannot predict recovery paths. No input validation guidance, no idempotency markers, no destructive operation warnings (write_file, create_project, run_project, delete operations should warn about irreversibility). The create_project template enum is correct (3d, 2d, empty), but most tools lack enum constraints. File-writing tools expose path parameters without documented sanitization, inviting path traversal risks. No evidence of paginated responses for list_projects. The per-tool breakdown reveals consistent mediocrity: descriptions at 20-40 chars (HARD FLOOR triggered), schemas present but minimal, naming adequate. Average tool score: 42 across 12 tools.
Add a node
Create a new Godot project
Create a scene
Get debug output
Get scene tree
Get Godot version
Launch the Godot editor
List Godot projects in a directory
Descriptions uniformly under 40 characters, hitting HARD FLOOR. Examples: 'Write content to a file', 'Read content from a file', 'Get Godot version'. No LLM-optimization guidance on WHEN to use, prerequisites, or consequences. Baseline target is 50-200 chars per pattern:tool-description.
Output schemas completely undocumented. No specification of return fields, types, or structure visible in code. All tools return generic {content: [{type: 'text', text: string}]} but the actual fields returned by underlying godot commands module are unknown. LLMs cannot plan downstream calls or extract structured data. Violates pattern:tool (document output schema) and pattern:response-shaper (return structured objects with typed fields).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 39 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 40 | - | v1 |
Read content from a file
Run a Godot project
Stop running project
Write content to a file
Destructive operations (write_file, create_project, run_project, launch_editor, create_scene, add_node) lack explicit warnings in descriptions or error handling guidance. No confirmation pattern, no dry-run option. Agents cannot predict irreversibility or recovery steps. Violates pattern:confirmation-request and pattern:command-tool (modifications must declare consequences).
File path parameters (filePath in write_file, read_file; projectPath in multiple tools; directoryPath in list_projects) are undocumented for sanitization, traversal restrictions, or platform expectations. No description guidance on absolute vs relative paths, symlink handling, or permission requirements. Path traversal vectors are unmitigated. Violates pattern:tool-gateway (treat agent input as untrusted).
Parameter descriptions are purely mechanistic name echoes. Examples: 'Absolute path to the file to write' (restates 'filePath'), 'Directory to search for Godot projects' (restates 'directoryPath'). No guidance on accepted formats, constraints, ranges, or dependencies. Baseline from production: 72 chars avg param description; these are 30-50 chars with zero added value. Violates pattern:tool-description (descriptions must explain what parameters control).
list_projects returns an unstructured string ('Found X Godot projects: ...\n...'). No pagination, no structured array of project objects, no next_cursor or offset support. Large result sets will blow context. Violates pattern:paginated-result and pattern:response-shaper.
Error handling in code returns bare error.message as text. Example: 'Error writing file: EACCES'. No recovery guidance, no classification (retryable vs user-fixable), no actionable next steps. LLM receives a raw error and has no path forward. Violates pattern:recovery-guide (error responses must tell the LLM what to do next).
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) visible in code. Spec 2026-07-28 expects these in current implementations. LLMs cannot auto-classify safety and retry eligibility without explicit markers. This is a current pattern that should be present.