Source confidence: high

Blender MCP + Tripo — Reference Image to Rendered Scene, Driven by Claude

In short: Running this system sets up Blender MCP with a hosted image-to-3D generator and drives it from Claude to turn one reference photo into a rendered Blender scene, with the integration claims checked against the code.

Key fact Detail
What it covers 3D, agents, LLM, reference
Tools Blender, MCP, Tripo, Unity, Unreal Engine
Posts covered 1 post (1 S-tier) · top: Blender MCP + Tripo — 2D reference image to…
Creators @bilawal.ai
Sources dated Mar 2025
Prompt system Run-it-yourself prompts
Last verified 2026-10-22

Blender MCP GitHub: https://github.com/ahujasid/blender-mcp Stars: 18.5k (as of writing) — by far the dominant Blender MCP implementation License: MIT Cloned to: ./repos/blender-mcp/ (1.5 MB — pure Python server, no weights) Tripo: https://www.tripo3d.ai/ | docs: https://platform.tripo3d.ai/docs

What it is

Blender MCP is a Model Context Protocol server that exposes Blender as a set of tools an LLM can call. You run a tiny socket server inside Blender (via an addon) and an MCP server outside Blender that Claude Desktop, Claude Code, Cursor, or VS Code connects to. From then on, Claude can create objects, apply materials, inspect the scene, run arbitrary Python in Blender's context, pull HDRIs and assets from Poly Haven, and — the reason this guide exists — generate 3D models on demand via Tripo (Hyper3D Rodin) or Hunyuan3D and import them into the current scene.

Combined with Tripo's hosted text-to-3D / image-to-3D API, this turns Claude into a functional 3D scene director. You hand Claude a reference photo, say "build me this scene in Blender and render it from a low angle," and watch it happen. It is the closest thing we have in 2026 to a natural-language Blender operator.

The creator (Siddharth Ahuja / @ahujasid) is an independent developer; this isn't a Blender Foundation or Tripo project. It's the de-facto standard because it went viral on X in early 2025 and everyone built on top of it.

How it works under the hood

There are two processes:

  1. Blender addon (addon.py) — installed inside Blender, runs a Python socket server bound to BLENDER_HOST:BLENDER_PORT (default localhost:9876). When a message arrives, it runs the requested Blender Python API call on the Blender main thread and returns the result.
  2. MCP server (src/blender_mcp/server.py) — a stdio-transport MCP server launched by Claude Desktop / Claude Code. It translates MCP tool calls into socket messages to the addon.

The protocol is simple JSON-over-TCP: a request with type and params, a response with status and result. Because the Blender side runs arbitrary Python, the server is extremely powerful and correspondingly dangerous — save your work before letting an agent drive it.

Tools the server exposes

The Hyper3D Rodin endpoint is Tripo's white-labeled API. Blender MCP ships with a free-tier key so you can try it without signing up, rate-limited to a handful of generations per hour. Your own Tripo key removes the limit.

Tripo in one paragraph

Tripo (tripo3d.ai) is the leading hosted text-to-3D / image-to-3D API. Their current model family is P1-20260311 (optimized for clean low-poly output) alongside v3.0 and v3.1 high-detail models. They support text-to-model, image-to-model, and multiview-to-model. Output is GLB with PBR materials, typically 20–60 seconds per generation on their backend. Pricing via fal.ai is roughly $0.20–$0.40 per model; direct Tripo Studio subscriptions start around $10/month for a credit pool. The API is REST: POST a job, poll for status, download the result. Docs at https://platform.tripo3d.ai/docs.

The important thing for this pipeline: Tripo is fast and consistent where Hunyuan3D-2 is slow and local. Use Tripo when iterating on a scene interactively with Claude; use Hunyuan3D-2 (see guides/hunyuan3d-2.md) when you want full local control, custom training data, or no API costs.

System requirements

No heavyweight ML runs on your machine unless you opt in to Hunyuan3D-2; Tripo and Poly Haven are hosted.

Quick start

# 1. install uv if you don't have it (see https://astral.sh/uv)

# 2. repo is already cloned at
#    ./repos/blender-mcp

# 3. install the Blender addon
#    In Blender: Edit > Preferences > Add-ons > Install > pick addon.py
#    Enable "Interface: Blender MCP", then in the 3D viewport N-panel
#    there's a BlenderMCP tab — click "Connect to MCP server".

# 4. configure Claude Code / Claude Desktop MCP settings with:
#    command: uvx
#    args:    ["blender-mcp"]
#    env:     TRIPO_API_KEY=tsk_your_key_here
#             SKETCHFAB_API_KEY=optional

# 5. restart Claude, start Blender, enable the addon's socket server,
#    and ask Claude: "What's in my Blender scene right now?"

If everything works, Claude will call get_scene_info, see an empty scene with a default cube, and happily start building things when you ask.

The full pipeline — reference image to rendered scene

Here's the canonical workflow the blender-mcp + Tripo stack enables. Every numbered step is a natural-language turn you'd give Claude in Claude Code:

  1. Drop a reference image in your project (say, a photo of a cozy Japanese tea room)
  2. "Analyze this reference image and list the major 3D objects I'll need to recreate the scene." — Claude reads the image and outputs: tatami floor, low table, tea kettle, shoji screen, hanging lantern, cushion x2.
  3. "For each object in that list, generate it via Tripo image-to-3D using a cropped region of the reference, and import each result into Blender with a sensible name." — Claude loops, calling generate_hyper3d_model_via_images for each object, polling poll_rodin_job_status, then import_generated_asset.
  4. "Lay them out in a plausible room arrangement based on the reference." — Claude calls modify_object to position and rotate.
  5. "Download a warm evening interior HDRI from Poly Haven and set it as the world background." — search_polyhaven_assets → download_polyhaven_asset.
  6. "Add a camera at human eye level, looking at the tea table, and set the Cycles render settings to 512 samples." — via execute_blender_code.
  7. "Render." — via execute_blender_code calling the Blender render operator.
  8. Iterate. Claude can see the result via a screenshot tool and adjust.

The whole loop, end to end, is doable in 5–15 minutes with Tripo on a decent internet connection. The same pipeline with manual Blender work would take a skilled artist hours.

Where it breaks down

Useful prompts to drive it from Claude Code

Claude is surprisingly good at all of these once the MCP connection is live. The bottleneck is your patience and your Tripo quota, not the tooling.

What we could build with it

Sources

Prompt system — run this yourself

Everything below is pasteable into Claude Code, Claude, or any agent. Use the one-shot when you want the whole result in one run; use the step prompts when you want to steer. Every step carries its own audit, and the gap audit at the end makes the agent find and fill what it missed.

Mission. Running this system sets up Blender MCP with a hosted image-to-3D generator and drives it from Claude to turn one reference photo into a rendered Blender scene, with the integration claims checked against the code. It produces a working MCP connection, a scripted reference-to-render run with every generated asset named, scaled to metres and logged, and a render compared against the reference. It is for a creator who wants a natural-language 3D operator. Done means the scene opens and renders headless in Blender 4.2 without errors, every asset has a provenance row, and a blind comparison rates the layout as matching the reference.

1 · Deeper, not bigger

Before running anything, make the task deeper rather than larger. Ask: what would a top professional do here that I am not asking for; what is the rawest material; which methods and tools; what, other than the model or me, proves it right. Then ask for exactly that.

Rewritten prompt — ask for exactly that:

I want Claude to turn a reference photo into a rendered Blender scene through Blender MCP and a hosted image-to-3D API. Act as a 3D generalist. First read the blender-mcp source (addon.py and src/blender_mcp/server.py) and list the actual tools and 3D generation providers it supports; the guide says Hyper3D Rodin is Tripo white-labeled, so verify that against both vendors' docs, and if Tripo is not wired in, call Tripo's REST API through a small helper. Then: (1) match the camera from the photo with fSpy and set units to metres; (2) block out the scene with primitives; (3) list hero objects and generate only those via image-to-3D from tight crops, logging task IDs, cost and time; (4) import each asset, normalize scale to a real-world height, apply transforms, check non-manifold edges and polycount; (5) light with a Poly Haven HDRI matching the photo, render in Cycles with denoising; (6) save the .blend and prove it renders headless in Blender 4.2. Compare the render with the reference side by side and by a blind pick. Read API keys from environment only, never print them, and save the scene before any execute_blender_code call.

2 · One-shot prompt

ROLE AND STANCE
You are a 3D generalist operating Blender through MCP from Claude Code. You build to the reference camera, generate only what primitives cannot do, and check every generated mesh before it enters the scene. You verify the guide's claims against the code before relying on them.

CONTEXT
- blender-mcp (ahujasid, MIT): an addon runs a socket server inside Blender on localhost:9876; an MCP server launched by uvx blender-mcp translates tool calls to JSON over TCP. Tools listed by the guide include get_scene_info, get_object_info, create_object, modify_object, delete_object, set_material, execute_blender_code, Poly Haven search and download, Sketchfab search and download, generate_hyper3d_model_via_text and via_images, poll_rodin_job_status, import_generated_asset, and Hunyuan3D generation.
- The guide claims the Hyper3D Rodin endpoint is Tripo's white-labeled API and that a free-tier key ships with the server. Public materials suggest Hyper3D Rodin is a separate vendor's product. Treat both as unverified.
- Tripo: hosted text-, image- and multiview-to-3D, GLB with PBR, 20-60 s per generation per the guide, about 0.20-0.40 USD per model via fal.ai, model family named P1-20260311 plus v3.0 and v3.1. Unverified until checked in Tripo's docs.
- The guide's known weak points: single-image segmentation, arbitrary scale ('assume 1 Blender unit = 1 metre'), baked PBR not matching scene light, game-ready not film topology.
- execute_blender_code runs arbitrary Python inside Blender. Save first.

HARD CONSTRAINTS
- API keys from environment only; never echo, log or commit them.
- Save the .blend before each execute_blender_code call; keep numbered versions.
- Units: metric, 1 unit = 1 metre, set before any import.
- At most 8 generated assets per scene; everything else is primitives, Poly Haven assets or reuse.
- Every asset gets a provenance row: name, source (Tripo task ID, Poly Haven ID, primitive), prompt or crop file, cost, generation time, licence.

DELIVERABLES, IN ORDER
1. tools.md: the tool list and providers from server.py and addon.py, with file and line references, and the verdict on the Rodin-equals-Tripo claim.
2. setup.md: Claude Code MCP config (command uvx, args blender-mcp, env names only), addon install steps for Blender 4.2, a get_scene_info round trip.
3. camera/: fSpy project and imported camera matching the reference.
4. blockout.blend: primitives placed to the camera.
5. assets/: crops, generated GLBs, provenance.csv, mesh_audit.csv (dimensions, polycount, non-manifold count).
6. scene.blend: assets placed, HDRI lit, Cycles with denoising, render.png.
7. compare/: reference and render side by side, an SSIM or LPIPS score, and a blind pick result.

GAP ANALYSIS (BUILT IN)
Keep gaps.md: which provider the generation tools actually call; whether a bundled free key exists and its limits; Tripo model names, prices and speeds measured versus claimed; assets that failed or needed manual fixes; materials changed after import; anything execute_blender_code did that the named tools could not. Fill what you can now.

SELF-QUESTIONS
- Does the camera match the reference before I place anything?
- Is each asset's height right in metres?
- Did any generated mesh arrive with unapplied rotation or scale?
- Do the generated materials fight the HDRI lighting?
- Could a primitive or Poly Haven asset have replaced any generated one?

STOP CONDITIONS
Stop and report if the MCP round trip fails after two fixes, if no generation provider works without a key the user lacks, or if spend passes 5 USD. Otherwise stop when all seven deliverables exist.

RETURN FORMAT
Table of deliverable, path, status; tool and provider verdict; asset count, total cost and time; headless render result; comparison score and blind pick; top five gaps.

3 · Step-by-step prompts

Step 1 — Ground truth: read the server and vendor docs

Goal: Know what the MCP server really exposes and which vendor generates the models.

Clone github.com/ahujasid/blender-mcp (pull latest if you already cloned it to ./repos/blender-mcp/). Read addon.py and src/blender_mcp/server.py.
1. List every MCP tool with its parameters, the socket host and port, and what each tool sends to the addon. Cite file and line.
2. For the 3D generation tools, find the HTTP endpoints they call and the environment variables they read. Determine whether they call Tripo, Hyper3D Rodin's own vendor, fal.ai, or something else.
3. Check whether a default or free-tier key is embedded, and its stated limits. Do not print key values.
4. Read Tripo's API docs: task creation for image-to-model, polling, output formats, current model version names and prices. Read the Hyper3D Rodin docs to identify its operator.
5. Write tools.md with a verdict on the guide's claims: 'Hyper3D Rodin is Tripo's white-labeled API', 'ships with a free-tier key', 'P1-20260311 model', '0.20-0.40 USD per model via fal.ai'.

Expect: tools.md with cited tool table, provider verdict and claims table.

Audit before moving on: Every tool and provider statement cites a file and line or a doc URL. If Tripo is not wired in, plan a helper for step 4 instead of forcing a mismatched tool.

Step 2 — Install and round-trip

Goal: Get Claude Code talking to Blender reliably.

Install uv. In Blender 4.2 LTS: Edit > Preferences > Add-ons > Install, choose addon.py, enable it, open the BlenderMCP tab in the N-panel and start the server. Configure Claude Code's MCP settings with command uvx, args blender-mcp, and env entries TRIPO_API_KEY and any other provider key, set from your shell environment, not pasted into the config file if your client supports env passthrough.
Restart Claude Code and ask: 'What is in my Blender scene right now?' Confirm get_scene_info returns the default cube, camera and light.
Then test each tool once on a throwaway scene: create a cube, move it, set a material, search Poly Haven for an HDRI, and run execute_blender_code that prints bpy.app.version. Record latency for each call.
Set scene units to metric with unit scale 1.0 and save as template.blend.

Expect: setup.md with config (key names only), a tool test table with latency, template.blend.

Audit before moving on: If any tool call hangs, check the addon is on the main thread and the port matches. Grep the config and logs for key values; any found must be removed and the key rotated.

Step 3 — Camera match and blockout

Goal: Build to the reference camera with primitives before generating anything.

Open the reference photo in fSpy. Mark two vanishing directions along obvious edges (table edges, floor lines) and set a known reference distance, such as a door height or table height. Export and import the fSpy project into Blender with the fSpy importer, giving a camera with matching focal length and pose. Set the reference as the camera background image.
Ask Claude, through the MCP tools, to list the major objects in the photo with an estimated real height in metres for each. Then block out each object with a primitive of that size, placed so it lines up with the photo through the camera view. Name objects clearly (table_low, cushion_left).
Render a quick Eevee preview from the matched camera with 50% opacity overlay of the reference.

Expect: camera/ fSpy files, blockout.blend, overlay preview PNG, objects.csv with names and heights.

Audit before moving on: In the overlay, the blockout's main edges should sit within a few percent of the image width of the photo's edges. If not, redo the fSpy calibration before generating assets.

Step 4 — Generate hero assets

Goal: Generate only objects primitives and libraries cannot cover, with full provenance.

From objects.csv choose at most 8 hero objects. For each, crop the reference tightly around the object, or provide a clean product photo if you have one, and save the crop in assets/crops/.
Call the image-to-3D path verified in step 1: the MCP generation tools if they reach the intended provider, otherwise a small Python helper calling Tripo's REST API with TRIPO_API_KEY from environment (create task, poll, download GLB). Record task ID, model version, start and end time, and cost in provenance.csv.
For anything a Poly Haven model covers adequately, use that instead and record its ID and licence.
Track total spend and stop at 5 USD.
For the first asset, generate twice from the same crop to see run-to-run variation, and once from a text prompt alone, so you know whether image conditioning is worth the cropping effort. Record Tripo's licence terms for generated models in provenance.csv.

Expect: assets/ with GLBs, crops, provenance.csv covering every asset.

Audit before moving on: Every GLB has a provenance row with a task ID. Compare measured generation time and cost with the guide's 20-60 s and 0.20-0.40 USD claims and record the difference in gaps.md.

Step 5 — Import, normalize and audit meshes

Goal: Make every asset scene-ready before placing it.

Save the .blend with a version number. Then, with execute_blender_code, for each GLB: import with bpy.ops.import_scene.gltf, join parts into one object, apply rotation and scale, set origin to the bottom centre, scale uniformly so its height equals objects.csv's real height, and rename it.
Run a bmesh audit per object: vertex and face count, non-manifold edge count, loose vertices, dimensions in metres. Write mesh_audit.csv. Decimate any object above 100k faces to a target you state.
Replace the matching blockout primitive with the asset, copying its location and rotation. Check materials: if baked lighting in the base colour clashes with scene light, reduce it by lowering texture contrast or switching to a neutral material for that object, and log the change. Put all generated assets in a 'generated' collection so they can be hidden for comparison.

Expect: scene_v*.blend files, mesh_audit.csv, a material changes log.

Audit before moving on: All hero assets have applied transforms (scale 1,1,1) and real-world heights within 5%. Any non-manifold count above zero is either fixed or justified in gaps.md.

Step 6 — Light, render, compare

Goal: Produce the final render and measure how close it is.

Use the Poly Haven tools to search and download an HDRI matching the reference's light (time of day, indoor or outdoor, warm or cool) and set it as the world. Add one area light only if the reference has an obvious key light the HDRI lacks.
Set Cycles, 512 samples, OpenImageDenoise, resolution matching the reference aspect ratio, and render from the fSpy camera. Save render.png and scene.blend.
Compare: place reference and render side by side, compute SSIM on downscaled greyscale versions and LPIPS if available. These are rough layout scores, not quality judgments.
Make a second render with the blockout only, and run a blind pick with at least 5 people: show the reference plus the two renders unlabeled, ask which matches better.

Expect: render.png, scene.blend, compare/ with side by side, scores, blind pick results.

Audit before moving on: If the final render loses the blind pick to the blockout, the generated assets hurt the scene; record which ones and why.

Step 7 — Validate against oracles and write the gap report

Goal: Prove the scene is portable and record what remains unverified.

1. Close everything and run blender -b scene.blend -f 1 with Blender 4.2 headless. Confirm the log shows no missing textures, no errors and that the frame was written.
2. Pack external files (File > External Data > Pack Resources) and repeat on a second machine or clean user profile if you can.
3. Reconcile provenance.csv with the provider's own task history.
4. Re-run the mesh audit on the final file.
5. Write gaps.md: each guide claim from tools.md with verified / unverified / false; measured versus claimed speed and cost; assets that needed manual fixes; tools that failed; anything done only through execute_blender_code. Fix what you can now and list the rest.
6. Record total wall-clock time from reference photo to final render and compare it with the guide's '5-15 minutes with Tripo' claim.

Expect: headless_render.log, a packed scene.blend, validation.md, gaps.md.

Audit before moving on: A headless render warning about missing files fails the step until packed. Confirm no API key value appears in the .blend's text blocks, scripts or logs.

4 · Gap analysis and audit

Run this after the build. It makes the agent enumerate its own claims, mark what is verified, rank the gaps and fix the top ones.

You are auditing a Blender MCP reference-to-render project you did not build. Read tools.md, setup.md, objects.csv, provenance.csv, mesh_audit.csv, compare/, validation.md and the final scene.blend.
1. List every claim: tool list, provider identity, free key, model names, speed and cost, asset dimensions, render result, blind pick.
2. Mark each verified, unverified or false with evidence: a file and line, a task ID, an audit row, a log line.
3. Re-check: units are metric at scale 1.0; every asset has applied transforms and a provenance row; spend stayed under the cap; the .blend renders headless in Blender 4.2 with packed resources; no API key value is stored in the .blend, configs or logs; saves preceded each execute_blender_code call.
4. List missing pieces: licences for generated assets, retopology for production use, animation readiness.
5. Rank gaps by impact on whether someone else can open and render the scene.
6. Fix the top three now.
7. Report what you could not fix and why.

Questions the agent must ask itself before it says done:

5 · What proves it right

6 · Failure modes

7 · Agent direction (unattended runs)

Start by reading server.py and addon.py; the provider question decides the rest of the pipeline. Cache downloaded GLBs, HDRIs and crops under assets/ so retries do not regenerate or re-bill. Keep Blender operations in the main loop, since they share one scene; a sub-agent may do the fSpy calibration and the vendor-docs reading in parallel. Save a numbered .blend before every execute_blender_code call. Stop and ask before spending past 5 USD, before adding a paid Sketchfab key, and when a provider requires an account the user has not set up. Never print or store key values. If an MCP call hangs twice, restart the addon server rather than retrying blindly. Return README.md linking tools.md, setup.md, camera/, assets/provenance.csv, mesh_audit.csv, scene.blend, render.png, compare/, validation.md and gaps.md, each with a one-line status.

Prompt system updated 2026-10-22 · all prompt systems · JSON