Loading video player...
Join this channel to get access to perks: https://www.youtube.com/channel/UCGPoHTVjMN77wcGknXPHl1Q/join The system has three actors: an MCP client (the desktop app you chat in), an MCP server (a separate helper process), and Blender (running with an add-on installed). You speak naturally to the client, which provides the language model with a fixed catalog of available “tools” (actions) that the server offers. The model decides whether your request can be satisfied using those tools; if yes it chooses a tool and produces structured arguments, and if not it either asks for clarification or explains that it can’t be done with the available capabilities. Once a tool is selected, the MCP client sends a structured tool-invocation message to the MCP server over standard input/output (stdio). The MCP server’s job is to receive these tool calls, validate/parse the arguments, and translate them into a simpler internal command format that Blender understands. In this project, Blender is not controlled directly by the MCP client; instead, the MCP server acts as a bridge and forwards each requested action to Blender over a local network connection. Inside Blender, the add-on runs a small local service that listens for incoming commands. When it receives a command, it routes it to the appropriate Blender operation (create objects, move them, assign materials, render, export, undo/redo, etc.), executes it within Blender’s Python runtime, and produces a structured result or an error message. That response travels back along the same path in reverse: Blender → local connection → MCP server → stdio → MCP client, which then displays the result to you and/or feeds it back into the model so it can decide the next step. https://github.com/djeada/blender-mcp-server