It is time to put everything together. In this part you build four small but complete game assets — a crate, a furniture set, a car, and a full roadside scene — entirely by prompting Claude Code. You never open a modeling tool by hand, never push a vertex, and never write a line of Python. You describe what you want, Claude drives Blender through the MCP add-on, and then you inspect and refine with follow-up prompts.
Each project follows the same loop: prompt to create, prompt to validate, prompt to refine. The prompts below are written to be copied verbatim into Claude Code. Treat the validation and cleanup prompts as first-class steps — they are how you catch stray default Cube names, duplicate materials, and objects that escaped their collections.
Before starting, confirm the bridge is live: claude mcp list should show blender, you should have clicked Connect to Claude in Blender 5’s BlenderMCP sidebar tab, and /mcp inside Claude Code should list the server. The surest check is to ask Claude to inspect the scene — if it reports your objects, the bridge is live. If any of those is off, the prompts will fail before Blender ever moves.
Project 1 — Low-Poly Crate
The crate is the classic first game asset: cube-based, low-poly, and a good way to confirm that naming, collections, and materials all flow through cleanly. Paste this into Claude Code.
Use Blender MCP to create a low-poly wooden crate. Requirements:
- Use simple cube-based geometry
- Add darker wooden strips on the sides
- Slightly bevel the edges
- Use named objects
- Put everything in collection_crate
- Add simple brown materials
- Add camera and light
Claude will create the cube body, add the strip geometry, apply the bevel, build the brown materials, and organize the result into collection_crate — reporting each step as it goes. When it finishes, do not trust your eyes alone. Run a validation prompt so Claude reads the scene back to you from Blender’s own data.
Inspect the crate scene and tell me:
- object count
- material names
- whether all objects are inside collection_crate
- whether any default Cube/Cylinder names remain
If Claude reports a leftover Cube.001 or an object sitting at the scene root instead of inside collection_crate, just tell it to fix that specific item. This validate-then-fix habit is what keeps later, larger scenes from turning into a mess.
After validation passes, prompt Claude to export the crate as a GLB and place it in a folder you choose. Then ask it to confirm the export succeeded and report the file path. You now have a reusable game asset produced without touching the modeler.
Project 2 — Table and Chair Set
This project introduces real-world scale and reusable, separable parts. You ask for one table and two chairs, each built from named sub-objects so the parts can be reused or re-textured independently.
Use Blender MCP to create a low-poly table and chair set. Requirements:
- Real-world scale in meters
- One table
- Two chairs
- Separate objects for tabletop, legs, seats, and backrests
- Put all objects in collection_furniture_set
- Use simple wood and metal materials
- Add camera and light
Because you specified meters, Claude sizes the pieces to plausible furniture dimensions rather than arbitrary Blender units — important the moment this set lands in a game engine alongside other assets. Once the set exists, push it toward production quality with a follow-up.
Make the furniture more game-ready:
- reduce unnecessary detail
- apply consistent naming
- make the object origins reasonable
- keep materials simple
Sensible object origins matter for later work: a chair whose origin sits at the base of its legs snaps to the floor predictably and rotates around a natural pivot. Ask Claude to confirm the origins after the cleanup, so you know the change actually took effect in the scene.
Prompt Claude to inspect collection_furniture_set and list every object with its dimensions in meters. Verify the tabletop height is roughly 0.75 m and the chairs are proportioned to match. If anything is off scale, ask Claude to correct only that object.
Project 3 — Low-Poly Compact Car
The car is your first compound object: many named parts — body, cabin, windows, wheels, lights — that must read as one coherent vehicle. The strict naming list is deliberate. Predictable names let you target any single part in a follow-up prompt without ambiguity.
Use Blender MCP to create a generic low-poly compact car. Rules:
- Do not copy any real car brand
- Use primitive shapes only
- Put everything in collection_vehicle
- Use separate named objects for: car_body, car_cabin, car_window_front, car_window_side_left, car_window_side_right, car_wheel_fl, car_wheel_fr, car_wheel_rl, car_wheel_rr, car_headlight_left, car_headlight_right, car_taillight_left, car_taillight_right
- Apply simple materials
- Add bevels where useful
- Add camera and light
Claude assembles the car from primitives, names each part exactly as listed, and groups everything under collection_vehicle. Once the parts are in place, refine the overall shape without bloating the mesh.
Inspect the car model. Improve its silhouette while keeping it low-poly. Do not add excessive geometry.
The phrase “do not add excessive geometry” is doing real work: it tells Claude to nudge proportions and angles rather than subdivide the mesh into something heavy. Low-poly is a constraint you enforce through your prompts, every time.
Ask Claude to verify that all thirteen named parts from the list are present in collection_vehicle, with no missing or misnamed objects and no stray primitives left outside the collection. If the four wheels do not share one material, prompt Claude to consolidate them onto a single tire material.
Project 4 — Low-Poly Garage Scene
The final project is a complete environment that reuses ideas from the first three. You assemble a building, a road, props, your generic car, lights, and a framed camera — all sorted into a clean collection hierarchy. This is where disciplined collections and naming pay off, because the scene has too many objects to manage by eye.
Use Blender MCP to create a low-poly roadside garage scene. Scene requirements:
- Small garage building
- Road
- Sidewalk
- Signboard
- Generic compact car
- Barrels
- Crates
- Tires
- Simple lights
- Camera for a three-quarter view
Collections:
- collection_environment
- collection_building
- collection_vehicle
- collection_props
- collection_lighting
- collection_camera
Style:
- Low-poly
- Game-ready
- Simple materials
- Clean object names
Notice that the collection list mirrors how a game project is usually organized: environment, building, vehicle, props, lighting, and camera each get their own home. Claude populates the scene and files every object into the matching collection. Because a scene this size accumulates small mistakes, finish with a cleanup-and-report pass.
Inspect the whole scene and clean it up. Fix:
- unnamed objects
- duplicate materials
- objects outside collections
- overly complex geometry
- bad camera angle
Then report what you changed.
Asking Claude to report what it changed turns the cleanup into a reviewable summary: you see exactly which objects were renamed, which materials were merged, and what the camera was adjusted to. That report is your sign-off that the scene is genuinely game-ready.
The collection set above is a reusable template. Reusing the same names — collection_environment, collection_building, collection_props, and the rest — across every scene you build means a single cleanup prompt works the same way every time, and assets drop predictably into your engine.
After cleanup, prompt Claude to export the entire garage scene as a single GLB and report the object count, the total material count, and the file path. Then ask it to confirm every object belongs to exactly one of the six collections — with nothing left at the scene root. You have now built a complete, organized, exportable environment without modeling a single polygon by hand.