Loading ToolBench
Extended Blender integration via MCP with support for blueprinting, sculpting, procedural modeling, optimization, rendering, baking, material presets, and texture generation
This Blender MCP server has significant quality gaps across naming, descriptions, schemas, and error handling. While all 7 tools are properly registered with basic schemas, most descriptions are too short (10-30 chars, vs. baseline 194), parameters lack validation constraints, and error handling is absent. The server targets Blender, a domain requiring precise technical communication, but tool definitions read as abbreviated rather than LLM-optimized. No evidence of output schemas, error recovery guidance, or parameter relationship documentation.
Apply a texture image to an object from a file path or URL.
Bake texture maps for an object to image files.
Create a 3D model from a blueprint template with optional style modifiers and custom components.
Reduce polygon count of a mesh using the Decimate modifier.
Apply a PBR material preset to an object.
Descriptions are critically short (10-35 chars) vs. baseline 194 chars. LLMs cannot determine when/why to select tools without context.
No output/return schemas documented for any tool. LLMs cannot infer what fields to expect, breaking downstream tool chaining and response parsing.
No error handling or recovery guidance. Tools can fail silently or with generic Blender errors that LLMs cannot act upon. E.g., 'No mesh found' should return 'Object X not found. Try list_objects() to find available objects.'
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 8 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 43 | - | v1 |
Parameters lack enum constraints and validation guidance. E.g., 'bake_types' accepts free-form comma-separated string instead of enum [COMBINED, DIFFUSE, NORMAL, AO, ROUGHNESS, METALLIC, EMIT, SHADOW]. LLMs will hallucinate invalid values.
Parameter descriptions lack format/range specs. E.g., 'resolution' has no min/max (1024 is example, not constraint). 'tile_x' and 'tile_y' should specify valid range (0.1-10.0?). Missing constraints invite absurd LLM inputs.
Tool descriptions do not explain WHEN to use them vs. similar tools. E.g., 'apply_texture_from_file' vs. 'set_material_preset', which should LLM choose? Descriptions must clarify: textures for surface detail, presets for quick PBR setup.
sculpt_mesh parameter 'operation' is free-form natural language ('add horns', 'smooth'). No enum, no validation, no guidance on supported operations. LLMs will attempt arbitrary sculptural requests that fail.
No indication of tool side effects or idempotency. Which tools modify Blender scene state? Which are read-only? Agents need explicit risk markers (WRITE vs. REVERSIBLE vs. READ). bake_textures writes files; render_scene also writes, but descriptions don't clarify.
apply_texture_from_file accepts URLs but no validation guidance on supported formats, size limits, timeout. LLMs could pass enormous or malformed URLs.
Missing tool that lists available objects/presets/bake_types. LLMs cannot discover what objects exist in the scene before calling bake_textures or apply_texture_from_file. Agents will guess and fail.