Loading ToolBench
Local-first, add-on-free MCP asset QA for headless Blender: executable discovery, bounded background scripts, structural FBX reimport checks, and four-view visual verification
Server has 4 tools with complete input schemas and descriptions. Naming follows verb_noun pattern (blender_locate, blender_run_script, blender_verify_*). Descriptions are adequate (50-150 chars) but lack actionable context for LLM selection. Parameters are typed with descriptions, but lack constraints (enums, ranges, patterns). Output schema is undocumented, responses are JSON text blobs without declared structure. Error handling is minimal; no recovery guidance. No tool annotations (readOnlyHint/destructiveHint). Security: tools accept optional blenderPath parameter (acceptable for local paths), but no validation against path traversal. Composition is reasonable, each tool has single responsibility, but blender_verify_* tools could benefit from clearer distinction in descriptions.
Resolve the local Blender executable used for background automation.
Run Blender in background mode with an explicit Python script and optional script arguments.
Verify FBX asset visually: rotation/scale residues, pivot placement, assembly gaps, and four-view renders.
Import an FBX in headless Blender and write/read a JSON verification result.
Output schema undocumented. Tools return JSON text via textResult() helper, but LLMs cannot infer response structure (fields, types, nesting). Breaks downstream tool chaining and forces LLM to parse unstructured output.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). blender_run_script and blender_verify_* are marked WRITE in metadata but lack destructiveHint in schema. Agents cannot determine retry safety.
Parameter constraints missing. timeoutMs accepts 0 - 600000 but no min/max declared in schema. scriptArgs is array but no item count limit. LLMs can pass invalid values (negative timeout, 10k args).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 65 | 2026-07-28+ | v2 |
Error handling lacks recovery guidance. runProcess() returns {exitCode, timedOut, output, outputTruncated} but no actionable error messages. If Blender fails, LLM sees raw stderr with no hint on next steps.
Descriptions lack WHEN-to-use context. 'Run Blender in background mode with an explicit Python script' does not explain when to call this vs blender_verify_fbx_reimport. LLMs cannot disambiguate similar tools.