Trim a specific shot's duration within a storyboard by setting in_ms and out_ms. After trimming, use rerender_episode to re-render the final video.
裁剪某镜时长(in_ms/out_ms)。免费;返回后需 rerender_episode 重拼成片。
| Name | Required | Description | Default |
|---|---|---|---|
| in_ms | No | ||
| out_ms | No | ||
| storyboard_id | Yes |
Changes observed during successful MCP inspections.
v0.1.57Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral burden. It does disclose useful non-obvious behavior: the operation is free and requires a subsequent rerender_episode call. However, it does not state whether the trim mutates the original shot, what the return value is, or how in_ms/out_ms affect the media, leaving the behavioral profile incomplete.
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?
Two short sentences, with the action front-loaded and the cost plus required follow-up stated immediately. Every sentence earns its place, and there is no redundant restating of schema fields.
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 mutating tool with no annotations, no output schema, and zero schema parameter descriptions, essential invocation context is missing: exact parameter semantics, return behavior, prerequisites, and when to choose this over split_shot or update_shot. The rerender_episode instruction is valuable but not enough to make the definition 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?
Schema description coverage is 0%, so the description needed to compensate, but it only mentions in_ms/out_ms in passing. It does not explain what in/out mean, whether both are required, or whether there are relative constraints such as out_ms > in_ms. The schema only provides types and minimum values, which is insufficient.
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 clearly states a specific action and resource: trim a shot's duration, with in_ms/out_ms as the relevant parameters. It also names rerender_episode as a follow-up, which helps define its role, but it does not explicitly distinguish trim_shot from similar shot-editing siblings such as split_shot.
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 the tool is for trimming shot durations and gives one important workflow condition: it is free, and after it returns, rerender_episode must be called to reassemble the film. However, it does not state when to prefer this over alternatives like split_shot or update_shot, nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.