Recommends in/out trim windows for shots with declared duration shorter than real footage, using activity detection to avoid cutting mid-action. Free; group shots return applicable=false.
裁剪窗口动作QC:对「声明时长<真实视频时长」的独立生成镜,按片内活动检测推荐 in/out 裁剪窗口——供应商产片动作常在后半段,默认从 0 秒裁会截在半动作态(如抬手没打下去)。免费零扣费。组模式镜不适用(组切分已内容感知,返回 applicable=false)。拿到推荐后用 trim_shot 应用。
| Name | Required | Description | Default |
|---|---|---|---|
| storyboard_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 discloses that this is a zero-cost recommendation action, that it detects activity within the shot, and that group-mode shots return applicable=false. It does not fully spell out the positive return payload, but the main behavioral traits are clearly transparent.
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 and well-organized: target condition, rationale, billing/caveat, and next step. Every clause earns its place, and no filler or repetition exists.
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 single-parameter recommendation tool with no annotations and no output schema, the description covers the target condition, the exclusion case, the reasoning behind the default-trim problem, and the downstream tool. It could be more explicit about the exact positive return field names for the in/out window, but core usage is complete.
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 schema has a single required integer storyboard_id with no property-level description, and the tool description never explicitly maps storyboard_id to the shot being QC'd. However, the parameter name is self-explanatory and the surrounding text makes it reasonably clear that the ID refers to the independently generated shot under review, so the gap is minor.
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 states a specific action—recommend in/out trim windows—for a precisely scoped target: independently generated shots whose declared duration is less than the real video duration. It also distinguishes itself from the sibling trim_shot by framing this as a QC/recommendation stage, and explicitly excludes group-mode shots.
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?
It gives an explicit when-to-use condition (duration mismatch, independent generated shots), an explicit exclusion (group-mode shots return applicable=false and why), and a direct routing instruction to apply the result with trim_shot. An agent can decide between this tool and its siblings immediately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.