Skip to main content
Glama

generate_scene

Build a location precisely from a scene-layout/v2 map and generate its plate.

This is the "exact location building" path: instead of describing the room in prose
(which the model reinterprets — furniture drifts, depths change between shots), it
renders a control image from the map's boxes (each object a colored block at its true
position/size/depth, plus a 1-meter floor grid in true perspective), then asks the
generator to REPLACE each block with its real object in the same camera — so the plate
follows the geometry pixel-wise. Same room from another camera_id is the same space.

scene_layout: a scene-layout/v2 dict — {format, units, room{w,d,h}, objects{...boxes},
  cameras{<id>:{pos,look_at,fov_deg,framing?}}, ...}. The camera must carry fov_deg.
camera_id: which camera in scene_layout.cameras to render from.
aspect: PORTRAIT (9:16), LANDSCAPE (16:9), SQUARE, PORTRAIT_THREE_FOUR (3:4) or
  LANDSCAPE_FOUR_THREE (4:3). 9:16 and 16:9 from one camera share the vertical FOV, so
  depths are identical across aspects.
style / extra: prepended / appended prose (art style, mood) — geometry comes from the map.

A box may carry `rot: [rx, ry, rz]` (degrees around the world X/Y/Z axes) and `pivot:
[x, y, z]`, applied as p' = Rx·Ry·Rz·(p − pivot) + pivot, pivot defaulting to the box
centre. That is how a POSE is expressed — a raised arm is a box rotated about the
shoulder. Measured live 2026-08-09: moving a hand by 2–20 cm is ignored by the
generator, rotating the arm by 15–60° comes through. Build motion out of angles.

seed / image_inputs: same meaning as in generate_image. For a SEQUENCE of frames of one
character, generate a reference frame first, then pass its mediaId as image_inputs on
every following frame — that is what keeps the face, clothes and colours identical.
A fixed seed alone does not: it only repeats an unchanged control image.

depth: render the guide as a plain greyscale depth map instead of the colour hybrid
  (for an external depth-ControlNet). calibration: add frame markers, a back-wall grid
  and a 2 m ruler with 10 cm ticks — measured to cut the framing drift roughly fourfold.
background: "dark" (default, unchanged) or "light". Use "light" when the plate must be
  on a white background: the generator sometimes copies the guide's own palette into the
  result, and a light guide makes that leak land as white rather than as a dark grid.

control_png: return the layout guide itself, base64-encoded. OFF by default because it is
  hundreds of thousands of characters of TEXT — one guide can cost more context than the
  whole conversation around it. `control_png_kb` always reports its size.

Returns {"urls", "media_ids", "legend", "control_png_kb"} — legend maps block colors to
objects. Add control_png=True to also get the guide itself for inspection/acceptance.

Input Schema

NameRequiredDescriptionDefault
seedNo
depthNo
extraNo
styleNoIn the style of Pixar-like 3D cartoon animation, clean rounded shapes, soft even lighting from the left, muted natural palette.
aspectNoLANDSCAPE
camera_idYes
backgroundNodark
project_idNo
calibrationNo
control_pngNo
image_inputsNo
scene_layoutYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations are thin (only readOnlyHint=false, idempotentHint=false, openWorldHint=true, destructiveHint=false), so the description carries the burden and does so richly: control_png's context cost in characters, palette leakage from the guide ('light' background workaround), calibration cutting framing drift ~4x, measured sensitivity (2-20cm translations ignored, 15-60° rotations honored), and the caveat that a fixed seed only repeats an unchanged control image.

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?

Long but front-loaded and information-dense — the core mechanism comes first, then per-parameter semantics. Nearly every sentence contributes a non-obvious fact (rotation-as-pose, depth-ControlNet use, legend in the return), though a few parentheticals run longer than needed.

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?

No output schema exists, but the description documents the return shape ('urls', 'media_ids', 'legend', 'control_png_kb') and explains what legend maps. Combined with the nested scene_layout structure and the control_png cost warning, an agent has everything needed to invoke it correctly.

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 coverage is 0%, so the description must compensate, and it largely does: it documents the scene_layout shape, camera_id, the full aspect value list absent from the schema, style/extra placement, seed/image_inputs, depth, calibration, background, and control_png. Only project_id is left undocumented, a small gap against a 12-parameter tool.

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?

Opens with a specific verb+resource ('Build a location... and generate its plate') and immediately identifies the mechanism: rendering a control image from a scene-layout/v2 map. It explicitly distinguishes itself from the prose-driven sibling path ('instead of describing the room in prose'), so an agent can separate it from generate_image without opening either 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?

Names when to use this path (geometry must be pixel-exact, same room across shots) and when the prose path fails (furniture drifts, depths change). It also gives routing rules for adjacent parameters: sequence frames should pass a reference frame's mediaId in image_inputs, and seed is explicitly called out as insufficient for identity.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.