Skip to main content
Glama
Sign In
Claude Bridge

Claude Bridge

by JackLuciano
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

bl

Control a live Blender scene by running ordered operation lists that build, edit, check, animate, and render 3D objects as one undo step.

Instructions

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)

Input Schema

NameRequiredDescriptionDefault
opsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.1

TDQS

B3.3/5.0
Behavior3/5

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.

Conciseness3/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines3/5

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.

Deploy Server

Other Tools