Part 4 — Prompting Blender MCP properly

By now you can install the bridge and drive Blender 5 with plain prompts. The next skill is the one that actually separates a frustrating session from a productive one: how you phrase the request. Claude Code is only as precise as the instructions you give it, and a vague prompt invites vague (or destructive) results.

This part teaches you to prompt Blender MCP like an engineer writing a ticket — explicit requirements, hard constraints, and predictable names — and to wrap every change in a tight inspect-modify-inspect loop so Claude never wanders off and mangles unrelated objects.

Lesson 11: Bad Prompt vs Good Prompt

Here is a prompt that feels reasonable but gives Claude almost nothing to work with. The model has to guess the style, the topology, the object breakdown, the naming, and where everything lives. You will get a car — just not one you can predictably modify later.

Make a cool car.

Now compare it to a prompt written like a software ticket. Every decision is pinned down, so Claude has one clear target instead of a thousand defaults to invent. This is the version you actually copy-paste:

Use Blender MCP to create a low-poly compact car. Requirements:
- Generic design, no real brand
- Separate objects for body, cabin, wheels, windows, headlights, taillights, mirrors
- Put everything in collection_vehicle
- Use simple materials only
- Use low-poly style
- Add camera and area light
- Name all objects with car_ prefix

The difference is not politeness or length — it is specification. The good prompt names the collection, dictates the object breakdown, fixes the material and poly style, and enforces a naming prefix. That means the result is something you can inspect, re-prompt, and export with confidence, because you already know what every object is called and where it sits.

Lesson 12: The Standard MCP Workflow

A good prompt sets up one change well. A good workflow keeps every change safe and reversible. Adopt this loop for anything beyond a throwaway scene — it mirrors how you would touch production code: look before you leap, change only what you meant to, and verify the result.

1. Inspect the scene
2. Plan the change
3. Modify only named objects/collections
4. Inspect again
5. Fix issues
6. Save/export

The two inspect passes are the important part. The first tells Claude (and you) the exact current state, so the plan is grounded in reality rather than assumptions. The second confirms that the change landed as intended and nothing else moved. Here is a reusable prompt that bundles the whole loop into a single, scoped request:

Before making changes, inspect the current Blender scene.
Then modify only the collection named collection_vehicle.
After modifying, inspect the scene again and report:
- objects added
- materials added
- any naming issues
- any objects outside the correct collection

Notice how it constrains the blast radius (“modify only the collection named collection_vehicle”) and demands a structured report afterward. That report is your diff: you can see at a glance what was added and whether anything escaped the collection or broke your naming convention.