blender-meta-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| BLENDER_BIN | No | Path to the Blender executable used for install:addon and test:smoke. | auto-discovered |
| BLENDER_MCP_PORT | No | Port the addon listens on (overrides addon preferences). | 11588 |
| BLENDER_MCP_BRIDGE | No | Address the MCP server uses to connect to the Blender addon. | http://127.0.0.1:11588 |
| BLENDER_MCP_AUTOSTART | No | Set to '0' to disable auto-listening after the addon is enabled. | 1 |
| BLENDER_MCP_TIMEOUT_S | No | Seconds the main thread waits for tasks. | 120 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| blender_healthA | Check whether the Blender addon bridge is reachable. Returns Blender version, file, and scene. |
| blender_execA | Execute Python inside the running Blender (bpy), like ae_exec / cocosmcp_exec.
The snippet runs on Blender's main thread with a VIEW_3D temp_override when one exists.
bpy and mathutils are already in scope. The value of the last expression is returned as JSON
(Vector/Euler/Color/Matrix become lists; bpy data-blocks become {type, name}).
Assign |
| blender_scene_infoA | Summarize the open Blender file: scene, mode, collections, and up to 200 objects. |
| blender_viewportA | Capture the current 3D viewport as a PNG (OpenGL, longest edge capped). Does not run a full render. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 4 tools
Each tool has a clear primary purpose: health checking, viewport capture, Python execution, and scene summary. Some minor overlap exists between health and scene_info since both report the current scene name, but descriptions make the distinction clear.
All tools use snake_case with the blender_ prefix, which creates a clear family. Naming blends nouns (blender_health, blender_viewport, blender_scene_info) with a verb (blender_exec), but the pattern remains predictable and readable.
Four tools is a reasonable size for a Blender bridge server. It is slightly lean, but the presence of blender_exec as a general-purpose escape hatch means the small count does not feel restrictive.
The tool surface is essentially complete because blender_exec allows arbitrary bpy Python execution, covering any missing operation. The dedicated health, viewport, and scene_info tools handle the most common inspection and interaction workflows without dead ends.