Split a storyboard shot into two distinct shots using its first and last frames as boundaries, enabling precise structural edits in short-drama production.
把某镜按首尾帧拆成两镜(结构操作)。免费。
| 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 provided, the description carries the behavioral burden. It discloses the core behavior (splitting a shot into two by first/last frames) and notes it is a structural operation and free. However, it does not mention side effects, reversibility, or the fate of the original shot, which is meaningful for a mutation-like operation.
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 extremely concise, front-loads the operation and object, and includes only relevant extra context ('free'). No words are wasted and nothing redundantly repeats the schema.
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?
The tool is simple with one parameter, and the description covers the action and object. However, there is no output schema and no mention of return values, whether the operation is reversible, or how the result relates to the original shot, leaving some completeness gaps.
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 one required parameter, storyboard_id, with no description coverage, so the description must compensate. It does so by identifying the target as a shot ('某镜'), making it clear that storyboard_id is the shot to split. The single-parameter design keeps ambiguity low.
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 verb and resource: splitting a shot into two shots based on first and last frames, and characterizes it as a structural operation. This clearly differentiates it from trimming or detecting cuts among the sibling tools.
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 implies when to use the tool: whenever a shot needs to be split into two at its endpoints. However, it does not explicitly position itself against related siblings like trim_shot, update_shot, or scan_intra_shot_cuts, nor does it state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.