blender-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| BLENDER_MCP_EXECUTABLE | No | Path to the Blender executable. If not set, the server searches PATH and standard installation folders for the newest version. | |
| BLENDER_MCP_LLM_API_KEY | No | API key for the multimodal LLM agent used by the local web UI. Supports OpenAI-compatible or Anthropic endpoints. | |
| BLENDER_MCP_LLM_PROVIDER | No | LLM provider for the agent. Use 'openai' (default) or 'anthropic'. Only used when BLENDER_MCP_LLM_API_KEY is set. |
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": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| blender_statusC | Report the Blender install, output folder, live-bridge state, templates and materials. |
| list_referencesA | List reference guide images under output/refs (optionally one group folder). |
| view_referenceB | Look at a reference/guide image so you can match it while modeling. Args: path: Path relative to output/refs, or absolute. |
| add_referenceA | Copy an image file into the reference library under output/refs. Args: source_path: Existing image on disk (absolute or under the output folder). name: Optional destination filename. group: Optional subfolder name for organising guides. |
| create_blendA | Create a new .blend file from a starter template and save it. Args: path: Destination, relative to the output folder unless absolute. A ".blend" suffix is added when missing. template: empty, default, studio, or product. script: Optional extra bpy code run after the template. compress: Write a compressed .blend. |
| run_scriptA | Run Python against Blender's bpy API.
Args: code: The Python to execute. blend_file: Open this .blend first. Supplying it forces a headless run. save_as: Save the file here when the script finishes. target: "auto", "live" or "headless". |
| apply_materialA | Apply a procedural material preset (metal, plastic, rubber, glass, wood) to a mesh. Args: object_name: Mesh object name in the scene. preset: One of the presets from blender_status.materials. color: Optional RGB or RGBA floats 0-1. blend_file: Open this file first (forces headless). save_as: Save after applying. target: "auto", "live" or "headless". |
| inspect_blendA | Describe a scene: objects, transforms, materials, cameras, lights and render settings. Args: blend_file: Inspect this file. Leave empty to inspect the live session instead. include_objects: Include the per-object breakdown, not just the counts. target: Where to look when no file is given. |
| renderA | Render a still image and write it to disk. Prefer render_and_view so you see it. Args: output: PNG destination, relative to the output folder unless absolute. blend_file: Render this file rather than the live session. Forces a headless run. engine: "EEVEE", "CYCLES" or "WORKBENCH". EEVEE for iteration; CYCLES for finals. samples: Sample count. Keep it low for previews. width: Output width in pixels. height: Output height in pixels. frame: Frame to render. Defaults to the scene's current frame. transparent: Render the world background as alpha. target: "auto", "live" or "headless". |
| render_and_viewC | Render a still and return the image so you must look at it. Args: output: PNG destination under the output folder. blend_file: Optional .blend to open first. engine: Prefer EEVEE while iterating. samples: Sample count. width: Width in pixels. height: Height in pixels. target: "auto", "live" or "headless". |
| preview_viewsB | Render multi-angle EEVEE previews (front, three_quarter, side, top) for critique. Args: blend_file: .blend to open and preview. output_dir: Folder under output/ for the PNGs. width: Preview width. height: Preview height. samples: Low sample count for speed. engine: Prefer EEVEE. target: Usually headless. |
| view_previewB | Look at one preview PNG from preview_views or a render. Args: path: Image path relative to output or absolute. |
| viewport_screenshotB | Capture the live Blender window's 3D viewport as it currently looks. Requires the MCP Bridge addon to be running in an open Blender session. |
| view_imageC | Load a rendered image so it can actually be looked at. Args: path: Image path, relative to the output folder unless absolute. |
| list_outputsC | List the files produced so far in the output folder. |
| open_in_live_sessionB | Load a .blend into the Blender window the user has open, so they can see it. |
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 16 tools
Each tool targets a distinct action: status, references (list/view/add), file creation, scripting, material application, scene inspection, rendering (with variants for preview and view), screenshot, output listing, and live session opening. Even similar tools like render and render_and_view are clearly differentiated by purpose and parameters.
All tool names use snake_case with a verb_noun pattern (e.g., list_references, create_blend, apply_material). The naming is predictable and follows a consistent structure, making it easy for an agent to infer functionality from the name.
With 16 tools, the set covers a broad range of Blender operations—file management, references, materials, rendering, scripting, and inspection—without being overwhelming. The count is well-scoped for its domain: enough to handle common tasks without unnecessary duplication.
The tool surface covers many essential tasks but lacks direct tools for object creation (e.g., adding primitives), transformation (move/rotate/scale), or animation. While run_script can fill these gaps via Python, the explicit tool set leaves notable gaps for a modeling server, forcing agents to fall back to scripting for basic operations.