Skip to main content
Glama

Create an AI Video Story episode (frames stage)

generate_story_video
Destructive

Starts an AI Video Story EPISODE (stage 1 of 3): the engine writes the multi-scene episode from your idea, draws the OPENING PICTURE OF EVERY SCENE, and PARKS for the user to look at them before any video generates. Returns immediately. Say 'the opening picture of each scene' to the user, never 'start frames' or 'frames review' (field names). WHEN: the series is picked and its FULL entry fetched (list_series WITH series_id and video_model: the ladder and prices are only there), the idea is settled, and for a cast.required series the cast is drafted, its portraits bought and the user has said go to them. The whole flow: get_recipe story-episode. INPUT: ONE idea (a short paragraph) plus options; never scenes, dialogue or image prompts (a scenes field is refused). A member whose portrait is still generating is refused 409. Use the series' defaults unless the user names a model. THE CARD: this call already put the aicut frames card in front of the user; it follows the episode through writing and pictures itself. Say one short line (what was ordered, and that the opening picture of each scene will appear for them to look at, in plain words) and STOP: no wait_for_generation, no get_video loop while it walks. The card stops updating at the review, so after a redraw read get_video until that lane's regenerate is terminal, then show_generation with the episode id puts a fresh grid up. No card (a terminal)? Poll get_video until story.stage is frames_review and give the user the frame urls. AFTER: story.stage moves starting, generating_frames, frames_review and STAYS there until fired: the next move is the user's. writing_failed is terminal, nothing charged, cast saved: call again with the same idea and cast_member_ids. IF EVERY FRAME FAILED it parks with no usable picture: regenerate_story_frame is the way out; do not offer delete_video, which throws away pictures ALREADY PAID FOR (story-episode recipe, step 6). COST: this charges the FRAMES stage now and refuses an account that could not afford the whole episode. Quote the chosen rung from the FULL entry: frames_tokens now, videos_tokens at fire (charged only then), total_tokens. TILDE a figure whose videos_estimated or frames_estimated is true (a SEPARATE question from exact: even when exact is true), and tilde the TOTAL whenever EITHER is. If a rung is not exact, or you pass a start_frame_model other than the default, quote estimate_only: it and the paid 201 carry the same markers (frames_estimated, videos_estimated, scene_count_estimated), reported with the same tildes. cast_member_ids_missing: true on an estimate means the request would be REFUSED: do not ask for a go on it. SIZING: ask only LENGTH in seconds (30 is the default), never a scene count; offer lengths from pricing.video_models[].durations.options (only on the series_id call of list_series) and pass the chosen seconds as duration_seconds; never compute a rung. Never state a scene count as fact: it is only what a rung derives and the writer decides; do not volunteer it. OFFER THE IMAGE MODEL ONCE, in a line you are already writing (not an interview): name the model that draws the pictures in plain words with its default and price; no preference means the series' default. 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

NameRequiredDescriptionDefault
ideaYesThe episode idea: one short paragraph of plain prose, no scene lists, shot directions or image prompts.
languageNoOmit unless the user asked for another language: the series' `defaults.language` is used.
series_idYesThe series id, exactly as `list_series` returns it.
video_modelYesOne of the series' `pricing.video_models` ids: its `defaults.video_model` unless the user names one. It decides which duration ladder applies, so pick it before the length.
aspect_ratioNo`9:16` (default) or `16:9`.
estimate_onlyNoPrice only; creates nothing.
cast_member_idsNoApproved cast member ids from `generate_cast_portraits` (or `list_characters`, kind `cast_member`), in roster order. Required when `cast.required`, forbidden when `cast.writer_owned`.
idempotency_keyNoRetry-safety key (IDEMPOTENCY).
duration_secondsYesEpisode length in SECONDS: one of the chosen model's published `durations.options[].seconds` on the series' FULL `list_series` entry (`durations.default_seconds` if the user has no preference). Never a scene count; an unpublished value is refused.
start_frame_modelNoImage model for the opening pictures (`pricing.start_frame_models`). Omit for the series' `defaults.start_frame_model`, which `frames_tokens` is priced at; any other needs a fresh `estimate_only`.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only mark it write/destructive/non-idempotent; the description adds the genuinely behavioral facts an agent could not infer: the call returns immediately and parks, it charges the frames stage now and refuses an account that cannot afford the whole episode, a generating portrait yields 409, writing_failed is terminal and unchained, and a reused idempotency_key replays the first job regardless of settings. It also spells out the after-states (starting, generating_frames, frames_review) and both card and no-card paths. No conflict with the annotations: destructiveHint aligns with the token spend, and idempotentHint=false aligns with the replay warning.

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 purpose is front-loaded in sentence one, but the body is roughly 450 words of ALL-CAPS labels, parentheticals and cross-references that are hard to scan. Some material restates global server rules (the SPENDING RULES and IDEMPOTENCY reminders are explicitly flagged as already being in this server's instructions), which dilutes the tool-specific content.

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?

For a multi-stage, token-spending, card-mediated tool with 10 parameters and no output schema, almost every operational question is answered: cost quoting and tilde rules, sizing guidance, image-model offer, idempotency, failure and recovery paths, and what happens on both the card and terminal-response variants.

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 real meaning: `scenes` is refused so the idea must be plain prose, `duration_seconds` is a length in seconds drawn from the model's published durations and never a scene count, a non-default `start_frame_model` requires a fresh estimate_only, and `cast_member_ids` is required vs forbidden depending on cast mode. These are cross-parameter constraints beyond the per-field schema text.

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 plus exact scope: 'Starts an AI Video Story EPISODE (stage 1 of 3)' that writes the episode, draws the opening picture of every scene, and parks for review. The 'stage 1 of 3' framing plus 'before any video generates' cleanly separates it from fire_story_video and render_story_video without the agent opening any 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?

The WHEN block names concrete preconditions (series picked and FULL entry fetched via list_series with series_id and video_model, idea settled, cast drafted and portraits bought for a cast.required series, user go-ahead) and points to the get_recipe story-episode flow. It also names the explicit alternatives: regenerate_story_frame when every frame failed, and 'do not offer delete_video', with the reason.

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