Skip to main content
Glama

blender_render_scene

Render a scene through its active camera and lights, one image per frame. Output beauty, mask, or normal passes; hide objects for clean plates and get images back.

Instructions

Render through the scene's OWN active camera and lights (shot rendering), one image per frame. mode: beauty | mask (needs objects: only they are drawn, white, silhouette in alpha) | normal. hide hides objects for this render (e.g. actors -> clean background plate). Returns the images.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
hideNo
modeNobeauty
widthNo
engineNoBLENDER_EEVEE
framesNo
heightNo
objectsNo
timeoutNo
ignore_gpu_guardNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.1/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. It usefully discloses that rendering uses the scene's own camera/lights, that it is one image per frame, and what mode/hide do. However it is silent on the 300s timeout, the engine choice, and the GPU-guard flag, all of which affect invocation behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Compact and front-loaded: the core behavior comes first, then mode semantics, then hide. Telegraphic style is efficient, though the mode line is dense enough to require a re-read.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 9-parameter render tool with no annotations, no output schema, and 0% schema coverage, the description is substantially incomplete. It leaves six parameters unexplained and says only 'Returns the images' without any format or shape detail.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% across 9 parameters, so the description must compensate. It only explains mode, objects, and hide; width, height, engine, frames, timeout, and ignore_gpu_guard remain completely undefined in both schema and description.

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?

States a specific verb (render) and resource (the scene through its own active camera and lights), and the 'OWN active camera ... (shot rendering)' phrasing implies contrast with a sibling that uses a supplied camera. It does not name blender_render explicitly, so differentiation is inferred rather than stated.

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?

The mode list gives implied usage context (mask for silhouettes, hide for clean background plates), but there is no explicit when-to-use guidance and no reference to the sibling blender_render or blender_screenshot to route the agent between them.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.