Use Blender with AI models through MCP

What MCP actually connects

MCP, the Model Context Protocol, lets an AI application communicate with tools through a defined interface. The model reasons about a request; the application manages tool access; an MCP server exposes operations. For Blender, an integration must also connect those operations to a running Blender session.

Keep four pieces separate: the model, the client application, the MCP server, and Blender. Choosing a model does not install a Blender connection. A working connection does not make the model good at topology. A convincing answer in chat does not mean an object was created in your scene.

This distinction makes troubleshooting much easier. If no tools appear, inspect the client-server setup. If tools appear but Blender does not respond, inspect the server-to-Blender connection. If operations run but produce the wrong asset, inspect the task, context, and model’s proposed actions. Do not change everything at once.

Choose and inspect the integration

One public option is ahujasid/blender-mcp. Its repository describes a Blender add-on plus an MCP server, with scene inspection, object operations, and Python execution. It is a community integration, not an official Blender product. Read its current requirements and security notes before installing.

The documented setup installs the server tooling, registers it in a compatible client, installs and enables the Blender add-on, and starts the connection from Blender’s sidebar. The repository has separate client instructions, including Codex and Claude clients. Follow the instructions for your exact client and installed version.

Use a copy of a small scene for the first connection. Some tools can execute Python and modify files, so give the integration access only to the work you intend it to operate on. Keep provider credentials in the client’s supported settings, not in a chat message, asset name, or shared project file.

Record the versions you used: Blender, the integration, the client, and the model identifier. This takes a minute and makes a later failure much less mysterious. If you update one piece, repeat the small connection check before opening an important scene.

Make the first task deliberately boring

Open a scratch scene with one object whose name you know. Ask the assistant to inspect the scene and report the object names and transforms without changing anything. Compare the report with Blender. This establishes that the assistant is reading the intended scene rather than describing a generic default.

Next, ask for one reversible change to that named object, such as moving it one unit along an axis. Inspect the actual transform in Blender. Then undo or restore the saved scene and confirm that the baseline is back. You are checking both the forward path and recovery.

Only after that should you ask for a small constructed asset. A model that cannot reliably identify the selected object is not ready for “make an entire village.” A small test gives you a clear failure to diagnose. A village gives you many roofs and very little certainty.

Ask the assistant to report what it changed and what remains unchecked. Compare that report with the scene. If the connection provides screenshots, inspect them as one form of evidence, while still checking object structure and transforms. A render can conceal a duplicated mesh or an inconvenient origin.

A brief to make your own

Inspect the open Blender scene without changing it. Report the Blender version if available, the object names, the active object, and its location, rotation, and scale. If a value is unavailable, say so. Do not infer a scene from a previous message. Wait for the next task after reporting what you observed.

GPT-6 Astra with Blender and MCP

To use Astra, choose a client that offers the model and can connect to the Blender MCP server. Check both capabilities in that client. Model availability in one application does not imply that the same application exposes MCP tools on your computer.

Start with scene inspection and a single named-object edit. For a scripting task, give Astra the current Blender version, the relevant object names, the desired change, and what must remain intact. Ask it to inspect before creating and to keep the edit narrow enough to review.

For example, a lantern prop task might specify a separate handle, a grounded origin, a visible silhouette at the target camera distance, and no changes to unrelated collections. You can judge each requirement in Blender. “Make it professional” gives the model less useful direction and gives you less useful evidence.

The model’s documentation establishes model availability and capabilities at the provider level. This guide does not establish a measured Astra-to-Blender success rate. If you are comparing models, preserve the same starting scene and task so you can compare actual changes, repair work, and output quality.

Claude Fable with Blender and MCP

The same separation applies to Fable: select it in a compatible client, connect the server, and confirm which tools are exposed. A client’s MCP support and a particular model’s availability are separate settings to verify.

Use the same inspection-first task and scratch scene you would use for Astra. When a proposed edit is wrong, provide the observed mismatch rather than only asking the model to try harder. “The handle is a separate object, but its origin is three units away from the mesh” is actionable context.

For a fair comparison, keep your intervention rules stable. If you give one model three screenshots, a corrected script, and an extra hour, while accepting the other model’s first attempt, you are comparing workflows with different assistance. That may be useful, but label it accurately.

Fable may be the model you prefer for a particular task. This page does not claim a winner without a recorded comparison. The useful result is a scene you understand, can revise, and can move into your game.

Gemini, open models, and other tool-capable models

The workflow is not limited to two model families. A client may offer Gemini or open models running on your computer while managing MCP connections itself. Check the actual client/model combination rather than assuming the model name implies compatibility.

Test whether the client presents the Blender tools correctly, whether the model requests valid operations, and whether it uses the returned scene information. A tool-capable model can still struggle with long operation sequences or the spatial meaning of a change.

If your setup cannot use MCP, you can still work with an assistant by sharing scene details and reviewing Python scripts before running them in Blender. That is a different workflow with more manual steps. It can be a perfectly useful choice when you want direct control over each operation.

Keep one model-neutral task file with the starting scene, asset requirements, and review criteria. Then compare candidates on that task. It will stay useful longer than a collection of near-identical “model plus Blender” prompts.

Define the asset as part of a game

A lantern for a distant background and a lantern carried beside the camera are different assets. Begin with the role: what does the object communicate, how large will it appear, does it move, and can the player interact with it? Those answers guide the amount of detail and the structure you need.

For Night Mail, the lantern must read as a light source in a small play view. A clear handle and warm illuminated body matter more than tiny engraved letters. If the player can carry it, the attachment point and orientation matter. If it appears only as scenery, those requirements may be simpler.

Specify a working scale, an origin convention, and naming that your project can understand. Separate moving parts when the intended animation needs them. Ask for a limited material set if consistency matters more than surface complexity. These are practical requirements you can inspect.

Do not promise a universal polygon count or texture size. Your budget depends on the target device, camera, scene population, rendering pipeline, and art direction. Start with your project’s constraints and measure in the engine. A number borrowed from an unrelated game can create false confidence.

A brief to make your own

Create one lantern prop in a new collection named NightMail_Lantern. Keep all unrelated objects unchanged. The lantern will appear beside a small courier in a phone-sized game view. Prioritize a readable silhouette. Make the handle a separate named object, place the main origin at the base, and state the assumed scale. Use a small material set. Report the object structure and any requirements you could not verify. Do not download external assets or overwrite an existing project file.

Review the scene before judging the render

Inspect the outliner. Are there unexpected duplicates, hidden objects, or loose pieces? Check the transforms and origin. Rotate the object from several views. Look for geometry that only works from the beauty-shot angle.

Then view it at the intended game size. A detailed lantern can become an unreadable brown lump when reduced to a few dozen pixels. Temporarily remove decorative details and compare the silhouette. If the simpler version reads better, that is useful evidence about the asset’s job.

Check materials under the lighting you actually use. A material that depends on an elaborate Blender setup may not transfer as expected. Keep a simple test scene in the target engine so you can inspect the handoff early.

If the assistant makes a repair, ask for the smallest relevant change. Rebuilding the whole object after every note makes comparison difficult and can quietly lose parts that were already correct. Save a checkpoint before larger revisions.

Finish with an import, not a screenshot

Export through a format supported by your engine and project. Import into a small test scene before populating a level with copies. Check scale, orientation, material assignment, hierarchy, and any animation. A successful export dialog only tells you that a file was written.

Place the object beside the player at the real camera distance. Does it communicate its role? Does the attachment point work? Does collision, if required, behave sensibly? Does the object remain readable while the camera or character moves?

Write down what had to be repaired after import. That work belongs in your evaluation of the workflow. A model that produces an attractive Blender render but needs a long cleanup may be less useful for your project than one that makes a simpler, well-structured prop.

Keep the Blender source, exported asset, and a note about versions together. The goal is an asset you can revisit without reconstructing the entire chat. If you cannot explain which object is authoritative or how the export was made, tidy that up before making ten more props.

Work a lantern through one complete revision

Use three views of the same asset: an inspection view in Blender, the normal game camera, and the asset moving with the courier. Give each view a different question. Is the structure clean? Is the role readable? Does the attachment behave? One flattering image cannot answer all three.

Suppose the handle reads well in Blender but vanishes in the game. Ask for a thicker handle while preserving the lantern body, origin, material names, and attachment point. Inspect the scene before exporting. Then replace the asset in the same engine test scene and compare at the same camera distance. This is a repair you can judge without changing the entire art direction.

Next test a deliberately awkward case: rotate the lantern, place it against a background of similar value, or duplicate it several times in view. These checks can expose an incorrect pivot, a weak silhouette, or a material that only looks right under one light. Fix the relationship that failed. Do not keep adding texture detail to a silhouette problem.

Keep a short record: starting file, requested edit, changed objects, export settings, destination scene, and observed result. The record lets you repeat the handoff when a different model or client helps with the next revision. It also separates the assistant's work from manual cleanup. Both belong in the cost of the workflow.

Compare the whole workflow, including the boring part

Run the same task from the same source file when comparing Astra, Fable, or another model. Include failed attempts and the time spent repairing the handoff. If one model produces a beautiful first result and another preserves an editable structure through three changes, the better choice depends on the work ahead.

Avoid publishing a universal winner from one lantern. State the client, model, server revision, Blender version, task, and limits of the comparison. A useful technology guide teaches readers how to evaluate their own setup, even after the model names change.

Troubleshoot one boundary at a time

Keep the workflow bigger than the model name

A reliable process survives a model change. Inspect the scene, make a narrow edit, check the result, save a checkpoint, and test the asset in its destination. A stronger model can make that process easier. It does not remove the need to know what the asset is for.

If you are still unsure what the player should see or do, step back to the design question. A perfectly connected tool can build the wrong thing very efficiently. The game-design course helps you decide what is worth building; this guide helps you carry out one part of it.

Sources & further reading

References for the tools and facts discussed here. Follow the documentation for the versions you use.

• Model Context Protocol: architecture overview
• Blender MCP: community integration and setup
• Blender Python API documentation