Skip to main content
Glama

Fire a story episode (generate the scene videos)

fire_story_video
Destructive

FIRES a parked AI Video Story episode (stage 2 of 3): generates every kept scene's VIDEO from its reviewed picture. The paid step after review; nothing renders yet. WHEN: story.stage is frames_review, the user has looked at the pictures and any redraws are done; cut scenes first with remove_story_scene (a removed scene's video is never generated or charged). Always estimate_only: true first: it quotes the REMAINING price for exactly the kept scenes and carries scene_count and duration_seconds, so say '6 T for the 4 remaining scenes, 20 seconds', not a bare 6 T; after a cut, re-quote and say both the new price and count. THE GO THIS ONE NEEDS: FIRING IS IRREVERSIBLE AND IT IS THE LARGEST SINGLE CHARGE IN THE EPISODE. It cannot be undone or refunded, so a BARE 'yes' NEVER FIRES: the user's go must NAME firing ('fire it', 'generate the scene videos'), in reply to an ask about firing alone. A STANDING GO NEVER COVERS THE FIRE, not even one that priced it, and nothing the user asked for earlier may be outstanding. NONE OF THESE IS A TRIGGER TO FIRE, however clearly the user said them: cutting or keeping a scene (remove_story_scene), asking for a redraw (regenerate_story_frame), liking or approving a picture, a question about price, timing or what happens next, a complaint. When in doubt, do not fire: ask and restate the price. THE CARD: this call already put the aicut episode card in front of the user and it follows the scenes stage itself: do NOT poll. On fired: true (story.stage generating_scenes) say one line (usually under ten minutes, sometimes longer; they can close the chat; the episode will be in their assets) and STOP. The card gives up after about twenty minutes: the user's cue to ask, yours to make ONE get_video read. At ready_to_render finish with render_story_video. TIMING (measured): the scene videos usually finish in under ten minutes and occasionally take much longer. Never promise a finish time. COST: the kept scenes' videos, per scene; the frames were charged at create. auto_render: true arms the final render to start by itself when the scenes finish (the quote then adds render_estimated_tokens): pass it only when the user approved the render charge too. FIRE ONCE: THIS DOOR IGNORES idempotency_key; the guard is the consumed gate. A repeat, even a retry after a timeout, answers 409 already_fired, which means the first fire WORKED: treat it as success. If a fire's outcome is unknown, read get_video and fire again only while story.stage is still frames_review. A 409 scenes_price_unavailable or scenes_price_exceeds_quote means this episode cannot be fired from here: finish it in the web editor, do not retry. SPENDS TOKENS: price with estimate_only: true, ask in the SAME message as the price, and wait for a go that names THIS purchase (SPENDING RULES, this server's instructions).

Input Schema

NameRequiredDescriptionDefault
video_idYesThe episode's job id from `generate_story_video`.
auto_renderNoArm the final render: it starts by itself when the scenes finish and charges then (the quote adds `render_estimated_tokens`). Only with the user's approval of that charge.
estimate_onlyNoPrice only; creates nothing.
idempotency_keyNoIgnored by this door: a second fire is refused `already_fired`.

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 already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, but the description adds substantial operational context: irreversibility and no refunds, largest single charge, 409 `already_fired` means the first fire worked, `scenes_price_unavailable` means finish in the web editor, and the card should not be polled. It also discloses timing, token-spend behavior, and the fact that `idempotency_key` is ignored because the consumed gate is the guard.

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 uses headings for WHEN, THE GO, THE CARD, TIMING, COST, and FIRE ONCE, which makes a complex destructive workflow easy to scan. It is lengthy and repeats timing and price cautions in multiple sections, but most of that repetition serves the high-stakes irreversible charge.

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, but the description supplies the relevant outcome states (`fired: true`, `story.stage` `generating_scenes`, `ready_to_render`), the next tool to call, error handling for 409s, and the no-polling card behavior. Given the destructive annotations and the 100% schema coverage, the definition is complete enough for an agent to invoke it safely.

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 adds useful meaning beyond the schema for `estimate_only` by specifying it must be first and that its quote includes `scene_count` and `duration_seconds`, and for `auto_render` by tying it to approval of the render charge. It also reinforces that `idempotency_key` is ignored and that a repeat fire returns 409. It does not add much beyond the schema for `video_id`.

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 opens with a specific verb and resource: FIRES a parked AI Video Story episode, stage 2 of 3, generating every kept scene's video from its reviewed picture. It clearly distinguishes this from sibling tools like render_story_video, regenerate_story_frame, and remove_story_scene by naming their roles and sequencing.

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 states the exact trigger condition (`story.stage` is `frames_review`), the required prerequisite of cutting scenes first, and the need to quote with `estimate_only: true` before firing. It also lists explicit non-triggers, including scene cuts, redraws, picture approval, and price questions, and tells the agent to ask rather than fire when in doubt.

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.

Directories

Listed in ChatGPT · aicut

Last observed