Loading ToolBench
Narrow, allowlisted studio operations for game development: Godot project validation, testing, export, asset pipeline (Blender), engine management, and screenshot comparison.
25 tools with mostly complete schemas and descriptions, but significant gaps in parameter documentation and error handling guidance. Tool naming is generally clear (verb_noun pattern), but many parameter descriptions lack format constraints, ranges, and validation rules. Output schemas are not documented. Error recovery guidance is absent. Composition is reasonable, tools are single-purpose, but some lack the context needed for chaining (e.g., godot_* tools don't document what fields are returned). Average description length ~120 chars (below 194 baseline), and ~40% of parameters lack descriptions or have trivial ones.
Extract metadata from an asset file (image, model, audio, etc.)
Full parameter schema, types and defaults for one or more ops. Call this before using an op you have not used before.
List available bforge operations with one-line summaries. Filter by tag (prop, kit, env, char, build, material, uv, gameready, render, check, export) or by a search string. Start here if you are not sure what exists.
Run one bforge operation in the live Blender session. Scene state persists between calls, so ops compose. Returns the op's structured result plus any advisory notes.
Run several ops in order in one round trip. This is the efficient way to build an asset: reset, generate, unwrap, collide, render, export — all in one call. Stops at the first failure unless continue_on_error is set.
Inspect or control the Blender session: status shows what is loaded, reset clears the scene, restart replaces the Blender process (use if it becomes unresponsive).
Output schemas not documented. Tools like godot_collect_logs, engine_show_versions, asset_get_metadata return data but LLMs cannot see what fields to expect. This breaks downstream tool chaining and forces agents to guess field names.
Parameter descriptions lack format constraints and validation rules. E.g., 'game' parameter accepts pattern ^[A-Za-z0-9_\-/]+$ but description does not explain this constraint. LLMs cannot read JSON Schema patterns, they rely on description text.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 49 | 2026-07-28+ | v2 |
Export a Blender asset to game-ready formats
Render a preview image from a Blender asset
Validate a Blender asset file
Engine build is deliberately not runnable through MCP (hours-long compile). Run `just engine-build` in a terminal instead.
Report built templates and the locked in-repository WebGPU patch source
Classify engine merge conflicts
Fetch engine artifacts and dependencies
Show available engine versions
Capture a screenshot from a Godot game for visual regression testing
Capture a screenshot from a web-exported Godot game
Collect and return the most recent Godot project logs
Compare two screenshots and report pixel differences
Export a Godot game to a specified preset
Run performance benchmarks on a Godot game
Run Godot project tests
Validate a Godot project by running import-only check
Create a new game project from the template
Get studio health and status information in JSON format
List all available game projects (template and games/)
No error recovery guidance. Tools lack descriptions of what errors can occur and what the LLM should do next. E.g., godot_export does not explain what happens if the preset is invalid or the export fails.
Many tools with empty input schemas lack parameter descriptions. E.g., engine_fetch, engine_build, engine_classify_conflicts have {} input but no explanation of what they do or what side effects occur.
Destructive operations lack confirmation or dry-run support. engine_build, bforge_run_batch, and blender_export_asset modify state but offer no way for agents to preview or confirm before execution.