This page is what happened when we ran it. The project itself — code, maintenance, community — has its own review: full repo review →
Blender
Blender MCP is a community server that connects an MCP client to a running copy of Blender on your desktop. A companion add-on inside Blender listens on a local socket; the server relays requests to it, so an assistant can read the scene graph, create and edit objects, adjust materials, and execute Python inside Blender itself. It ships as blender-mcp and starts through uvx.
How we started it
uvx blender-mcpSkip it on any machine where Blender is not already open in front of you, and treat our run as the warning: it never reached initialize. We started it as an unprivileged probe user with a clean environment and it exited with code 1 during startup, because its settings loader tried to open a .env file it was not allowed to read. That is a sandbox-hostile startup path rather than a broken server, and people with Blender running locally do report it working, but it means the thing cannot be measured, containerized, or run on a shared box without you first making its working directory friendly.
Use it if
Skip it if
The bill for your context window
There is no Context Tax to report here, and that absence is itself the measurement: tools/list never happened, so the payload weighed nothing and the tool count stayed at 0. When it does boot on a desktop, expect a small surface, since the interesting work happens through a generic Python-execution tool rather than dozens of narrow ones. That design keeps the tools list cheap and pushes the real cost into whatever the model chooses to send through it, which no directory can measure in advance for you.
Setup reality
Two halves have to be alive at once: the add-on inside Blender, and the uvx-launched server outside it. Our harness only ever ran the outside half, with a clean environment and no secrets, and that was enough to break it. The traceback ends in a PermissionError on '.env' inside pydantic-settings, raised through python-dotenv while the process was still constructing its settings object. It scraped no environment-variable hints for us, because it died before it could complain about any. Practically, that means the fix is filesystem, not credentials: run it from a directory the process owns, where an absent or readable .env is possible. Then install the add-on, start Blender, and let the socket connect. The README covers the add-on side; nothing in it prepares you for the startup path failing on file permissions.
Questions people ask
Why did the Blender MCP server fail to start in your test?
We booted it as an isolated probe user with a clean environment on 2026-08-19. Its settings loader tried to read a .env file in the working directory, hit a PermissionError, and the process exited with code 1 before initialize completed.
Does Blender MCP need Blender to be running?
Yes. The server is a relay to an add-on that lives inside a running Blender session and listens on a local socket. With Blender closed, connecting the server gets you a client entry that can do nothing.
Can I use it for headless rendering on a server?
Not as designed. It targets an interactive desktop session, and the startup failure we hit is the sort of thing you meet constantly on servers. For batch rendering, drive Blender's own command line instead.
Other creative servers we started
| Server | Vendor | Boots | Context tax |
|---|---|---|---|
| Figma (Framelink) | community | ✗ | ~0 tokens |
How this page is made: the server is spawned as an unprivileged user with a clean environment and no credentials, then asked for its tools, resources and prompts over stdio. Token figures are estimates at four characters per token, not a tokenizer count. One run, one machine. Corrections: contact the desk.