Skip to main content
Glama

start_recording

Capture simulation frames to disk from the active viewport and optionally log tracked prim state, so you can review motion and scene changes after stopping.

Instructions

Start recording simulation frames to disk.

    Records the active viewport, from its camera at its own size: aim it with set_camera or look_at_prim first.
    camera_path, width and height are ignored for now (#25); the answer warns when given a camera_path, or a size
    other than 640x480.

    Captures a frame every few app updates, about 1/fps seconds, whether or not the simulation plays: play it to
    record motion. Frames are saved as PNGs in mcp_output/recordings/. Use stop_recording when done,
    then get_recording_frame to review any frame.

    Optionally tracks prim state (transforms, properties) alongside video frames.
    State is written to a grep-friendly state.txt in prim-block format.
    

Input Schema

NameRequiredDescriptionDefault
fpsNoFrames a second: 5 captures one every 0.2 s
widthNoIgnored for now: frames come at the active viewport's size (#25)
heightNoIgnored for now: frames come at the active viewport's size (#25)
camera_pathNoIgnored for now: frames come from the active viewport's camera (#25)
track_primsNoPrims whose state to record, descendants included, e.g. ["/World/G1"]
property_filterNoOnly properties whose names contain one of these, e.g. ["joint", "pos", "vel"]

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.2

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only say it is not read-only and not destructive; the description adds the substance: frames land in mcp_output/recordings/ as PNGs, capture cadence is about 1/fps in app updates, capture continues whether or not the sim plays, and prim state is written as grep-friendly state.txt in prim-block format. It also discloses that camera_path/width/height are currently inert and that a warning is emitted when supplied.

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?

Front-loaded with the core action and then organized into prerequisites, cadence/write location, cleanup path, and optional prim tracking. It repeats the "ignored for now (#25)" fact already carried in the schema and ends with a stray blank line, so it is slightly redundant but never padded.

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 zero-required-parameter start action with an output schema present, the description covers everything an agent needs: how to frame the shot, what will not work, where artifacts go, how often capture happens, and how to stop and inspect results. No return-value explanation is needed given the output schema.

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 description earns extra: it explains the real cadence behind fps (one frame every few app updates, ~1/fps seconds) and re-flags the three ignored parameters as a runtime warning rather than just a schema note. It adds little on property_filter beyond the schema's own example, which is why it stops short of 5.

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 ("Start recording simulation frames to disk") and immediately narrows scope to the active viewport at its own size. It is clearly distinguishable from capture_viewport (single shot) and from stop_recording/get_recording_frame, which it names as the follow-up steps.

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 to aim the viewport with set_camera or look_at_prim first, to play the simulation to capture motion, and to call stop_recording when done and then get_recording_frame to review. Alternatives and sequencing are named rather than inferred.

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