BlenderMCP has 16 tools with basic naming and descriptions, but critical gaps undermine quality. Tool names follow verb_noun convention (get_scene_info, create_object, delete_object), which is good. However, descriptions are generic and lack actionable context. Most critically: (1) Parameters lack type constraints and detailed descriptions, e.g., 'object_type' accepts free-form strings instead of an enum of valid Blender types; 'properties' is an untyped object with no guidance on valid keys. (2) No output schemas documented, callers don't know what fields to expect. (3) execute_code is a dangerous catch-all that bypasses all safety patterns. (4) Error handling is absent, no guidance on recovery, retryability, or what went wrong. (5) Tool descriptions average ~60 chars, below the 194-char baseline for A+ tools, and lack WHEN/WHY context. The server is functional but would not pass production code review.

• Add output schemas to all tools. Document the structure of returned objects (e.g., get_scene_info returns {objects: [{name, type, location}], frame_count, fps}).
• Convert 'object_type' parameter to an enum: ['MESH', 'EMPTY', 'LIGHT', 'CAMERA', 'SPEAKER', 'ARMATURE']. Add similar enums for material properties and texture types.
• Expand parameter descriptions to 50 - 150 chars each. Include format hints: 'location: array of 3 floats [x, y, z] in Blender units'.
• Remove or heavily restrict execute_code. If arbitrary code execution is needed, require explicit user confirmation and log all invocations for audit.
• Add error handling: return structured errors with category (NOT_FOUND, INVALID_PARAM, TIMEOUT) and recovery hints (e.g., 'Object not found. Call get_scene_info() to list available objects.').

Inferred effective spec: <=2025-11-25.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry