Loading ToolBench
MCP server that integrates Blender 3D with Claude AI via the Model Context Protocol, enabling scene creation, manipulation, asset management, and rendering through MCP tools
This MCP server has significant definition quality gaps across naming, descriptions, parameter documentation, and schemas. While tool names follow action-verb conventions reasonably well (get_, create_, search_, download_, etc.), most parameter descriptions are minimal or missing entirely. Input schemas are present but largely incomplete, most lack detailed type information beyond basic strings. Output schemas are not documented anywhere in the source. Error handling is absent; there are no recovery guides or actionable error messages. The server includes a SceneRefinementAgent class that generates suggestions, but this is not integrated into tool outputs or descriptions. Overall, the definitions would not survive code review by a principal tool engineer and fall well below production-grade baselines (which require 80+ for A-grade tooling).
Create a 3D generation job using Hyper3D (Rodin API) from a prompt or image
Download an asset from Poly Haven and import it into Blender
Download a 3D model from Sketchfab and import it into Blender
Execute Python code in Blender's context. The code will be executed in Blender's main thread with full access to the bpy module
Check if Hyper3D (Rodin) integration is enabled and available
Get detailed information about a specific object in the Blender scene
Get available asset categories from Poly Haven
No input schema defined for 7 read-only status/info tools (get_scene_info, get_viewport_screenshot, get_polyhaven_status, get_hyper3d_status, get_sketchfab_status, get_polyhaven_categories, and all 'get_*_status' variants). These tools take empty input {} but provide no documentation of output structure, field types, or return values. LLMs cannot plan downstream tool calls without knowing what fields are returned.
Parameter descriptions are generic or missing specificity. 'object_name' (get_object_info) lacks detail on how to discover valid names or what fields are returned. 'code' (execute_code) says 'Python code to execute' but does not warn about isolation level, available modules, or error recovery. 'prompt' (create_rodin_job) and 'image_path' do not specify format constraints or size limits.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 43 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 13 | - | v1 |
Check if Poly Haven integration is enabled and available
Get information about the current Blender scene including name, object count, materials count, and details about up to 10 objects
Check if Sketchfab integration is enabled and available
Capture a screenshot of the Blender viewport
Import a generated asset from a completed Rodin job into Blender
Check the status of a Rodin 3D generation job
Search for assets on Poly Haven by query and category
Search for 3D models on Sketchfab
Apply a downloaded texture to an object in Blender
No output schema documentation anywhere in the source. Tools return JSON but LLMs have no specification of field names, types, or structure. E.g. get_scene_info returns 'details about up to 10 objects' but the actual JSON structure is invisible, forcing LLMs to guess and potentially fail downstream calls expecting specific fields.
execute_code tool is extremely high-risk (DESTRUCTIVE) but has no error handling, no dry-run option, no confirmation step, and no guidance on recovery. Agents could accidentally corrupt Blender scenes with no way to undo. Tool description does not mention side effects, isolation, or which bpy modules are safe.
No error handling, error codes, or recovery guidance in any tool. If search_polyhaven_assets fails (API down, no results, auth failure), there is no structured error response telling the LLM what to do next. Raw exceptions would break the agent flow.
Status check tools (get_polyhaven_status, get_hyper3d_status, get_sketchfab_status) are unclear about what 'enabled and available' means. Does it test API connectivity? Auth validity? Returns empty input schema with no output documentation, LLM cannot reason about what to do with the result.
Multi-step operations like 'create_rodin_job' → 'poll_rodin_job_status' → 'import_generated_asset' lack documented job_id format and lifecycle. Response from create_rodin_job should guarantee it returns a job_id that poll_rodin_job_status accepts, but output schema is missing, forcing LLM to assume or extract from unstructured text.