aicut

Change what happens in one scene (and redraw it)

change_story_scene

Destructive

CHANGES WHAT HAPPENS IN ONE SCENE of an episode parked at frames review and redraws its opening picture from the change. You pass a PLAIN SENTENCE ('the kid should look super sad', 'move it outside at night'); aicut rewrites that scene's setting / people / action text from it and draws the new picture: ONE image generation. The change STICKS (the scene video made at fire uses it). It is the tool for 'change scene 2, X should be Y'; regenerate_story_frame draws the SAME scene again from the SAME text. CAN: change the SETTING, the ACTION and WHO IS IN FRAME. CANNOT: the SPOKEN LINES, the scene's LENGTH, or a scene pinned to a reference still (the web editor's). An ask ONLY about what somebody SAYS is REFUSED, 400 dialogue_only, nothing written or charged (an estimate_only refuses it too): say dialogue is edited in the web editor and offer a visible change. A MIXED ask applies the VISIBLE half only and the response says so: relay it, never let the user believe the line changed. You never write scene text: pass the user's words as one sentence and do not read the rewrite back. WHEN: story.stage is frames_review; scene_index is zero-based in story.frames (users count from ONE); each frame's summary and dialogue are what you check the ask against before you spend. AFTER: returns image_id (status generating), changed (which parts moved) and a report: RELAY THE report AS WRITTEN. An empty changed means NOTHING moved, whatever the new image_id suggests. This call opens its own card with the scene marked as redrawing: no show_generation, no narrating the wait. CHECK attached: false means the image is charged but will NOT replace the frame at fire: say so and redraw before firing. IF THE PICTURE FAILS OR THE ACCOUNT RUNS OUT (402) THE SCENE HAS ALREADY CHANGED (changed_text: true): it has the new beat and its old picture; regenerate_story_frame draws the new one, and you must NOT send this again (a second rewrite and picture). changed_text_unknown: true means aicut DOES NOT KNOW whether the scene changed, and neither do you: not a success, never re-send at once (it would apply twice): say it could not be confirmed, read that scene's summary in get_video, and send again only if it lacks the change. COST: one standard image at the series' RESOLVED start-frame model, the same as regenerate_story_frame (pricing.frame_regen_tokens). estimate_only: true spends nothing and changes NOTHING: pass the real change with it so a refusal (dialogue_only, a reference-built scene) comes back BEFORE you ask for a spend (best-effort; it can answer 429 utility_rate_limited). THE GO THIS ONE NEEDS: one change, one named scene, one priced ask: a complaint ('scene 3 is wrong') is a reason to ASK what should change and OFFER this with its price, never a go. Never change more scenes than named. Changing a scene is not firing. 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: idempotency_key keys the PICTURE only: a reused key replays that picture, but the scene's text is rewritten again on every call, so after an unknown outcome check get_video first (see above) instead of resending.

Input Schema

Name	Required	Description
`change`	Yes	What should be different, as ONE plain sentence in the user's own words ('the kid should look super sad'). It must be VISIBLE (setting, action, who is in frame): a sentence only about what somebody SAYS is refused (`dialogue_only`). At most 600 characters.
`video_id`	Yes	The episode's job id from `generate_story_video`.
`scene_index`	Yes	The zero-based scene index exactly as `get_video`'s `story.frames` lists it (users count from ONE: 'change scene 2' is the SECOND frame).
`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

A4.8/5.0

Behavior5/5

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

The annotations already mark this as a destructive, non-read-only, non-idempotent operation, and the description adds substantial operational context beyond that. It discloses that the scene text changes even if image generation fails, that `changed_text: true` means the beat changed with only the old picture, that `changed_text_unknown: true` must not be resent immediately, and that `attached: false` means the image is charged but will not replace the frame at fire.

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 long, but the complexity of the tool and its failure modes justify much of the length. It is front-loaded with purpose and restrictions, then organized into WHEN, AFTER, COST, GO, and IDEMPOTENCY sections; the all-caps emphasis is dense but most sentences carry operational value.

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?

Although there is no output schema, the description covers the returned `image_id`, `changed`, `report`, and `attached` fields, plus the critical `changed_text: true` and `changed_text_unknown: true` outcomes. It also covers cost behavior, refusal behavior, the frames-review prerequisite, and retry safety, leaving little an agent needs to infer before calling it.

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 description coverage is 100%, so the baseline would be 3, but the description adds meaningful interaction semantics beyond the schema. It clarifies that `change` must be visible rather than dialogue-only, that `scene_index` is zero-based against `story.frames` while users count from one, that `estimate_only` is best-effort and may return `utility_rate_limited`, and that `idempotency_key` keys only the picture while text is rewritten on every call.

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 and resource: it changes what happens in one scene and redraws that scene's opening picture. It explicitly distinguishes the tool from `regenerate_story_frame`, which redraws the same scene from the same text, so an agent can route correctly without opening another schema.

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-to-use conditions (`story.stage` is `frames_review`, one named scene, one priced ask) and names the alternative for same-text redraws. It also spells out refusal and mixed-ask cases: dialogue-only asks return `dialogue_only`, while mixed asks apply only the visible half and must be relayed accurately.

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