capcut_detect_beats

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

No annotations are provided, so the description carries the full burden. It discloses the output behavior (BPM, beat spacing, beat times in seconds) and implies read-only operation through the verb 'Find'. It does not explicitly state that files are not modified, but the descriptive output is adequate for a simple detection 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 two sentences long, with the action and output front-loaded. Every sentence contributes: what the tool does, what it returns, and when it is useful. No wasted words.

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?

Despite the lack of an output schema and annotations, the description covers the main behavioral contract: inputs are audio-bearing files, outputs are tempo-related metrics. It does not discuss edge cases (e.g., silent files) or usage of the skipSeconds parameter, but the schema fills the latter gap. Overall, it is sufficiently complete for a straightforward detection tool.

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 provides full descriptions for both parameters (path and skipSeconds), so the baseline is 3. The description adds no parameter-specific semantic meaning beyond what the schema already states, though it does reinforce that the tool works with audio content.

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 uses a specific verb 'Find' and names the resource clearly: tempo and beat times of audio files. It distinguishes itself well from sibling tools like capcut_create_beat_edit or capcut_list_projects by focusing on analysis rather than creation or management.

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 provides a concrete use case ('useful on its own for deciding how long cuts should be'), giving the agent context for when to invoke it. However, it does not explicitly mention when not to use it or point to an alternative like capcut_create_beat_edit.

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