Loading ToolBench
MCP server for Blender automation and 3D modeling operations, providing tools for armature rigging, texture baking, camera configuration, mesh manipulation, material editing, rendering, and scene management.
sBlendyMCP provides 8 tools with complete input schemas and descriptions, but quality is inconsistent. Tool names follow verb_noun convention (blender_bake, blender_camera, etc.), which is good. However, descriptions vary widely in clarity and actionability. blender_bake has a detailed, context-rich description (165 chars) explaining prerequisites and parameter relevance; blender_camera is similarly thorough. But blender_execute_code is terse (95 chars) and lacks guidance on when to use it vs. domain-specific tools. Parameter descriptions are present but often generic ('Object name', 'File path') without format constraints or examples. Output schemas are not documented, callers cannot predict response structure. Error handling is minimal; no recovery guidance or categorization. The server lacks pagination support, result limits, and field-level documentation. Composition is reasonable (each tool has one responsibility), but tools don't chain well, responses don't consistently include IDs needed by downstream tools.
Texture baking operations. 'action' picks SETUP_IMAGE (create + assign a bake target image), EXECUTE (run a bake with a specific type), or the quick bakes NORMAL (tangent-space normal map), AO (ambient occlusion), and DIFFUSE (color map). Provide only the parameters relevant to the chosen action. NOTE: baking requires a bake-capable engine (CYCLES in Blender 5.x — EEVEE does not support baking).
Camera operations. Use 'action' to choose the operation and provide only the relevant parameters. Actions: ADD, SET_ACTIVE, SET_LENS, SET_DOF, SET_ORTHO, SET_PANO, LIST.
Collection management. Use 'action' to choose the operation and provide only the relevant parameters. Actions: CREATE, DELETE, RENAME, ADD_OBJECT, REMOVE_OBJECT, MOVE_OBJECT, SET_VISIBILITY, LIST.
Execute arbitrary Python code in Blender's context. The code has access to 'bpy' and 'mathutils'. Set a 'result' dict variable to return data. Use this for operations not covered by other tools.
Export the scene or selected objects as glTF/GLB, OBJ, or FBX. Pick the output type with 'format' and give a full 'filepath' (the parent folder is created if needed).
Output schemas not documented. Callers cannot predict response structure, forcing LLMs to guess at field names and types. This breaks tool chaining and increases hallucination risk.
Parameter descriptions lack format constraints and validation rules. E.g., 'filepath' has no guidance on absolute vs. relative paths, directory creation, or platform-specific separators. 'resolution' has no min/max bounds.
blender_execute_code is a generic escape hatch with minimal guidance. Description (95 chars) does not explain when to use it vs. domain-specific tools, what 'result' dict structure is expected, or error handling. LLMs may overuse it instead of calling specialized tools.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 57 | 2026-07-28+ | v2 |
Save or open a Blender .blend file. 'action' picks SAVE (current file, optionally to a new path, optionally packing resources) or OPEN (replaces the current scene).
Import a 3D file into Blender. Supports: glTF/GLB, OBJ, FBX, STL, PLY, COLLADA, Alembic, and USD. The format is detected from the file extension unless overridden.
Undo or redo the last operation in Blender. 'action' picks UNDO or REDO. Returns a clean 'Nothing to undo/redo' message when there is nothing to step.
No error handling guidance. Tools return raw Python errors or generic 'not found' messages without recovery hints. E.g., 'Armature not found' does not suggest calling blender_collection LIST to discover available objects.
No pagination or result limits. Tools like blender_collection LIST could return hundreds of items, exhausting context. No documented limit or cursor support.