Skip to main content
Glama
starreel

StarReel MCP

by starreel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

generate_frames

Batch-generate missing storyboard frames for an episode after review and quote approval; supply review_token and quote_id to launch async generation.

Instructions

确认后批量出帧:后台异步。用 get_storyboards 轮询,first_frame_image/last_frame_image 逐镜填充即完成。★图片生成较慢——每张几十秒到数分钟(尤其高清模型),整集可能十几分钟。轮询看 frame_status:pending=还在生成(继续耐心等,别当失败、别重复调 generate_frames,重复触发=白花钱)、ready=完成、failed=才是真失败。别因为「等了一会儿还没出」就判定生成失败或重试。出视频前必须先出帧,否则视频会退化成无一致性锚点的画面。frame_type 要与 quote_frames 用的一致(默认 first_frame)。★这是批量补缺帧:只给「缺该帧」的镜出图,已有首帧的镜会跳过——这是正常设计、不是"系统拒绝重出"。要重出/重画某一镜已有的帧(如换了定妆图要让新图生效),用 generate_shot_frame(单镜重生,平台带身份锚),不是这个工具、更不是自制图 upload_shot_frame。★尾帧能批量出:frame_type=last_frame 会给「已有首帧且缺尾帧」的镜批量补尾帧(尾帧只在想固定某镜结尾画面/大运镜时才需,常规只出首帧)。★响应里的 frames_planned 是计划数,不是已成功数——本接口在后台派发循环开跑之前就返回了。真实进度只看 get_storyboards 的 first_frame_image / get_jobs 的逐条生成记录;余额不足(402)会中止整批,此时轮询再久也不会有结果,应去查余额而不是继续等。 ★【分镜审查硬闸·免费】本步前必须先调 review_storyboards:把返回的 findings 逐条原样告诉客户(每条带 code=问题类型、shots=命中镜号、action=该调哪个工具修),再把 review_token 传进本工具。未审查会被 400 拒。审查后又改了内容 → token 自动失效,复审一次即可(仍免费)。有 error 时默认拦截;客户知情并坚持照现状继续,才带 acknowledge_review:true——带病推进大概率产出废片且照常扣费,不要替客户做这个决定。⚠️ 批量报价确认流程:先调对应的 quote_* 工具,把返回的 estimated_points 原样告诉用户,用户明确同意后,才用返回的 quote_id 调本工具。不要擅自确认。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
quote_idYes来自 quote_frames
episode_idYes
frame_typeNo默认 first_frame,须与报价时一致
image_modelNo临时覆盖本次出图模型(不传=用 drama 级设定,默认香蕉2)。可选:gemini-3.1-flash-image(Nano Banana 2·默认·71点)/gemini-3-pro-image(Nano Banana Pro·更精细·175点)/gemini-3.1-flash-lite-image(Nano Banana 2 Lite·便宜·31点)/doubao-seedream-5-0-260128(Seedream 5.0)/gpt-image-2(ChatGPT Image 2)
review_tokenNo★来自本层 review_* 工具的凭据(受闸项目必填;缺了会 400 并告诉你该调哪个审查工具)
acknowledge_reviewNo审查有 error 时,客户已知情并明确要求照现状继续才传 true(默认拦截)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.57

TDQS

A5/5.0
Behavior5/5

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

No annotations are provided, so the description carries the full burden, and it delivers: async background dispatch, frames_planned is a planned count not a success count, pending/ready/failed status semantics, slow generation, 402 failure mode, review_token invalidation, and skip-existing behavior. There is no annotation contradiction.

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 description is long, but every section carries operational value, and it is front-loaded with the core async batch behavior before warnings and prerequisites. Bold text and bullets make the dense content scannable rather than a wall of text.

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?

Despite lacking an output schema, the description explains the key response field (frames_planned), how to determine real completion via get_storyboards/get_jobs, failure causes, required preceding steps, and sibling alternatives. Nothing essential for correctly invoking the tool is missing.

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?

Schema coverage is high, but the description adds critical semantics beyond the schema: frame_type must match the quote and controls which shots get filled, review_token is a mandatory credential from review_storyboards, and acknowledge_review is for informed override only. This materially reduces misuse risk for the trickiest parameters.

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: batch-generate frames asynchronously after confirmation. Clearly distinguishes itself from generate_shot_frame (single-frame regeneration) and upload_shot_frame, so sibling differentiation is explicit.

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?

Gives explicit when-to-use and when-not-to-use guidance: use for missing frames only, existing frames are skipped by design, and re-generating an existing frame requires generate_shot_frame. Also mandates the quote_* confirmation flow, the review_storyboards prerequisite, and polling via get_storyboards instead of retrying.

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

Deploy Server

Other Tools