A chat window can describe a Blender workflow. It cannot perform one. Model Context Protocol is the difference between an assistant that explains the recipe and one that stands at the stove.
What I run
- Blender MCP — the agent drives
bpyin a live session: scene inspection, procedural props, batch export, PBR assignment, viewport screenshots it can actually look at and respond to. - Godot MCP — launching projects, creating scenes and nodes, wiring resources, managing UIDs in Godot 4.4+, and reading the error output back into the loop.
- Local research and file servers — the boring ones that matter most, because they let an agent read the notes where a decision was already made instead of inventing a new one.
The rule that makes it usable
Every action must be scoped, reviewable, and reversible. An agent with unbounded authority in a 3D scene is a very fast way to lose a day’s work. So: version control before the loop starts, narrow tool surfaces over general shell access, screenshots and error text fed back as verification, and a hard stop when the task has no clear completion criterion.
Why this matters for creative work
Creative pipelines are full of tasks that are tedious, deterministic, and easy to describe — retopologize this batch, export at these three LODs, rename every material to the convention, rebuild the sprite sheet. That work is not where taste lives, but it eats the hours where taste would have gone.
MCP moves the boundary. The agent handles the deterministic middle of the pipeline; I keep the ends — what we’re making, and whether it’s any good.
Related stacks
Blender (bpy, geometry nodes), Godot 4 (GDScript), Three.js and TouchDesigner for realtime output, and Cloudflare Workers for anything that ships to the web.