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

Annotations only say it is a non-read-only, non-idempotent, open-world write. The description adds real value beyond that: it costs credits, it requires input of at least one minute, and it is a two-stage workflow whose files come from export_clips rather than this call. It stops short of saying whether a job is created and must be polled or cancelled (siblings get_job and cancel_job exist), which is the main behavioral gap.

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 front-loaded sentences covering purpose, output, follow-up and cost with no redundancy. The trailing phrase 'like on the website' is the only slightly vague filler, but it does convey that credits are charged as in the web product.

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 7-parameter, all-optional tool with full schema coverage and no output schema, the description covers purpose, input constraint, returned data, downstream step and billing impact. What it omits — asynchronous job handling and how source_id chains off a prior Klipa job — is relevant given the sibling get_job/cancel_job set, keeping it short of a 5.

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 100%, with enum explanations for goal, format, clip_count and max_clip_seconds already in the schema, so the schema carries the parameter burden. The description adds only the minimum source-video length, not semantics for source_id chaining or instructions. Baseline 3 is appropriate here.

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?

Specific verb and resource: 'Analyses a long video ... and finds its best moments as short clips'. It names the target formats (TikTok, Reels, Shorts), the output shape (title + virality score per clip), and explicitly describes the handoff to export_clips, so an agent can distinguish this discovery step from the file-production sibling.

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?

Gives a concrete eligibility constraint ('at least 1 minute'), states the follow-up step ('the clip files are then produced with export_clips'), and warns that it consumes Klipa credits. It does not explicitly contrast with other clip-producing siblings such as make_highlight_video or cut_video, so an agent must still infer when this is the right choice.

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