Video Clip Export

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

Annotations declare a non-read-only, non-idempotent, non-destructive, non-open-world write. The description adds real context beyond that: the original is preserved, no provider is invoked, and requested bounds versus selected PTS versus actual encoded timing are kept separate - important for a tool that measures real decoded times rather than trusting inputs.

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?

Three short sentences with the primary action front-loaded and no filler. The timing-separation sentence is dense jargon but it carries genuine information an agent needs; nothing is padding.

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?

An output schema exists, so return values need not be described. For a non-idempotent write tool the description covers preservation, provider isolation, and timing semantics; the only gap is lack of guidance on prerequisites (e.g. whether the source must first be inspected) or sibling routing.

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 coverage is 100%, so the baseline is 3. The description goes slightly beyond by clarifying that start/end values are 'requested bounds' distinct from 'selected original PTS and actual encoded timing', which is meaningful semantics for the two timing parameters rather than restating the schema.

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?

States a specific verb (export) and resource (bounded source clip), plus a secondary action (verify encoded output and manifest). It clearly distinguishes this from analysis tools like video_analyze or video_clip_select, though it never names the close sibling audio_clip_export explicitly.

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?

Usage is implied by 'export a bounded source clip' - the agent can infer this is for cutting out a clip rather than analyzing it. But there is no explicit when-to-use/when-not guidance and no routing against near neighbors such as video_clip_select, audio_clip_export, or media_edit_footage.

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