aicut

Wait for a generation to finish

wait_for_generation

Read-onlyIdempotent

Waits up to 15 seconds for an aicut generation to reach a terminal state, WITHOUT opening a card, and returns the compact status. SEVERAL ITEMS: quote each, ask once with the total, start them all (images with wait: false, distinct idempotency_keys or none), then make ONE call with ids (1 to 6 of {id, media}) instead of id and media. terminal is always present: true means nothing further arrives on its own (the job is succeeded or failed, or awaiting_user is set); false means it is still queued or processing. WHEN: right after generate_video, generate_image, generate_audio or a transform, and again AT ONCE every time it answers terminal: false (same id and media): it blocks up to 15 seconds itself, so you never sleep or set a timer. Do NOT call it after generate_story_video or fire_story_video (the card follows those); wait only after render_story_video. Do not switch to get_* or narrate each attempt: several calls in a row is the expected shape. STALL: no terminal: true after about 10 minutes, tell the user so and make ONE get_* read of that job. On terminal: true say ONE short line about what came out and stop (the card is up: do NOT call show_generation); on failed, tell the user what went wrong (error.message). No card on your client (a terminal)? Give the user the url. WITH ids it returns when ALL are terminal or the 15 seconds end: results (each job in order, with its own terminal, awaiting_user and next_step; an id not on this account gets its own error and never fails the rest), all_terminal (your loop condition) and, while false, poll_after_seconds. Next call: only the jobs still terminal: false. A STORY EPISODE PARKED FOR THE USER (story.stage frames_review or ready_to_render) answers terminal: true with awaiting_user: true: stop waiting, say what is ready and let them decide (a redraw, a fire and a render each need their own priced go). THE ONE EXCEPTION: ready_to_render with story.auto_render: true is NOT a decision (the fire armed the render, which starts by itself): it answers terminal: false, so keep waiting on that render, and if it has not started after a few minutes tell the user and offer render_story_video. A render ends at story.stage: "rendered" (story.render.url is the final file) or, if it failed and was refunded, awaiting_user: true. At ready_to_render the url is only the raw scene preview. Spends no tokens and creates nothing. It returns JSON for you to read: say nothing to the user between waits and never paste it.

Input Schema

Name	Required	Description
`id`	No	A job id from a `generate_*` tool or transform, or an episode id from `generate_story_video` (media `video`).
`ids`	No	Several jobs at once (see SEVERAL ITEMS), instead of `id` and `media`.
`media`	No	Which kind of generation the id belongs to: `video` (a `generate_video` job, any video transform: `upscale_video`, `extend_video`, `edit_video`, `motion_control`, `generate_lipsync`, and a story render; an AI Video Story episode is a `video`), `image` (including `upscale_image`) or `audio`.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 23, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the burden is lighter, yet the description adds substantial context beyond them: it blocks up to 15 seconds itself (no timer needed), spends no tokens, creates nothing, handles the 10-minute stall case, and defines what terminal:true means per story stage. This is richer than any annotation could convey.

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?

The critical facts (15-second block, no card, compact status, terminal semantics) are front-loaded, but the body is a dense wall of run-on sentences with heavy parenthetical tangents and caps-lock emphasis. Most content is genuinely load-bearing for a complex polling tool, but the structure makes it hard to scan rather than the content being wasteful.

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?

There is no output schema, so the description must define return values, and it does thoroughly: `terminal`, `awaiting_user`, `next_step`, `results`, `all_terminal`, `poll_after_seconds`, `error.message`, `story.stage` and `story.render.url`. It also covers the story-episode exception cases, leaving no gap for an agent polling a job.

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; the description rises above that by explaining the mutual exclusivity and workflow of `ids` versus `id`/`media` ('make ONE call with `ids` (1 to 6 of `{id, media}`) instead of `id` and `media`') and the 'only the jobs still terminal:false' iteration rule. It doesn't add format/syntax detail for the id string itself, keeping it just under 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 with scope: 'Waits up to 15 seconds for an aicut generation to reach a terminal state, WITHOUT opening a card, and returns the compact status.' This instantly separates it from get_* (which reads) and show_generation (which opens a card).

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?

Explicit WHEN section ('right after generate_video, generate_image... and again AT ONCE every time it answers terminal: false'), explicit exclusions ('Do NOT call it after generate_story_video or fire_story_video'), and explicit anti-patterns ('Do not switch to get_* or narrate each attempt'). Nothing is left to inference.

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

All aicut tools Inspect

Try in Browser