auto_cleanup_vocal

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

With no annotations provided, the description carries the behavioral disclosure burden and does a solid job by explaining background execution, immediate job_id return, the exact pipeline stages, and how remove_noise uses the first 0.5s as a noise profile. It omits what the tool operates on (selected audio or a track) and whether the cleanup is destructive, which prevents a perfect score.

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 front-loaded with the main purpose, then explains background behavior, pipeline steps, and the parameter in a compact, structured way. Each section earns its place, though a few words like 'Professional' add little information.

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 one-parameter background tool, the description is nearly complete: it covers the processing chain, the job_id return, how to monitor results, and the important noise-profile caveat. The missing input scope (what selection or track is processed) and lack of any note about reversibility/destructiveness are the main gaps.

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 only provides a boolean with a default and no description, so the help text fills the entire gap. It explains the semantics of remove_noise, its default True, and the critical precondition that the first 0.5s should be room tone or silence, which is invaluable for correct invocation.

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 that the tool performs one-click vocal cleanup with professional processing for singing and studio vocals, giving a specific resource and intent. It is distinguishable from podcast/interview/live siblings by its vocal focus, though it does not explicitly name or compare itself to those alternatives.

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 gives clear context: it is for vocal tracks and should be monitored via check_pipeline_status. However, it does not say when to avoid this tool or which sibling should be used for non-vocal content, so the selection of this tool over alternatives is left largely implicit.

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