Review storyboards before frame generation to catch banned words, repeated compositions, position drift, and weak emotion beats. Fix findings and re-review to prevent wasted full-episode renders.
【第②道硬闸·免费】审查分镜:禁区词(会被厂商审核拒、白扣费)、镜头时长分布、相邻构图重复、同场景角色站位漂移、情绪曲线峰谷、关键镜标记。★generate_frames 之前必须先跑本工具——分镜里的问题一旦整集出图就变成整集废图,单镜修不回来。按 findings.action 用 update_shot/split_shot 修完再复审。
| Name | Required | Description | Default |
|---|---|---|---|
| episode_id | Yes |
Changes observed during successful MCP inspections.
v0.1.57Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It adds useful context: the tool is free, non-fixing (repair is delegated to update_shot/split_shot), and outputs findings with an action field. Still, it does not explicitly state read-only behavior, permissions, output shape details, or failure/error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but front-loaded: it starts with the tool's purpose, lists the check categories, highlights the critical ordering constraint, and closes with the repair/re-review loop. All sentences carry actionable information, though the punctuation and bullet-like structure make it slightly noisy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with a single integer parameter and no output schema, the description is largely complete: it states what is reviewed, when it must run, what the findings enable, and how to remediate. It could still mention whether storyboards must already exist or how findings are enumerated, but the provided workflow is sufficient for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, episode_id, is self-describing and required, but schema description coverage is 0%. The description does not mention the parameter by name or add details about where to obtain the ID or required preconditions. The 'whole episode' wording only weakly reinforces episode-level granularity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb-resource pair ('审查分镜') and enumerates concrete review dimensions: forbidden words, shot duration distribution, composition repetition, character placement drift, emotion curve, and key-shot markers. It clearly targets storyboards rather than scripts or rendered frames, but it does not explicitly differentiate itself from sibling review tools like review_script or review_frames.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit workflow trigger: 'must run this tool before generate_frames', and explains the consequence of skipping it. It also directs the agent to use findings.action and then update_shot/split_shot before re-reviewing. However, it does not state when not to use this tool or mention alternative review tools such as review_all or review_frames.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.