Blender MCP: Export 3MF and Automate 3D Prints via AI

Watch (21:25)

Overview

Wiring Blender's MCP server and 3MF export into Claude Code or Codex so AI agents can drive a full 3D print workflow end-to-end.

Full transcript (from the video)

This week the Blender Foundation and Anthropic announced an official Blender connector for Claude built on the same open protocol that Claude code and the new Codex agent already speak. That announcement matters less for the technology which has been quietly working in the community for almost a year and more for what it signals. Blender is now an official partner in the agentic AI story. Until very recently when people thought about 3D printing and AI, they thought about parametric CAD tools like CAD query. Blender was the artistic outlier.

Today I want to argue that Blender driven by an MCP server has become a serious tool for printable parts, especially when the part is organic, decorative, or hard to express as code. And the surprise at the end is that Bamboo Lab printers have grown their own MCP servers and the two halves now snap together. Before we go further, it is worth getting MCP itself out of the way because the magic of this video is not in the protocol. The model context protocol is a fairly thin specification from Anthropic that defines how a tool server announces itself, what tools and resources it exposes, and how an AI client invokes them. Think of it as a USB-C plug for AI tools.

A Blender MCP server, once written, can be plugged into Claude code, into the new Codex agent, into Cursor, into Claude, into anything that speaks the protocol. That portability is why this approach scaled so quickly. You do not have to pick which AI tool to bet on. You install Blender MCP once and every agent on your machine can drive Blender. The agents themselves are the magic.

The protocol just gets out of the way. There are two Blender MCP servers worth knowing about. The first is the one that started it all, an open-source community server hosted on GitHub under the project name Blender MCP by an author whose handle is Ahuja Seed. It is widely starred, has an active release cadence, and is the one almost every blog post and tutorial points at. It is the one I will use for the rest of this video because it is the one you can install and run in 5 minutes today.

The second is the official Blender connector that the Blender Foundation announced jointly with Anthropic this week. It is built by Blender's own developers, and it promises a tighter integration with Blender's internals than a third-party add-on can manage. For now, treat the official one as the future and the community one as the present. Both speak MCP, so either way the rest of the workflow is the same. The first time you read the source for the community Blender MCP server, the surprise is how few tools it actually exposes.

There is no create cube tool, no add modifier tool, no export to STL tool. There are about 20 tools in total, and most of them are about reading the scene or about pulling assets from external sites. The reading tools are interesting on their own because get scene info, get object info, and get viewport screenshot give the model a two-way to look at what it is doing. The asset tools are almost a separate workflow because they let the agent pull free models from Poly Haven and Sketchfab or generate fresh ones from text using the Hyper 3D Rodin and Hunyuan 3D generators. But, the tool that does almost all of the actual work is the one I want to talk about next, and it is the simplest of them all, the single most important tool in the Blender MCP server is the one called execute Blender code.

It takes a string of Python and runs it inside the Blender process. Why does that one tool dominate? Because Blender already has a complete Python API called BPA, that gives the model access to all of Blender's menus, operators, modifiers, and object properties. If you can do it with the mouse, you can do it with BPI. So, instead of the server author trying to wrap thousands of operators as individual MCP tools, they made one tool that runs any operator the model wants.

That design choice is why this whole server is so small, and it is also why it stays so flexible. When a new Blender feature ships, the agent can use it the same day with no server update. The trade-off is safety. The model is running real Python inside your Blender session with all the power that implies. A reasonable question at this point is, why bother with Blender at all if I already have CAD query for parts?

The answer is that Blender and CAD query cover different halves of the 3D printing landscape. CAD query wins for anything mechanical or dimensioned, anything with whole patterns, mating features, or parts that need to fit hardware. Blender wins for anything organic, anything sculpted, anything decor anything where, frankly, you just want it to look right rather than measure right. Blender also carries texture, color, and material data alongside, so when you finally export, that information can travel with the model. And because Blender has a viewport, the agent can take a screenshot, look at its own work, and notice that the dragon's wing is poking through the body.

A parametric tool cannot give you that visual feedback loop. Before we glue Blender to a 3D printer, we need to talk about the file format that makes the gluing worth doing. Almost everyone in this audience has shipped a part as an STL file. STL is famously simple. It is a list of triangles, full stop.

It has no units, no color information, no metadata, no concept of multiple objects on a plate. The slicer has to guess all of that, and it usually guesses right, but sometimes it does not, and your part comes out the wrong size. The 3MF format, which Microsoft pushed forward and Bambu Lab and Prusa now use as their native project format, fixes all of that. It is a zipped XML container that carries units, color, materials, multiple objects, and even slicer settings. Once the agent has produced an export in 3MF format, the slicer does not need to guess at any of those things.

There is one piece of friction in the Blender 3D printing story, and it is worth being upfront about it. Blender does not export 3MF out of the box. Even in the most recent long-term support release, you have to install a small add-on first. The maintained one is called 3MF IO, and it lives on the official Blender extension site. You install it the same way you install any extension through Blender's extensions panel inside preferences.

Once it is in, 3MF shows up alongside STL and OBJ in the file export menu, and the operator becomes available through BFA. The agent can then call it like any other Blender operator. This is also a place where the official Blender connector might one day make life easier by shipping 3MF support natively. For now, install the add-on once and forget about it. Once the 3MF IO add-on is installed, the agent emits a single line of Python through execute Blender code, and the model is on disk in a format the slicer will love.

The call is the 3MF export operator on the BFY module, taking a file path argument and a flag for whether to export the whole scene or just the selection. By default, I leave selection off, so the agent gets the entire build plate. This one line is the line that saves your print because it preserves units. An STL export loses while a 3MF export keeps them. That is the difference between a part that comes out the right size on the first try and a part that arrives 10 times too small because somebody picked millimeters in Blender and somebody else picked inches in the slicer.

After the export, the agent reads the file size to confirm the bytes hit disk and moves on. Wiring Blender MCP into Cloud Code is refreshingly simple and takes only a single command. From any project directory, you run Cloud MCP add Blender, followed by the UV runner and the Blender MCP package name, and Cloud Code records that server in its configuration file. The UV runner is part of the UV project, which is the modern Python package runner, and what it does here is fetch the Blender MCP package on demand and run it without you having to maintain a virtual environment for it. After that one command, every Cloud Code session in that project can see the Blender tools listed alongside the file system tools and the bash tools.

You can confirm everything is wired correctly by running Cloud MCP list, which prints every registered server. The same registration also works in your home directory. If you want Blender available across all your projects, there is no separate authentication step. The Blender server only talks to your local Blender, so there is nothing to authorize. The same Blender server works for the new Codex agent, which added MCP support recently.

The command is almost identical. You run Codex MCP add Blender, then a separator made of two dashes, then the UV runner and the Blender MCP package name, and Codex writes the entry into its configuration file at home.codex/config.toml. If you prefer to edit the file by hand, the section is named mcp_servers.blender with a command of the UV runner and an args array containing the Blender MCP package name. The reason this matters is not that Codex is better than Claude Code or vice versa, but that you can use both depending on the day, the task, or the model you trust most for a given job. Both will drive the same Blender session over the same socket, and both will see the same tool list.

The protocol layer makes the choice of agent almost free. Now, I want to save the audience an evening of debugging by listing the four mistakes that bite almost everyone the first time they set this up. Mistake one, Blender has to be running before you start the agent. And inside Blender, you have to open the Blender MCP sidebar and click connect to Claude. Without that click, the server has nothing to talk to.

Mistake two, only one MCP client can hold the connection at a time. If you have Claude Desktop and Cursor both wired up, they will fight over the socket, and you will get strange disconnects. Pick one. Mistake three, the default port the server listens on can be taken by another tool, especially on a busy dev machine. The readme explains how to override it.

Mistake four, mostly on Windows, the UV runner sometimes is not on your path after install and you have to add it manually and restart your terminal. Let me walk through what an actual session looks like end-to-end, so the workflow stops being abstract. You open a code code session with Blender already running and the MCP add-on connected. You build me a desk clamp organizer that holds two pens and my phone, around the size of a small paperback. The agent calls get scene info, sees an empty scene, and starts writing Python.

It uses execute Blender code to add a base block, sketch out a pen slot, mirror it, and rough in a phone slot. It calls get viewport screenshot, looks at the result, and notices the phone slot is too tight for any phone with a case. It edits the script, widens the slot, screenshots again. When everything looks right, it calls execute Blender code one more time with the 3MF export operator and hands you a file path from your prompt to a printable 3MF, 10 minutes. The single biggest reason Blender MCP feels different from any earlier scriptable CAD tool is the viewport screenshot.

The tool called get viewport screenshot returns a PNG of what Blender is currently rendering and it hands that PNG straight back to the model. The model can then look at it the way a human modeler looks at the screen and decide whether the part is right. That single feedback loop is what closes the gap between writing code blind and modeling visually. The agent can build a part, screenshot it, notice that two cylinders are intersecting in a way that breaks the mesh, fix the cylinders, and screenshot again. It can spot scale problems that no script alone would catch.

It can compare its output to a reference image you provide. This is the loop that turns a scripting interface into a real modeling assistant, and it is why mesh modeling under MCP feels different from mesh modeling under any older API. I want to be honest about the failure modes, too, because they will save you frustration. The first failure mode is mesh booleans. When the agent builds two shapes and union them, the boolean operation often produces non-manifold edges that the slicer rejects.

The script ran, no Python error was thrown, but the slicer says this is not a closed solid. The agent rarely catches this on its own. You learn to ask, "After every boolean, please check the mesh for non-manifold edges." And the agent will run a small BFE snippet to verify. The second failure mode is modifier stacks. When the agent edits a model that has multiple modifiers, it sometimes leaves the stack in a weird state.

The third failure mode is mechanical parts. If you need a hole sized for a small machine screw, do not ask Blender to do it. Ask CAD Query. Pick the right tool for the part. Now we get to the Bamboo Lab part of the story, and the first thing to know is that Bamboo Studio is already a 3MF native slicer.

Most slicers treat 3MF as just another import format alongside Bamboo Studio treats it as its native project format. When you save a project in Bamboo Studio, you get a 3MF file. That file carries the plates you set up, the filament you assign to each object, the supports you configured, and the slicer settings you chose, all packed into one zip. So when Blender exports a 3MF and you drag it into Bambu Studio, you are handing the slicer a file in the format it most wants to read. Most Bambu owners already see 3MF in their daily workflow.

They just did not notice it because Bambu Studio quietly uses it as its save format. There is a small Bambu Lab companion app that almost no one talks about called Bambu Connect. It is still in beta and it is the missing piece for a fast workflow. Bambu Connect is not a slicer. It does not have the heavy modeling UI.

What it does is sit on your machine and accept a sliced 3MF or a G-code file and send it straight to your printer. It can run in cloud mode where it talks to the Bambu cloud or in LAN mode where it talks directly to the printer on your local network. The flow people who care about speed actually use is model in Blender, slice in Bambu Studio once to capture your settings. Then, for every iteration after that, drop the sliced 3MF onto Bambu Connect and click send. That removes most of the slicer UI from the loop.

The Bambu side of the workflow has grown its own MCP servers and there are three worth knowing about. The first one is the Bambu printer MCP project published on NPM. It has an explicit bridge into Blender MCP and it ships tools to auto slice with the Bambu Studio command line, upload a 3MF over the printer's file protocol, and start a print over its message queue. The second project is the most actively developed of the three. It exposes around two dozen tools including camera frames and AMS material mapping.

The third project is It is a remote MCP server backed by the Bambu cloud so it does not need developer mode on your printer. The repo names are listed on screen, so check the slide rather than trying to catch them in audio. Between them, an agent can slice, send, monitor, and cancel a job without ever opening Bamboo Studio. Now, to the question that started this whole video, is there a quicker path that someone found where Bamboo and Blender meet through MCP? Yes, and it works in one clawed code session with both servers registered.

The agent designs the part in Blender using execute Blender code, and then exports a 3MF using the 3MF IO operator. The same agent then hands that file to the Bamboo printer's print tool, which auto slices the file with the Bamboo Studio command line in the background, uploads the sliced result to the printer over its file protocol, and starts the job over the printer's message queue. From your typed prompt to a printer pulling filament, no human ever opens a slicer UI. That is the quicker path. It is fragile right now because every server in the chain is young, but the path is real.

If you peek under the hood of any Bamboo MCP server, you will almost certainly find the same Python library doing the actual work. It is called Bambu Labs API, and it is on the Python Package Index. It is the Python primitive that handles the printer's message queue, its file upload protocol, its AMS slot mapping for multi-color print, its camera feed, and its status polling. It is the layer that turned the somewhat ad hoc reverse engineering work of the early Bamboo hacker community into a real library. If you want to integrate Bamboo printers into anything custom, your own dashboard, your own MCP server, your own farm controller, this is where to start.

The MCP servers I just walked through are essentially thin wrappers around Bambu Labs API that speak MCP at the top and printer protocols at the bottom. Almost everything else is convenience. If you want to actually try this workflow this weekend, here's the order I would do it in because the dependencies bite if you do them out of order. Step one, on the printer itself, enable developer mode in the LAN settings and write down the access code. Without those two steps, no third-party tool will be allowed to talk to the printer over your network.

Step two, install Blender, then install the 3MF IO extension from the Blender extension site, then install the Blender MCP add-on by downloading its Python file and installing it through preferences. Open the Blender MCP panel and click connect. Step three, install UV, the modern Python package runner, and then run cloud MCP add blender with the UV runner and the Blender MCP package name or the equivalent command in your other agent. Step four, install your Bambu MCP of choice, configure it with the printer's address and access code, and you are ready to go. If you remember nothing else from this video, carry these five ideas forward.

First, MCP is the connective layer, not the magic itself. It is just a clean protocol, but its arrival has made cheap to wire any agent to any tool, and Blender is now officially part of that story. Second, the heart of the Blender workflow is two tools: execute Blender code and get viewport screenshot. Together, they let an agent build, look, fix, and look again. The third idea is that 3MF is the format that finally tells the slicer what STL was always hiding: Units, color, materials, and structure.

Fourth, Bambu Studio is already a 3MF native slicer and Bambu printers now have their own MCP servers. And fifth, with two MCP servers loaded into one cloud code session, you can take a