mcp-for-blender-pro: a chat workspace and MCP server inside Blender

A companion Studio window next to the viewport

mcp-for-blender-pro is described as an AI assistant for Blender that can inspect a scene, build objects, edit materials, find assets and carry out multi-step workflows, with a visual chat workspace and a built-in Model Context Protocol server. The repository description adds that it works with OpenAI, ChatGPT, Claude, Gemini, Ollama and OpenCode.

The layout of the tool matters more than usual here. There are two ways to work with it. You can send a message inside Blender itself through a panel in the 3D Viewport, or you can open a separate Studio window that the documentation describes as holding chat, scene objects, viewport snapshots, approvals and a task board. The Studio view is the one that shows what the assistant is doing while it does it, which is what makes an assistant that edits your scene tolerable to work with.

The stated workflow is to start from a brief, ask the assistant to inspect the scene, create a layout, arrange objects, assign materials or prepare an export, then follow its actions in the conversation and check the result in the viewport preview. The documentation is explicit that you keep working in Blender throughout, which is a design statement about where the model sits: inside the tool you already use, not in a separate application that drives it.

The audience named in the project description is artists who want faster iteration, technical artists automating repetitive work, and developers connecting AI tools to Blender.

Installing the extension from a ZIP

The install is a five step sequence with no command line involved, which fits how Blender extensions are normally distributed.

First, download the file named mcp-for-blender-pro.zip from the releases page. Then in Blender open Edit, Preferences, Get Extensions, then the menu, and choose Install from Disk. Select the ZIP, enable mcp-for-blender-pro, and open 3D Viewport, then N, then MCP Pro. The last two steps are configuration: choose a provider, add your connection details and select a model, then send a message in Blender or open the Studio window.

Two constraints appear in the same paragraph as the steps. The release bundle targets Windows x64 with Blender 4.2 or later, and Blender has to stay open while you use Studio or an external client. The second point is not a limitation so much as a consequence of the design, since the assistant acts on the live scene through the running Blender instance, so there is nothing to connect to once Blender is closed.

The Windows-only bundle is the detail with the most impact on adoption. Nothing in the documentation describes a Linux or macOS build of the release artefact, so on those systems the choice is between building from the repository yourself, whose top level holds blender_manifest.toml, mcp_server.py, orchestration.py, agents.py, providers.py, profiles.py, studio.py and directories for core/, tools/, web/ and docs/, or waiting for a build.

Twenty-one tools, grouped by what they do

The MCP surface is documented as a table of tool groups, and the grouping tells you how much of Blender the assistant can actually reach.

Scene inspection is get_scene_info, list_objects and get_object_info, and the documentation explains why that matters: scene and object inspection gives the assistant context before it acts, which is what stops it from creating a second camera when one already exists.

Object creation covers add_cube, add_sphere, add_cylinder, add_plane, add_light and add_camera. Editing covers move_object, duplicate_object, delete_object, parent_objects and set_material.

Then there is the pair that changes the character of the tool: viewport_screenshot and execute_code. The screenshot tool closes the loop between the model and the scene, and the documentation notes that image-capable models can interpret viewport screenshots. The example prompts reflect that, since one asks to duplicate the selected object into a spaced row of five and show the viewport.

execute_code is the arbitrary scripting escape hatch. The rest is a bounded vocabulary of scene operations, but this one lets the model run Python against the running Blender, which is where bpy-level work beyond the named tools happens.

The remaining groups are bpy_api_lookup and describe_node_type for consulting the Blender API and node types, export_scene for output, and search_assets with import_asset for asset workflows. The asset integrations named are Poly Haven, Sketchfab and Poly Pizza, with service keys to configure and a reminder to follow the licences of the assets you use.

Single assistant, or a manager with workers and reviewers

Two operating modes are offered. Single assistant is the direct, conversational one, used for quick changes. For larger work you configure a team chain with individual responsibilities, instructions and models.

The team roles are defined in the documentation. A manager breaks the request into assignments and acceptance criteria. Workers perform the assigned scene operations. Reviewers inspect results and either approve the work or return specific findings. The example prompt in the project description, find an appropriate Poly Haven asset for this scene and ask before importing it, shows the approval behaviour built into the asset path in particular.

The failure handling is specified tightly, and this is where the design earns its keep. Tasks run sequentially so scene edits stay ordered, which matters because an out-of-order edit in a 3D scene can produce a state nobody can reason about. A blocked task gets one correction attempt, and a second failed review stops the workflow. The task board exposes assignments, attempts and review findings as work progresses, so a human can see not just the current state but the history of what was tried.

Compared with writing the bpy script yourself, the difference is where the decisions live. A hand-written script is deterministic and reviewable line by line, and it fails in one specific way. An agent chain interprets a brief, may choose a different route to the same scene, and can get partway through before a reviewer stops it. That flexibility is the point for an artist sketching a layout, and it is exactly what you do not want in a production asset pipeline.

Cloud models, local models and custom endpoints

The supported connections are OpenAI, Anthropic Claude, Google Gemini, OpenRouter, OpenCode Zen, Ollama and custom APIs. The documentation says to load the available model catalog and select a model directly in Blender or Studio, and that saved connections keep work and personal connections separate, including multiple keys for the same provider.

Custom endpoints support three protocols: OpenAI Chat Completions, Anthropic Messages and Ollama. That list is a useful compatibility check, because a self-hosted model served behind a different interface will not work without a shim. The documentation also advises choosing models with tool-calling support, since a model that cannot call tools cannot drive the scene tools at all, and notes that image-capable models can interpret viewport screenshots, which is the difference between a scene description and a screenshot-aware assistant.

The OpenCode path is a bit different from the others. The documentation says to launch OpenCode Portable from the sidebar, and that OpenCode manages its own provider sign-in and model selection, and that OpenCode-only free models are available through the OpenCode client.

For MCP specifically, other compatible clients can connect to the authenticated local endpoint described in the connection guide, so the built-in Studio is a convenience rather than a requirement. If you already run an external agent client, the connection guide is the document to read.

Approvals exist, and they are not a sandbox

The section on control is short and unusually candid. Built-in chat supports operation approvals, cancellation after the current step, and named undo steps for mutations. So an operation can be paused for a decision, and a long-running sequence can be stopped once the current step finishes rather than being killed mid-write.

Then there is the sentence that matters most for a security-minded reader: Python tool validation helps catch disallowed operations, it is not a security sandbox. Combined with the presence of execute_code, the honest reading is that the validation layer filters accidental or sloppy calls, not a determined model, and certainly not a script. Anyone treating the assistant as safe to point at a production file system has misread the documentation.

Two smaller boundaries are stated nearby. External MCP clients manage their own approval policies, so the safety story differs depending on which client is driving. And connection credentials are stored in your user settings, with chat history lasting for the current session only, which means a restart clears the conversation but leaves the keys in place.

The Studio itself runs locally and authenticates requests to Blender, so the traffic between the assistant and the application does not leave the machine. The model calls do.

A 1.0 release, an MIT licence and an included dependency licence

The project is Python, MIT licensed, with the licence stated in the repository description and a LICENSE file at the top level. The description also notes that OpenCode's licence is included with the distribution, which is the right thing to do when a distribution bundles someone else's code, and it is worth checking the terms of that included licence before you redistribute the bundle.

The repository is not archived and the last push was on 2026-10-20. There is one release in the recent list, mcp-for-blender-pro 1.0.1, published on 2026-10-18, and the README badge refers to release 1.0.0. So this is a project at the very beginning of its public version line, with the documentation, the tool names and the release cadence all likely to change.

The documentation set is short and directed at use rather than internals. There is a quickstart, a connections and agents guide, and a repository with core/, tools/, web/, docs/, an i18n module and a UI module, with the interface available in English, German, French, Spanish and Chinese. The i18n module at the top level of the tree suggests translations are wired into the add-on rather than bolted on afterwards.

One last practical note for anyone planning an evaluation. The documentation tells you to keep Blender open while using Studio or an external client, and the extension is a native Blender extension installed from disk rather than a separate application. That means the thing being evaluated is the behaviour of a model editing your scene, and the sensible test is a throwaway file rather than a project you have invested in.

Editorial conclusion

Adopt mcp-for-blender-pro if you work on Windows with Blender 4.2 or later and want a model that can act on the scene through documented tools with an approval step in front of it. Skip it if you are on Linux or macOS and the release bundle does not cover your platform, if you need hard isolation from arbitrary Python, or if you want a deterministic pipeline rather than a conversation. Verify first that the extension installs from disk and that the provider you intend to use is one of the listed connections, then read the approval and cancellation behaviour before you let it touch a scene you care about.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. LiCinCan/blender-ai-mcp-addon on GitHub
4. README
5. Releases