Blender MCP and the Future of Creative Tools - Siddharth Ahuja

Making a donut sounds like a modest creative goal. In Blender, getting there can first mean learning a substantial interface. Siddharth Ahuja came to the problem through experimentation after running a product studio: he liked what the application could do, but had never mastered its controls.

Blender is a general-purpose 3D application. It can import assets, animate them, create artwork, and export work to a game engine. Those capabilities come with tabs across the top, properties on the right, and more options nested inside them. Ahuja jokes that navigating all those controls had kept him from becoming a good 3D artist.

When he encountered Model Context Protocol, or MCP, its promise of connecting a language model to tools suggested a different entry point. Could the model handle the operations while he described what he wanted?

Ahuja describes a beginner donut course he followed as a five-hour exercise. His frustration was the distance between a simple intention and the knowledge needed to carry it out. The question behind Blender MCP was whether prompting could shorten that distance.

Blender MCP connects a model application, such as Claude or ChatGPT, to Blender so that a prompt can produce scene operations. Ahuja’s opening demonstration asks for a dragon guarding a pot of gold. The user supplies the scene’s intent; the model application works out how to construct it.

Ahuja laughs at the result: it understands the assignment, even if it is hardly exceptional artwork. There is an isometric room, a dragon with wings, and a pot of gold. Ahuja estimates that the dragon scene took about five minutes to make. He thinks the same attempt would have taken him much longer manually.

Getting a recognizable result and producing polished artwork are separate achievements. This dragon demonstrates the first: a description has become an arrangement of objects inside a complex creative application.

At the time of the talk, Ahuja reported approximately 11,500 GitHub stars for Blender MCP. He also reported more than 160,000 downloads. Other people were already using it and building on it, expanding the experiments beyond what he could make himself.

The connection is simpler than the resulting scenes might suggest. A model application communicates with Blender through MCP, which provides a standardized way to expose available capabilities. Ahuja’s sketch puts the application between Blender and external asset services: it can coordinate work inside the local scene and requests to outside APIs.

Tool descriptions tell the model which operations are available. The model selects an operation, and the application invokes it; MCP itself does not choose what to make.

On the Blender side, Ahuja’s add-on executes scripts supplied through the bridge. That is the crucial connection between language and geometry: generated code becomes operations inside Blender. The model application interprets the request, while Blender executes the scene work.

Assets extend the available vocabulary beyond objects constructed directly through scripts. Rodin supplies AI-generated assets, while Sketchfab and Poly Haven provide other asset sources. The model application can coordinate obtaining an object and bringing it into the scene.

Blender makes this practical because it already supports scripting and can download and import assets. The integration can use those existing capabilities instead of reproducing each action as a sequence of clicks through the interface.

For example, a user can describe a zombie and ask for a generated asset that fits the description. The client coordinates that request with the external service and the work inside Blender. This is its role as an orchestrator: the creative request may require several capabilities, but they can contribute to one result.

Ahuja presents the separation between application, model, and creative tool as a source of flexibility. He names Claude, Cursor, Windsurf, and LangChain as possible environments, and points to choices across Claude, ChatGPT, and Gemini for the model side. His design ambition is to let people bring their preferred environment and model to the same creative workflow.

The first implementation lesson is how much work an existing scripting interface removes. Claude’s ability to write code becomes useful for modeling and asset handling because Blender can execute that code. A general execution capability can reach many parts of the application without requiring a separate integration for every manual operation.

But exposing more operations does not automatically make the model more effective. Ahuja reports repeatedly refactoring an integration that had roughly 14 or 15 tools because tool selection became confused. The problem was deciding which capability to use for a request.

His examples show why the choices can overlap:

A request for a simple shape can fit both a dedicated creation tool and general code execution. The model has to choose between routes that may lead to the same visible result.

Ahuja’s response is to keep the interface lean and make each capability clearly distinguishable. Distinct responsibilities make tool selection easier. The useful lesson is to reduce ambiguity between operations, rather than adopt his tool count as a universal limit.

That principle carries into the product experience. An open-source project can attract many feature requests, but adding every possible feature can erode the lean, general-purpose workflow that made it useful.

Meanwhile, the underlying models improve. Ahuja still finds their understanding of 3D limited, but points to Gemini 2.5 as an example of progress he noticed during the project’s development. A broadly useful scripting bridge can benefit from that progress without needing a new dedicated feature for every kind of scene.

Once other people started using the bridge, its possibilities became more concrete. Ahuja begins the showcase with his own scene assembled from newly generated assets, including a magical mushroom. He describes the objects he wants, tells Claude where to place them, and captures the resulting composition.

Ahuja reports making the magical-mushroom scene in two minutes. He emphasizes that the assets were generated for the scene: prompting covers both obtaining the objects and arranging them, rather than only positioning a collection he already had.

A separate cat example adds another operation. Its creator obtains generated assets and then animates them a little, giving the scene a sense of life. Ahuja says the cat workflow can be completed in less than an hour. The result is no longer just a composition to photograph; its objects can move.

The next example changes the input. A creator supplies an image of a living room, and the model uses that reference to guide reconstruction and obtain appropriate assets. Ahuja describes the living-room reconstruction as taking minutes.

A reference image gives the workflow a visual target. Instead of describing every object and spatial relationship in words, the creator can show the arrangement they want the scene to resemble.

Another creator works in Cursor with an image reference to generate terrain in Blender. This reaches into a more specialized part of the application: nodes that configure textures and surface bump or normal detail.

Those node arrangements have their own learning curve. Because Blender can execute code, the model can configure them as part of creating the requested terrain. The scripting bridge reaches beyond placing objects into the machinery that determines how their surfaces look.

Ahuja is particularly delighted by the next game’s unusual premise: the player enters someone’s lungs, collects bone fragments, and reconstructs a rib cage to win. Blender MCP was used to set up the scene and create assets. Its contribution here is the environment and objects that support the game’s peculiar objective.

A further showcase focuses on a glossy, iridescent material and an animated camera. Ahuja says this material and camera animation were produced through prompting in minutes. The request now reaches beyond an object’s shape into its surface appearance and the camera movement used to present it.

The racing example begins with a prompt to create a track and animate cars. The Blender scene contains a circular racetrack, cars, colored obstacles, trees, and stands. The creator then places the camera so the racing action starts to feel like a movie shot. This is a constructed 3D scene whose objects and framing can be directed before the next production step.

The creator also animates the camera, then uses Runway to transform the Blender-derived material into the final displayed clip. Blender establishes the scene and motion; Runway produces the transformed footage.

That division opens the workflow to filmmakers as well as 3D artists. A controllable scene can become an intermediate step in making a shot, even when the Blender render is not the final visual medium. The track, cars, and camera movement supply structure for the subsequent video-generation work.

Ahuja returns to the opening exercise with donuts made from a short prompt. Ahuja estimates about a minute for the prompted donut example. He also acknowledges that the result could be much better.

The contrast with his five-hour beginner course concerns the route to a starting result. Following a tutorial teaches operations; prompting produces something to inspect and refine. They do not establish equal quality or equal skill acquisition, but the prompted example changes what a newcomer can attempt before mastering the interface. A simple idea can now become a visible object that gives the next prompt something concrete to work on.

Ahuja then extends orchestration beyond Blender. If a model application can coordinate a local creative tool and external asset services, it could also coordinate several creative applications.

The organizing principle is creator intent. People come to Unity because they want to make a game, and to Ableton because they want to make music. Learning the software is a means to that outcome. The challenge is to capture what someone wants to create and translate it into work across applications while still matching their vision. Ahuja sees MCP connecting those tools, with the language model interpreting the request and coordinating the work.

In his proposed game workflow, the user describes the game to the model application. The application would coordinate several responsibilities:

• Blender: Create the assets needed for the game.
• Unity: Assemble the game, add collisions, and implement its logic.
• External services: Supply additional assets or animation.
• Ableton: Create music for the characters and game.

This is an envisioned production chain. The creator would direct one project while the application chooses which underlying tool should perform each part.

To demonstrate a smaller version of that idea, Ahuja combines Blender MCP with his companion project, Ableton MCP. The request is to create a dragon and give it a soundtrack. Ableton MCP supplies the connection through which the model application can request music creation, alongside its existing connection to Blender.

The result has two coordinated parts. Blender contains the described dragon, with sinister lighting appropriate to a villain. Ableton creates the soundtrack. The character brief influences both the visual scene and the music, while each application produces its own output.

Ahuja is candid that the quality is still limited. What excites him is the ability to stitch the pieces together: one creative request can guide work that would otherwise require separate operations in two very different interfaces.

These experiments leave Ahuja with a question about interfaces: will more people work primarily through a model application, without learning every complex tool beneath it? He sees new creators entering that way already.

His analogy is an orchestra conductor. The creator needs to articulate the intended result and coordinate its parts, even when they do not personally operate every instrument. Expressing a vision clearly becomes central to making it executable: which pieces belong together, what each should contribute, and how the result should feel.

Blender MCP and Ableton MCP are his concrete examples, but Ahuja also reports seeing integrations for PostGIS, Houdini, Unity, and Unreal Engine. He expects that expanding set of connections to let more people create across media. His enthusiasm rests on the possibility that someone with a clear idea could direct the necessary tools before becoming an expert in each one.