Skip to main content
Glama

capture_sweep

Capture many viewport shots in one job, each with its own camera pose, lens, variant selections and timeline time, to inspect a scene's looks from many viewpoints at once.

Instructions

Capture many shots in one call, each with its own camera pose, lens, variant selections and timeline time, as a job: for checking a scene's looks and switches from many viewpoints, where one capture_viewport a picture costs a turn each. Answers the job's id and folder at once.

A shot is a position with yaw and pitch (yaw about the up axis, 0 along +X; pitch -90 looks straight down), a position with a target, or camera_path, a camera of the stage rendered as it is. Its lens is focal_length and the apertures in mm, the vertical one fitted to the image when left out; one that doesn't fit the image's shape is refused. selections switch variant sets for the shot alone, in the session layer, which no save writes; time sets the timeline. Every shot is checked before anything changes.

Kit writes each shot's PNG and a manifest.json, each shot's pose, lens, selections, time and file, into mcp_output/sweeps//. Read it with get_job(id, wait=100): shot 37 of 400 as it goes, then one line naming the folder and the shots that came out black or failed. A sweep's manifest.json given as shots_file takes the same shots again, given the first sweep's width and height, on this scene after a change or on another built from the same spec. Afterwards every layer, the timeline and the selections are as they were, after cancel_job too, which keeps the shots taken. A time repeats time-sampled animation; Replicator's walking agents move on each update whatever the time, so stop the timeline (sim_control) for shots of them that repeat. One size for all the shots; one job runs at a time.

Input Schema

NameRequiredDescriptionDefault
nameNoThe sweep's folder in mcp_output/sweeps/: letters, digits, '.', '_', '-' and spaces; the time when empty. A folder that holds a sweep already is refused
shotsNoThe shots, in order, up to 2,000; give this or shots_file
widthNoEvery picture's width in pixels, up to 4096
heightNoEvery picture's height in pixels, up to 4096
shots_fileNoA JSON file on this server's machine holding a list of shots, or a sweep's manifest.json to take its shots again; give this or shots

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.4.1

TDQS

A4.5/5.0
Behavior4/5

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

Annotations only say readOnlyHint=false, destructiveHint=false, openWorldHint=false; the description goes well beyond by disclosing that selections are applied in the session layer 'which no save writes', that all state is restored afterwards including after cancel_job, that every shot is validated before anything changes, and that an existing sweep folder is refused. Strong disclosure for a mutation tool, though it never states the permissions or time/cost expectations of a long multi-shot job.

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?

It is front-loaded with the core action, but several sentences are spliced run-ons ('Its lens is focal_length and the apertures in mm, the vertical one fitted...') and the paragraph has stray line breaks that hurt scanability. Nearly every sentence carries unique information, so the length is justified by tool complexity, but the packaging could be tighter.

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 2,000-shot batch job tool, the description covers output location (mcp_output/sweeps/<name>/ with PNGs and manifest.json), how to monitor via get_job(id, wait=100), what failure looks like, state restoration semantics, and reuse of the manifest. With an output schema present, nothing an agent needs to invoke this correctly is missing.

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 100%, so the baseline is 3, but the prose adds real meaning: vertical_aperture is fitted to the image shape and refused when it doesn't fit, a manifest.json passed as shots_file re-takes shots and needs the first sweep's width and height, and shots/shots_file are mutually exclusive with a 2,000 ceiling on shots. These are behavioral constraints the schema alone does not convey.

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 and resource ('Capture many shots in one call, each with its own camera pose, lens, variant selections and timeline time, as a job') and explicitly contrasts itself with the sibling capture_viewport ('where one capture_viewport picture costs a turn each'). An agent can distinguish it from both capture_viewport and get_job without inspecting schemas.

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?

Gives conditions for use (checking a scene's looks and switches from many viewpoints), names the alternative it replaces, explains the shots_file reuse path across scenes and after changes, and states operational constraints ('one job runs at a time') plus the interaction with cancel_job and sim_control for repeating agents. That is explicit when-to-use plus real exclusions and follow-ups.

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