Loading ToolBench
Local-first MCP server for Blender with provider-agnostic AI backends (OpenAI-compatible, Ollama, LM Studio, llama.cpp) and agent-driven scene control
blender-open-mcp has 13 tools with complete input schemas and descriptions. Naming follows verb_noun convention consistently (blender_get_*, blender_create_*, blender_delete_*, etc.). Descriptions are present for all tools (range 80-200 chars, median ~120 chars) and reasonably clear about intent. However, several significant gaps reduce quality: (1) Output schemas are NOT documented, responses are not formally specified, forcing LLMs to infer structure from tool description alone. (2) No error handling guidance, tools like blender_execute_code and blender_delete_object are destructive but lack recovery instructions or dry-run patterns. (3) Parameter descriptions vary in completeness; some lack format/range constraints (e.g., 'code' param for blender_execute_code has no length limit or security note). (4) No tool annotations (readOnlyHint, destructiveHint, idempotentHint) to signal which tools are safe vs. dangerous. (5) Composition issue: blender_execute_code is a catch-all that bypasses the tool-based API, agents could use it to circumvent other tools entirely, creating unpredictable behavior. (6) Missing pagination/limits on potential list operations. Overall: solid foundation, but lacks production-grade polish around error guidance, output documentation, and safety annotations.
Send a natural-language prompt to the configured LLM backend (OpenAI-compatible, Ollama, LM Studio, llama.cpp, or Azure) with full Blender scene context
Create a primitive mesh object in the Blender scene at the specified location, rotation, and scale
Delete an object from the Blender scene by name
Execute arbitrary Python code in the Blender Python interpreter (bpy module available)
Get the currently active LLM provider configuration (provider, base_url, model, supported providers list)
Get detailed information about a specific Blender object by name (transform, type, materials, geometry stats)
Output schemas NOT documented for any tool. LLMs cannot infer response fields, nesting, or data types. Forces guessing and increases errors on downstream tool chaining.
blender_execute_code is a catch-all that bypasses tool-based abstraction. Accepts arbitrary Python code with no length limit, validation, or injection protection. Violates principle that each tool does one thing. Agents could use this to circumvent other tools entirely.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 69 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Download and import a 3D asset from Poly Haven into the Blender scene by asset ID
Get a full summary of the current Blender scene (all objects, camera, frame range, render settings)
List available models for the current LLM provider (fetched from provider's /models or /api/tags endpoint)
Modify an existing Blender object's transform (location, rotation, scale) or visibility
Render the current Blender scene and save the image to a file path
Configure or switch the active LLM provider (provider, base_url, api_key, model, extra settings)
Assign a material with optional RGBA color to a Blender object using Principled BSDF
Destructive operations (blender_delete_object, blender_execute_code) lack confirmation/dry-run patterns and no recovery guidance. Agents have no way to undo accidental deletions or code execution.
API keys exposed as tool parameters (blender_ai_prompt, blender_set_llm_provider, blender_list_llm_models). Secrets in parameters leak into agent logs and trace histories. Violates security best practice.
blender_execute_code implies state persistence ('variables persist') across requests. MCP spec requires stateless handling, each request should be independent. Violates protocol design.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) to signal safety and retry semantics. LLMs cannot distinguish read-only from destructive operations.
No error handling or recovery guidance. Tools fail silently or with generic messages; no indication of what the LLM should do next (retry, ask user, abort).
Parameter constraints loose or absent. E.g., blender_create_object.location has no documented range (negative coords? > 1000?). blender_execute_code.code has no length limit or validation. Unbounded inputs risk API misuse or timeout.
Tool descriptions sometimes vague or lack dependency hints. E.g., blender_get_polyhaven_asset does not document how to discover valid asset IDs. blender_set_material does not explain Principled BSDF or when material reuse occurs.
Optional override parameters for LLM provider (base_url, model, api_key) in blender_ai_prompt and blender_list_llm_models increase complexity and repeat configuration needlessly. Should be centralized in blender_set_llm_provider.