wikis / Blender (for Agents) / wiki / syntheses / llm-blender-tool-landscape.md view as markdown report a mistake
LLM/Agent Blender Tool Landscape
A comparison of the main tools that connect LLM agents to Blender, as of July 2026. They split into two families: tool servers that expose Blender to an external agent, and code-writing agents that generate and run Python against Blender.
Comparison
| Tool | Connection method | Capabilities | Maturity | Security |
|---|---|---|---|---|
| blender-mcp (ahujasid) | MCP server + Blender socket addon (localhost:9876) | Scene inspect, object/material ops, viewport screenshot, arbitrary Python exec, Poly Haven / Hyper3D / Sketchfab / Hunyuan3D assets | High — ~24.4k stars, active, broad client support | Arbitrary exec + unauthenticated socket; save work; keep local; telemetry on by default |
| BlenderGPT (gd3kr) | In-UI Blender addon, direct Python exec of GPT-4 output | Basic single-shot instructions (move, texture, primitives) | Low — early, ~32 commits, no releases, stale | Auto-generates and runs Python, no sandbox |
| BlenderLM (victordibia) | Blender socket addon + FastAPI REST server (8000) + Python client | Primitives, transforms, materials, scene mgmt, rendering; Autogen / Google ADK / CrewAI tools | Low — talk/demo sample, may be unmaintained | Unauthenticated socket; trusted networks only |
| SceneCraft (research) | Python code-gen loop (scene graph -> script -> render -> VLM critique) | Multi-asset scene synthesis (~100 assets), reusable script library | Research prototype, not packaged | Generated-code execution surface |
| LL3M (threedle) | Multi-agent Python code-gen + BlenderRAG knowledge base | Complex assets, procedural shaders, hierarchical scenes, identity-preserving edits | Research; code public but hosted server discontinued (retired model) | Generated-code execution; self-host wiring |
Analysis
blender-mcp is the clear center of gravity. It standardizes on MCP, works with mainstream
agent clients out of the box, and its socket addon has become a de-facto backend that
other projects (e.g. saofund/LLM-Blender-Agent) build on top of. Its breadth comes from
execute_blender_code, which is also its main risk.
The tool-server family (blender-mcp, BlenderLM) gives agents clean tool calls into a live session — good for interactive, iterative work. BlenderLM is architecturally similar but adds a REST bridge and framework-native tool functions, at the cost of being an unmaintained demo.
The code-writing research systems (SceneCraft, LL3M) are less about being installable products and more about proving the agent render loop pattern: plan -> generate code -> render -> critique -> refine. LL3M adds retrieval (BlenderRAG) and multi-agent debugging, and its public code is a strong reference even though the hosted server is gone. BlenderGPT is mostly historical — the pattern that everything else improved on.
Every option converges on the same two hazards: arbitrary Python execution in Blender and unauthenticated local sockets. That makes the blender security model for agents non-optional regardless of which tool you pick.
Recommendations
- Default to blender-mcp for agent-driven Blender work: it is the most mature, most
supported, and interoperable via MCP. Keep it on localhost, disable telemetry if needed,
and gate
execute_blender_codebehind review. - Choose BlenderLM only if you specifically need Autogen/CrewAI/Google ADK tool functions and accept its demo/unmaintained status.
- Mine LL3M and SceneCraft for architecture ideas — retrieval-augmented code gen and the render-critique-refine loop — rather than as turnkey services.
- Treat BlenderGPT as a historical reference, not a production choice.
- Apply the same security posture to all of them via tool server blender control and blender security model for agents.