Skip to main content
Glama
newsbubbles

ismail: agent DAW (MCP server)

Stage Take Replay

stage_take_replay

Simulate user input by playing back a recorded take to drive virtual hands and camera movements. Observe how the page responds to gestures, grabs, and complex touch interactions during the playback.

Instructions

Replay a take as input: its head drives the page's camera and its tracked hands drive the page's hands, through the same hands.js, touch.js and grab.js a real hand goes through, so gestures, pinches, grabs and drops happen again offline (page command: replay_input, page/replay.js). The test for "he reached for the ball and took the table": replay his take and read what the page grabbed. takes= the scene the take is in (default scene); start/end trim it in the take's seconds; rate 1 for grab verdicts (grab counts use wall time); grab=True turns grab by touch on for the replay and back after; show draws the joints as small balls (left blue, right orange). Hands only: a controller take, a runtime select or a stick does not replay; the target ray is approximated from the shoulder through the palm. Refused while someone is in VR on that page: run it on a page nobody wears (a private stage, or the live one while stage_presence says nobody is in VR). wait=True waits for the take to finish and replies with what the page did, one line per event with the take's time, then what the take itself recorded (its own grab and drop marks) to compare; wait=False replies at once, and the result comes as the replay_done event. replay_input {stop: true} (stage_take_replay_stop) ends it early. Emits: replay_start, replay_done, and whatever the hands do (gesture, hand_rest, grab_counting, grabbed, grab_releasing, grab_released, grab_landed).

Input Schema

NameRequiredDescriptionDefault
endNo
grabNo
rateNo
showNo
takeYes
waitNo
sceneYes
startNo
takesNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.4.0

TDQS

A4.5/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 does so thoroughly: it discloses the replay pipeline (hands.js, touch.js, grab.js), VR refusal, hands-only restriction, target-ray approximation, grab toggling, show-joint visuals, wait semantics, emitted events, and early-stop behavior. This is unusually complete behavioral context for a complex tool.

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 description is front-loaded with the core action and is dense with useful detail, but it is a single long paragraph with many parentheticals. Minor reordering or structure could improve scanability, yet nearly every clause earns its place.

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

Completeness4/5

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

Given the tool's complexity, 9 parameters, and an output schema, the description is largely complete: it covers restrictions, event emissions, wait behavior, and stopping. The remaining gap is the light treatment of required parameters 'take' and 'scene', which could leave an agent uncertain about exact identifier semantics.

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

Parameters3/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 explain all 9 parameters. It covers start/end trimming, rate for grab verdicts, grab toggling, show joint rendering, and wait behavior, but the required 'take' and 'scene' parameters are only obliquely addressed, and the 'takes' line ('the scene the take is in') is ambiguous rather than clarifying.

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?

The description uses a precise verb ('Replay') and resource ('a take as input'), then immediately explains its effect on camera and hands. It distinguishes itself from siblings like stage_take_replay_stop and stage_take_start by focusing on offline input replay and naming the page pipeline it drives.

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?

It gives a concrete use case ('The test for "he reached for the ball and took the table"') and explicit exclusions ('Hands only: a controller take, a runtime select or a stick does not replay'). It also tells the agent to run on a page nobody wears when VR is active and points to stage_take_replay_stop for early termination.

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

Deploy Server

Other Tools