MCP for Blender

The server holds no identity of its own and never authenticates who is calling. Its main tool runs arbitrary Python inside the user's Blender process, which has the full authority of the logged-in operating-system user: every file in the home directory, the network, and the third-party API keys stored in the addon preferences. Nothing narrows that authority by default, and the Blender addon accepts commands from any local process on its loopback port. A hijacked session therefore acts as the user on the whole machine.

As a tool server, the project leaves approval to the MCP host and gives the host little to work with. Four read-only tools carry a read-only hint, but the tools that change state, including the arbitrary-code tool, carry no risk annotation, so hosts fall back to the protocol's generic default. The code tool mixes reads and writes in one call, and there is no preview, dry run, read-only mode or server-side confirmation. Code that runs can delete files, overwrite saved work or call paid generation APIs, none of which Blender's undo reverses.

The primary tool takes an arbitrary Python string and runs it, so there is no argument scoping on the path that matters most. The narrower tools do validate inputs: result limits and wait times are clamped, generation quality is an enum, and downloaded archives are checked for path traversal before extraction. The image argument to 3D generation accepts any local file path and uploads that file to the chosen provider. Every tool, including code execution, is enabled by default.

Model-written Python runs in-process inside Blender through exec(), with no sandbox, separate user or container. An opt-in safe mode, turned on with an environment variable, checks scripts against an allowlist of syntax, modules and Blender paths before they are sent; its own documentation describes it as a guard on what the model can be talked into, not a sandbox, and it covers only the MCP path. Even with safe mode on, a script that escapes it lands in the same process with the user's full authority. The criterion takes the opt-in safe mode's score, capped because it is off by default.

Untrusted text reaches the model from asset-library search results (third-party model names and author names), from object and material names in whatever .blend file is open, and from viewport images. The server returns this as plain text alongside its own guidance, with no provenance or untrusted marking, and offers no read-only or no-egress mode. Because the same session can run arbitrary Python, a successful injection can read private files and keys, send them anywhere and make irreversible changes, unless the host's approval stops it.

The server keeps no memory store, but its code tool can write state that runs again later: Blender handlers, timers, registered scripts, the startup file and installed addons are all reachable when safe mode is off. Integration switches (asset libraries, 3D generators) and some endpoint and key settings are read from properties of the currently open scene, which Blender saves inside .blend files, so opening a file can turn integrations on without a separate trust prompt. Nothing records or reviews these persistent changes.

The server has no plugin system. The third-party content it loads at runtime is downloaded assets: Poly Haven models are appended from .blend files, checked against the md5 the Poly Haven API publishes, while Sketchfab, Poly Pizza and generator results are mesh formats. Integrations are off by default but can be switched on by the settings stored in an opened scene, and appended .blend data runs inside the Blender process; whether embedded scripts in it run depends on Blender's own auto-run setting. Separately, the addon checks the project's main branch for updates and installs them on a user click without signature verification.

Third-party keys for Sketchfab, Hyper3D, Poly Pizza, Tencent Hunyuan3D and the Premium licence are read from addon preferences, scene properties or environment variables; preferences and scene properties are stored in Blender's own files, and scene-level keys travel inside saved .blend files. Most key fields are masked in the UI, but nothing keeps them away from the model, which can read them with one line of Python. The server logs every command with its full parameters at INFO level. Anonymous usage telemetry (tool name, success, duration) is on by default, while prompts, code and screenshots are sent only after an explicit opt-in.

The only default record is the server's standard-error log, which prints each command sent to Blender with its full parameters (including the code) and the response status, with timestamps. It is unstructured, written wherever the MCP host captures server logs, and reachable by the code the model runs. The richer trajectory recording is opt-in and uploads to the project's hosted database rather than keeping a local audit trail. Commands sent to the addon socket by other local processes are not logged by the server.

The server waits at most 180 seconds for any Blender command and clamps several arguments, such as search limits and generation wait times. These are limits on waiting, not on work: the addon runs scripts on Blender's main thread with no timeout, so a long or looping script keeps running after the server gives up, and there is no cancel. There is no rate limit or spend cap on paid 3D generation calls.