Skip to main content
Glama

render_final

Render a Blender scene to an image file using its lights, materials, and camera, then show the picture for review.

Instructions

Render the scene to a file with its own lights, materials and camera, and show the picture. Needs a camera: call set_camera first (or pass camera). For quick check pictures use render_sheet (overview) or render_view (any angle, no set-up). path is absolute, or relative to the work folder; the folder is created. engine: eevee (fast), cycles (slow, CPU, real light), workbench (flat preview, no lights needed). size is pixels for a square, or [width, height]. samples is the quality: 16-64 for eevee, 32-256 for cycles. transparent writes alpha (PNG, WEBP, TIFF, OPEN_EXR) and hides the world. denoise is for cycles only. view_transform: Standard keeps colours true; Filmic, AgX or Khronos PBR Neutral if the Blender build has them. exposure is in stops for this render only (+1 doubles the light); without it the scene exposure (set_post) is used. auto_exposure=true first renders a small probe and picks the exposure that puts the median luminance of the geometry at mid grey; the answer has auto_exposure. meter is a list of object names (with children) to measure instead of all geometry: give the model, so a floor or backdrop does not steer the exposure. Except for OPEN_EXR the answer has tone numbers of the written picture (0-1): frame and, when the geometry is known (meter, auto_exposure or transparent), object: median, mean, clipped_highlights and crushed_blacks. warnings appears when over 10% is clipped or over 50% is black. Read these numbers before you trust the picture. The scene settings are restored afterwards.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathYes
sizeNo
meterNo
cameraNo
engineNoeevee
denoiseNo
samplesNo
exposureNo
file_formatNoPNG
transparentNo
auto_exposureNo
view_transformNoStandard

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.4.0

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and discloses rich behavior: engine tradeoffs, sample ranges, scene settings restored afterwards, transparent alpha behavior, warnings thresholds, probe exposure, and return tone numbers. It does not contradict any structured field.

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?

The core action and prerequisites are front-loaded, and most sentences carry needed parameter or behavioral detail. However, the description is dense and would benefit from clearer visual grouping or shorter paragraphs for such a long list of points.

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

Completeness5/5

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

For a 12-parameter tool with no annotations and no output schema, the description is highly complete: it covers prerequisites, parameter behavior, return values, warnings, and image-quality caveats. The only minor omission is file_format nuance, which is unlikely to prevent correct invocation.

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

Parameters4/5

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

Schema description coverage is 0%, so the description must supply parameter meaning. It meaningfully explains engine, size, samples, transparent, denoise, view_transform, exposure, auto_exposure, meter, camera, and path, but it omits explicit guidance for file_format and defaults, leaving one gap in an otherwise strong semantic explanation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: render the scene to a file and show the picture. It distinguishes itself from render_sheet and render_view and notes the camera prerequisite, so an agent can identify its role without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says when to use alternatives: quick check pictures should use render_sheet or render_view, and this tool needs set_camera first or a passed camera. This is direct when/when-not guidance with named alternatives.

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