Claude Bridge
Drives a live Blender session from Claude via a chat panel inside Blender or from Claude Code, exposing 45 high-level ops instead of Python scripts. Provides scene building and editing (add, move, place, edit faces, curves, rooms), material and node graph creation (shader, world, compositor, Geometry Nodes), rendering and multi-view screenshots, asset importing from Poly Haven and local PBR folders, animation and constraints, and game-asset checks and export presets, with built-in verification, change summaries and one-click revert.
Claude Bridge for Blender
Install with automatic updates (recommended): in Blender, open Edit ▸ Preferences ▸ Get Extensions ▸
Repositories ▸ + ▸ Add Remote Repository, paste
https://jackluciano.github.io/claude-bridge-blender/index.json, then search for Claude Bridge and click
Install. Blender will offer new versions as they come out.
Or ⬇ download the zip and install it via Get Extensions ▸ ⌄ ▸ Install from Disk.
Claude Bridge isn't on extensions.blender.org: the official platform doesn't host add-ons that connect to AI models, so it's distributed from this repository.

Drive a live Blender with Claude, from a chat panel inside Blender or from Claude Code, using compact, high-level ops instead of throwaway Python scripts. Runs on your normal Claude subscription (Pro/Max) through the Claude Code CLI. No API key is needed.
Blender sidebar chat ──spawns──▶ claude CLI (headless, your login) ─┐
├─ MCP stdio ─▶ mcp_server.py ─TCP 127.0.0.1:9877─▶ addon ─▶ bpy
Claude Code (terminal / desktop) ───────────────────────────────────┘What's new in 0.2
The biggest update so far: 45 ops (up from 28), three chat modes, and many fixes. Full list in the CHANGELOG.
Fixes you'll notice
🔒 Security: a web page could reach the bridge port and run code in Blender. The bridge now refuses anything that isn't from the MCP server (per-launch token, HTTP requests rejected).
💳 Always your subscription: an
ANTHROPIC_API_KEYin your environment is no longer passed to the chat's CLI.🪑 Edit Mode trap fixed:
addno longer puts new geometry inside the mesh you were editing, and a taken name no longer silently becomesBox.001.🪵 Real-world sizes:
dimsis baked into the mesh, so bevels and textures look the same on every object (the stretched wood grain on big floors is gone).
Building better scenes
📐
placeandcheck: rest objects exactly on the floor, a table or against a wall;checklists floating, overlapping, cut-off or unlit things as text, with a fix for each.🖼 Multi-view
look: camera + front + side + top in one image.rendercan now show Claude its own render and no longer changes your render settings.🌍
world: studio/interior/outdoor HDRIs bundled with Blender, a sky with a matching sun, or a flat colour.🧱
edit: extrude, inset, bevel and loop-cut faces picked by direction, material or your selection.🕸
nodes: shader, world, compositor and Geometry Nodes graphs in one compact op, plus a scatter preset.🪵 Free photo textures, HDRIs and models from Poly Haven (
asset), and your own PBR texture folders (img), at real-world scale without UVs.🌀
curve(pipes, cables, lathed vases and legs),room(walls with doors and windows from a floor plan),fit(normalize imported models),colandrename(tidy scenes).🎬 Animation:
key, a one-line turntable, spin/pop-in/bounce presets, constraints (con).🎮 Game assets:
check{only:["game"]},gameprep(UVs, transforms, LODs, collision) and Unity/Unreal/Godot export presets.
A better chat
🧭 Modes: Build, Plan first (tick the steps you want; applying costs no tokens) and Coach (Claude can look but not touch, with lessons that are checked locally).
↩️ What changed + Revert: every reply ends with
+added ~changed −removed, Select changed and a one-click Revert reply.🎯 Scene context: "make this red", "put a lamp here" just work (selection, mode and 3D cursor are sent along, ~30 tokens).
⚡ Fewer tokens: a Blender-only system prompt replaces Claude Code's coding prompt; a usage footer shows the context size, and long chats can continue in a fresh chat that carries the scene over.
🧩 Starters, templates and recipes: one-click starters, Critique/Light this/Tidy up templates, save a chat as a recipe that rebuilds the scene with zero tokens, and a demo scene that works before you log in.
🩺 Setup check: missing, logged-out or outdated CLI is detected with fix buttons; Copy diagnostics for bug reports.
⚙️ Preferences: port, default model and effort, CLI path, folders, standing instructions, safe mode (approve risky ops), teach mode (how-to hints), live streaming and an optional resident CLI process.
🍎🐧 macOS and Linux: the CLI is found even when Blender starts from the Dock; CI runs on all three systems.
Related MCP server: BlenderMCP
Features
In-Blender chat (View3D ▸ Sidebar ▸ Claude): replies stream in live, tool calls are shown inline, and Claude changes the scene while you watch. Each reply ends with a summary of what changed and a Revert button.
Three modes: Build, Plan first, Coach (see above). Model picker (Opus default, Sonnet, Haiku, CLI default) and effort picker.
Chat history: every chat is saved. Pick an old one from the dropdown to reopen it; the Claude session resumes with its full context.
Screenshots and images: attach a clean viewport capture, the whole Blender window, an image file, or paste with Ctrl+V (works even while typing in the chat field; Windows). Big images are downscaled first.
Inbox: drop GLB/FBX/OBJ files into the Inbox folder and import them at a sensible size with one click.
Built-in skill (
claude_bridge/skill/SKILL.md): workflow and real-world modelling tips. It's part of every in-Blender chat, and installed for Claude Code as theblender-bridgeskill.Token-lean by design:
The chat runs the CLI with no built-in tools, skills, other MCP servers or user hooks, and its own short system prompt.
Two MCP tools with a ~1.3k-token schema covering 45 ops.
Each op reply is one line, a batch is one call and one undo step, and captures are small JPEGs.
Why ops instead of scripts
Script-based bridge | Claude Bridge | |
Typical action | 200–600 tokens of Python |
|
Result | free-form prints / tracebacks |
|
Verification | separate query call | built into every op's reply, plus |
Many changes | many calls | one batch = one call = one undo step |
Seeing the scene | full screenshots |
|
Python is still there as a last resort (py op), and api looks up operator arguments and node sockets in your
Blender so Claude doesn't have to guess.
Install
Requirements: Blender 4.2+ (tested on 4.2 LTS and 5.2), and Claude Code installed
and logged in (claude once in a terminal). Python 3.10+ only for installing from source.
From the extension repository (easiest, with updates)
In Blender, go to Edit ▸ Preferences ▸ Get Extensions ▸ Repositories ▸ + ▸ Add Remote Repository and paste
https://jackluciano.github.io/claude-bridge-blender/index.json.Search for Claude Bridge in Get Extensions and click Install. Updates show up there too.
The in-Blender chat works right away. The setup check tells you if the CLI is missing or logged out.
For Claude Code (optional): in Sidebar ▸ Claude ▸ Bridge, click Connect Claude Code, then restart Claude Code.
From a release zip
Download claude_bridge-x.y.z.zip from Releases
and pick it in Edit ▸ Preferences ▸ Get Extensions ▸ ⌄ ▸ Install from Disk…. Zip installs don't update by
themselves.
As a Claude Code plugin
claude plugin marketplace add JackLuciano/claude-bridge-blenderclaude plugin install blender-bridge@claude-bridge-blenderThis adds the MCP server (via uvx claude-bridge-blender) and the skill. You still need the add-on running in
Blender.
From source
git clone https://github.com/JackLuciano/claude-bridge-blender
cd claude-bridge-blender
python install.pyinstall.py links claude_bridge/ into Blender's user add-ons (use --copy to copy instead), enables it,
registers the MCP server with Claude Code as blender-bridge, and installs the blender-bridge skill
(skip the Claude Code steps with --no-mcp).
Start Blender and open the Claude tab in the 3D view sidebar (press N). The bridge starts automatically.
In Blender: type in the chat field and press Enter, or click a starter.
In Claude Code: just ask, e.g. "make a low-poly table with a wooden material, then show me".
Chat panel
Control | What it does |
Chat dropdown / ➕ / 🗑 | switch between saved chats, start a new one, delete the current one |
Text field + ▶ | send (Enter also sends); ✖ stops a running reply |
Select changed / Revert reply | select what the last reply touched / undo the whole reply in one click |
🧊 / 🪟 / 🖼 / 📋 | attach a viewport capture / the Blender window / an image file / the clipboard (or Ctrl+V) |
📥 Inbox | import new models dropped into the Inbox folder (Shift+click opens it) |
☰ Templates | ready-made requests, Save as recipe, Replay recipe |
📄 Copy | copy the whole chat |
Mode · Model · Effort | Build / Plan first / Coach · Opus / Sonnet / Haiku / CLI default · reasoning effort |
Footer | context size and the last reply's steps, tokens and time; ⧉ continues in a fresh chat |
Chats are stored as JSON under Blender's config folder (…/config/claude_bridge/chats/, configurable in
Preferences).
MCP tools
bl: run a batch of ops
{"ops": [
{"op": "new"},
{"op": "room", "pts": [[0,0],[4,0],[4,3],[0,3]], "openings": [{"wall": 0, "at": 1, "w": 0.9}]},
{"op": "add", "type": "cube", "name": "Top", "dims": [1.2, 0.7, 0.04], "col": "Desk",
"mat": {"name": "Oak", "color": "#a0703c", "rough": 0.6}},
{"op": "tex", "obj": "Top", "kind": "wood"},
{"op": "place", "obj": "Top", "on": "floor"},
{"op": "world", "hdri": "interior", "strength": 0.5},
{"op": "check"}
]}Ops run in order, stop at the first error (reported with its index), and the whole batch is one undo step.
obj is a name, a list of names, "sel" or "active". Sizes are meters, angles degrees, colors "#rrggbb" or
linear [r,g,b].
Op | Args |
|
|
|
|
|
|
|
|
|
|
| absolute / relative transforms, |
| delete / duplicate ( |
| exact contact ( |
| material / procedural texture / PBR image set / Poly Haven textures, HDRIs, models |
|
|
| add or edit modifiers (incl. Geometry Nodes |
|
|
| curves, pipes and lathes / rooms with doors and windows |
| normalize imports / collections / batch renames |
| keyframes / frame range and presets (turntable, spin, pop_in, bounce, float) / constraints |
| point at things, scene camera, drive the user's viewport, background and lighting |
| any |
|
|
| game-ready meshes / |
| files ( |
| last-resort Python; assign |
look: see the result
Returns a small JPEG (default 512 px) rendered from the viewport with OpenGL, so it has no UI, popups or other
windows. cam: true gives the scene camera's view. views: ["cam","front","right","top"] returns one grid image
of several angles and leaves your view alone. View args (preset, orbit, zoom, frame, shading) are
applied first, so "orbit 45° and show me" is a single call.
Tests
python run_tests.py # headless: ops, chat (with a stand-in CLI), MCP end-to-end
python tests/live_smoke.py --chat # running Blender GUI: viewport, look, render, real chat, paste
blender --python tests/live_paste.py # Windows: real Ctrl+V keystroke into the chat71 headless tests run on Windows, macOS and Linux in CI. --chat makes a few real Claude requests on your
subscription.
Security
The add-on listens on 127.0.0.1 only. Every request must carry a per-launch token that only local processes of your user can read, and anything that looks like a web request is dropped.
It executes the ops it receives, including
py. Turn on Safe mode (Bridge panel or Preferences) to approve Python, scene clears, file opens, deleting your objects and file access outside the project/temp folders.The chat's Claude process can use only the two bridge tools: no shell, no file access. Coach and Plan modes are read-only, enforced by the bridge.
Poly Haven downloads happen only when asked, only from Poly Haven, are checksum-verified, and respect Blender's Allow Online Access setting.
Notes
Ctrl+V paste: Windows works everywhere, including the text field. On macOS/Linux it works over the sidebar but not while editing the text field; use the 📋 button there. Clipboard reading uses
pngpaste/AppleScript on macOS andwl-paste/xclipon Linux.Port: set it in Preferences (default
9877; a second Blender takes the next free port).CLAUDE_BRIDGE_PORTsets it for the MCP server.
Contributing
Feel free to fork, modify and improve it. Issues and pull requests are very welcome, from small fixes to new ops, lessons and recipes. See CONTRIBUTING.md for setup, how to add an op, and the test commands.
License
GPL-3.0-or-later (required for Blender add-ons that import bpy). Poly Haven assets are CC0.
Available Tools
2 toolsblB
Control the live Blender. ops = list of {"op":..., ...}; runs in order as ONE undo step, stops at first error.
Refs: obj = name | [names] | "sel" | "active". Angles deg. Colors "#rrggbb" or [r,g,b].
scene{filter,type} info{obj} get{path} prop{path,value} (path e.g. "scene.render.fps", "Cube.data.energy", "objects.Cube.location")
add{type:cube|sphere|ico|cylinder|cone|plane|circle|torus|monkey|grid|empty|text|curve|camera|point|sun|spot|area, name,loc,rot,scale,dims,size,mat,smooth,body,energy,color,args{}}
set{obj,loc,rot,scale,dims,name,hide,parent,smooth,props{dotted.attr:val}} move{obj,by,rot,scale}
del{obj} dup{obj,n,by,linked,name,tree} select{obj|"all"|"none",active,add} join{obj} (add/dup/cam take col:"Name")
col{name,obj,parent,hide,exclude,color} rename{obj,seq:"Leg_{n}",sort:x|y|z|name,prefix,suffix,find,replace}
curve{name,pts[[x,y,z]..],type:poly|smooth,cyclic,bevel,fill,lathe[[r,z]..],steps,mesh,mat} (pipes, cables, vases, turned legs)
fit{obj,height|longest|dims,at,floor,apply,faces} (normalize imports; import{path,fit:true|{height}})
mat{obj,name,color,metal,rough,alpha,transmission,ior,emit,emit_strength,coat,spec,slot}
tex{obj|mat,kind:wood|fabric|marble|noise|brick|checker|tiles|leather|concrete,color1,color2,scale,bump,rough[min,max]} (procedural texture)
img{obj|mat,path|dir|maps{albedo,rough,normal,metal,disp,ao},size_m,proj:box|uv} (photo PBR set at real scale, no UVs needed)
asset{search,type:textures|hdris|models} -> ids; asset{id,res,obj|mat,size_m | rot,strength | at,height} (free CC0 Poly Haven; downloads)
mod{obj,type:bevel|subsurf|array|mirror|solidify|bool|decimate|weld|wireframe|screw|displace|remesh|nodes|...,name,props{},inputs{GN input:val},apply}
nodes{mat|obj|world|gn|comp, add{id:type|alias}, set{"id.Socket":v,"id.prop":v,"ramp.0":"#hex"}, link["a.Out>b.In"], del[ids], show, preset:"scatter"+instance,density,scale} (ids: bsdf,out,bg,in,rl)
apply{obj,mod:name|"all",xform:loc|rot|scale|all}
edit{obj,sel:all|keep|+z|-y..|{normal,tol}|{mat}|{above}|[ids],do:[{extrude:d|[x,y,z]},{inset:w|{w,depth}},{bevel:{w,seg}},{cut:{axis,n}},{bisect},{delete},{move},{scale},{subdivide},{mat},{smooth}]} (steps chain on new faces)
room{pts[[x,y]..],h,t,openings[{wall:i,at,w,h,sill(0=door)}],name,floor,ceiling,walls[i..],wall_mat,floor_mat} (walls+doors+windows+glass; walls:[0,1]=open corner)
place{obj,on:"floor"|name,at:[x,y]|"center",against,side:+x|-x|+y|-y,gap} (exact contact by real bounds)
check{obj,only:[floating,overlap,frame,scale,images,light,cam]|["game"],budget} (measured problems + fix hints; run before the final look)
gameprep{obj,engine:unity|unreal|godot,uv,apply,lods,collision,names} export{path,preset:unity|unreal|godot,obj,per:"object"}
aim{obj,at} cam{name,loc,at,lens,active}
key{obj,f,loc,rot,scale,props{},interp:linear|bezier|constant|bounce|...,ease:in|out|in_out}
anim{start,end,fps,preset:turntable|spin|pop_in|bounce|float,obj,turns,stagger,height}
con{obj,type:track|damped_track|follow_path|copy_loc|copy_rot|child_of|limit_dist|floor|...,target,name,props{},animate}
view{preset:front|back|left|right|top|bottom|camera|persp|ortho, orbit[yaw,pitch], zoom, dist, at, frame:"sel"|"all"|name, shading:solid|material|rendered|wireframe}
bop{id:"mesh.subdivide",args{},obj,edit,ctx:"view3d"} (any bpy.ops operator)
api{id|path|node|search} (look up operator args, writable props, node sockets in this Blender; use before guessing)
world{color,strength | hdri:studio|interior|forest|city|courtyard|night|sunrise|sunset|path,rot | sky:true,sun_elev,sun_rot,sun | bg}
render{path,res[w,h],pct,samples,engine,preview,look,max} (look:true returns the image; settings restored) import{path} export{path} save{path} open{path} new{keep} undo{n} redo{n}
py{code} (last resort; set out to return)
| Name | Required | Description | Default |
|---|---|---|---|
| ops | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose two critical traits: all ops run as ONE undo step and execution stops at the first error, plus "look:true returns the image; settings restored" for render and the download behavior for asset. However, it says nothing about permissions, return payloads for the other 40+ ops, or side effects like file writes from save/export/open.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The critical contract is correctly front-loaded (op list, one-undo-step, error stop, ref conventions) before the catalog. But the body is an extremely dense wall of telegraphic entries where op names, params, and parenthetical hints blur together, hurting scannability even if little is strictly redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 45-op dispatch tool with no annotations and no output schema, the description covers input surface impressively but omits return values for nearly every op and gives no guidance on typical multi-op workflows. An agent could invoke simple ops correctly but would be guessing on outputs and on some advanced ops' semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% — the schema exposes only an untyped ops array with an op enum — so the description must document everything, and it does define conventions (obj refs, degrees, hex colors) and inline param lists per op. But the notation is telegraphic: params like dims, body, args{}, fit options, budget, and props{dotted.attr:val} are named without types, defaults, or examples, leaving real ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb+resource: "Control the live Blender," and immediately defines the core contract (ops list, executed in order as one undo step). The enumerated op catalog makes the scope unmistakable. It never mentions the sibling tool "look," so there is no explicit differentiation, keeping it out of 5 territory.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage guidance exists but is scattered inside individual op entries rather than stated up front: "api ... use before guessing," "py ... last resort," "check ... run before the final look." These are genuinely useful routing hints, but there is no overall statement of when to call bl versus look, or of prerequisites/ordering between the high-level workflows.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lookA
Small JPEG of the user's viewport (or camera view with cam:true). Optional view args (preset, orbit, zoom, frame, shading, dist, at) are applied first. max = longest side px (default 512; use 256-384 when possible). views:["cam","front","right","top"] = one grid image of several angles for the price of one (leaves the user's view alone).
| Name | Required | Description | Default |
|---|---|---|---|
| cam | No | ||
| max | No | ||
| keep | No | ||
| zoom | No | ||
| frame | No | ||
| orbit | No | ||
| views | No | ||
| preset | No | ||
| shading | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral burden. It discloses that the output is a JPEG, that optional view args are applied first, and that views leaves the user's view alone. However, it never explains the keep parameter and says nothing about permissions or other side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense paragraph but is front-loaded with the core purpose. Every clause carries useful information, though the parenthetical lists make it slightly harder to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 9-parameter tool with no annotations and no output schema, the description covers the main behavior and several parameters. It still leaves keep unexplained and lacks detail on view args, so an agent does not have full invocation clarity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% across 9 parameters, so the description must compensate. It explains cam, max (default and pixel meaning), views (contents and benefit), and lists several view args, but it completely omits keep and does not explain the formats of the named view args.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific output: a small JPEG of the user's viewport or camera view. That identifies the resource and format clearly. It does not differentiate from the sibling tool 'bl', so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives practical guidance: use cam:true for camera view, prefer max 256-384, and use views to get several angles in one grid image. It does not name an alternative tool or state when not to use this one, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
2 tool updates
v0.2.1- First observed
bl - First observed
look
TDQS
Scored across 2 tools
The set collapses to one god-tool (bl) whose sub-ops overlap heavily: property setting can be done via prop, set{props}, nodes set, or bop; movement via move, set{loc}, and apply xform; and the look tool duplicates bl's render look:true and view presets. With 50+ operations inside a single description, an agent faces constant misselection risk between import/export (listed twice, once inside fit), add vs dup vs bop, and del vs edit{delete}.
Within bl the ops follow a consistent terse lowercase style (add, del, mat, tex, mod, con, bop, py), but the style mixes verbs (add, move, apply, aim) with bare nouns (scene, prop, col, nodes, room) and heavy abbreviations. The two top-level names don't follow a shared pattern either: 'bl' is an abbreviation while 'look' is a verb.
Literally there are only 2 tools, which is thin for a Blender bridge, but the bl tool crams roughly 50+ distinct operations into one dispatch surface, so the effective API is far above the 3-15 sweet spot. The single mega-tool trades count for a massive surface, which is borderline rather than well-scoped.
Coverage of the Blender domain is near-total: modeling (add/edit/mod/room/curve), materials and PBR textures, assets, geometry nodes, animation and constraints, camera/lighting, viewport capture, render/export, scene checks, and escape hatches (py, bop, api) for anything not covered. There are effectively no dead ends.
Maintenance
Related MCP Connectors
Connect your AI assistant to Blender for 3D modeling, Geometry Nodes, materials, lighting, animation, rendering and export. Inspect real scenes and viewport images, refine the result and restore checkpoints. OAuth connects your chat to Blender Bridge Desktop on an online Windows 10/11 x64 computer running Blender 4.2+. The chat can run on another device. Requires an active Blender Bridge account; 7-day trial available. AI model access is separate.
Cloud Blender for AI agents: build, inspect, render and animate 3D scenes over remote MCP. Keep editable .blend projects and export GLB or STL. Make your first 3D asset free—30 compute minutes per UTC month, no credit card. First 100 eligible Free account owners to use all 30 minutes in one UTC month by December 31, 2026 UTC receive one calendar month of beta free: 4 compute hours per UTC month, 2 concurrent workers per deployment, 2 deployments, 2048×2048 renders at up to 256 samples, and 10 GiB storage. Existing usage counts toward the 4-hour allowance. Limited to 100 rewards; expires January 1, 2027 00:00 UTC. Free resumes afterward without an automatic charge. Examples, eligibility and terms: https://sceneplane.online/launch?utm_source=glama&utm_medium=directory&utm_campaign=first100
Blender and GLB/FBX/USD/STL rendered on cloud GPUs for AI agents: product shots, turntables, MP4
Use AI models for chat, image, and video generation from Claude Code and other MCP hosts.
Related MCP Servers
- AlicenseBqualityDmaintenanceConnects Blender to Claude AI through the Model Context Protocol, enabling AI-assisted 3D modeling, scene creation, and manipulation through natural language commands.172MIT
- AlicenseNot gradedqualityDmaintenanceConnects Claude AI to Blender through the Model Context Protocol, enabling AI-assisted 3D modeling, scene creation, object manipulation, and material control. Supports downloading assets from Poly Haven and generating 3D models through Hyper3D Rodin.2MIT
- AlicenseAqualityDmaintenanceConnects Blender to Claude AI, enabling AI-assisted 3D modeling, scene creation, object manipulation, material control, and code execution directly in Blender through natural language prompts.17MIT
- AlicenseAqualityCmaintenanceConnects Blender 3D modeling software with Claude AI, enabling natural language control of 3D modeling and scene manipulation tasks.175MIT