aicut

Render a story episode (the final file)

render_story_video

Destructive

RENDERS an AI Video Story episode into its final delivered file (stage 3 of 3), after the scene videos are done. It is composed SERVER-side from the stored episode (scenes, captions, music, title card, watermark policy); you pass only the episode id. WHEN: get_video shows succeeded or story.stage: "ready_to_render" (an episode edited in the web editor renders with those edits; a later render replaces the file). AFTER: the answer carries render_id and story.stage: "rendering". Wait with wait_for_generation or read get_video: stage: "rendered" means story.render.url is the FINAL file, and THAT is the url to give the user with one line (its length) and one clause that captions and deeper edits live in the aicut web editor. story.render.status: "failed" means it failed and was refunded: ask before rendering again. NEVER hand out the episode url before rendered: at ready_to_render it is only the raw stitched preview. A repeat during a render answers the SAME render_id with coalesced: true: not a failure. COST: per rendered minute at the platform render rate, from the episode's own duration. estimate_only: true works only once the episode is renderable (before then it refuses and names the stage); earlier, give pricing.render_tokens_per_minute (series' full list_series entry) as a rate or a tilde figure, never as the price. THE GO THIS ONE NEEDS: a render is its own charge and ask; approving the scene videos or saying the episode looks good is not a go to render. The user must name rendering or the final file, and a bare 'yes' counts only as the direct answer to your priced render ask. 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). IDEMPOTENCY: a reused idempotency_key REPLAYS the first job whatever the settings: never reuse one for a new generation (this server's instructions).

Input Schema

Name	Required	Description
`video_id`	Yes	The episode's job id from `generate_story_video`.
`estimate_only`	No	Price only; creates nothing.
`idempotency_key`	No	Retry-safety key (IDEMPOTENCY).

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 23, 2026

TDQS

A5/5.0

Behavior5/5

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

Beyond the annotations, the description discloses server-side composition, file replacement on later renders, staged return values (`render_id`, `rendering`, `rendered`, `failed`), refund behavior, coalesced repeats, cost model, token spending rules, and idempotency replay semantics. No annotation contradiction is present.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The definition is dense but front-loaded: purpose, WHEN, AFTER, COST, approval, spending, and idempotency are each labeled and ordered usefully. Given the high-stakes mutation and cost behavior, every section adds actionable guidance without filler.

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?

Even with no output schema, the description explains the key returned fields and stage transitions an agent must interpret. For a costly, destructive, open-world render tool, it covers prerequisites, outputs, failure handling, pricing, approval, and idempotency completely enough to call and interpret correctly.

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

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although schema coverage is 100%, the description adds real meaning: `video_id` is the only required input, `estimate_only` refuses before the episode is renderable and names the stage, and `idempotency_key` replays the first job regardless of settings. These are actionable semantics beyond the terse schema descriptions.

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 states a specific verb (renders), resource (AI Video Story episode), and output (final delivered file), and explicitly identifies it as stage 3 of 3 after scene videos are done. This distinguishes it from generate_story_video and other sibling tools without requiring schema inspection.

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 explicit WHEN conditions (`get_video` shows `succeeded` or `story.stage: "ready_to_render"`), what to do AFTER using `wait_for_generation` or `get_video`, and when not to hand out the URL. It also covers failure/refund handling, repeat behavior, and the exact approval needed before spending tokens.

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