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

With no annotations provided, the description carries the full burden of behavioral disclosure. It comprehensively covers the payment challenge flow, output roles and formatting (1080×1920 .mp4, loudness normalization), refund policy (only zero clips refunded), pricing model (N × $0.50 per clip, single charge), and the requirement that the source remain in storage. This is exemplary transparency for a mutating, payment-requiring tool.

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 front-loaded with the core purpose, then systematically covers the flow, pricing, alternatives, and edge cases. It is long but every sentence carries essential information for an agent to correctly execute this multi-step, payment-gated operation. The redundancy with schema descriptions is minimal, and the organization (purpose → flow → outputs → pricing → alternatives → retry) aids comprehension.

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?

Given the complexity (6 parameters, two-call flow, payment methods, output schemas, failure semantics) and absence of both annotations and an output schema, the description is remarkably complete. It tells the agent exactly how to sequence calls, what to poll, how to interpret outputs (roles clip-1-video...clips-manifest), how to handle partial failures (no refund for <N clips), and even how to recover state (retry with job_id alone). Nothing material is missing.

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?

While schema description coverage is 100% and inline parameter descriptions are already detailed, the tool description adds critical operational semantics: it explains the purpose of each parameter in the two-call sequence (e.g., source_job_id as the capability token, payment_credential after paying the challenge), clarifies the clips array composition (your own picks, nothing auto-selected), and resolves the distinction between job_id-only retry vs job_id+payment_credential. This goes well beyond what the schema provides, especially for the payment flow.

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 opens with a specific verb-resource pairing: 'Batch-cut a set of your own chosen vertical 9:16 clips from a prior find_clips job in one purchase.' This immediately distinguishes it from extract_vertical_clip (single clip) and clips_horizontal (horizontal orientation), making the tool's purpose and scope unambiguous.

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 explicitly states when to use it ('once find_clips has surfaced candidates you like, to cut several in one purchase') and when to use the alternative ('use extract_vertical_clip directly when you need per-clip framing control or more than 5 clips from one source'). It also outlines the two-call flow and payment confirmation steps, leaving no ambiguity about invocation context.

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