auto_cleanup_podcast

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

With no annotations provided, the description carries full disclosure burden and succeeds: it reveals async behavior ('Runs in background — returns a job_id'), specific pipeline parameters (3:1 compression, 30ms attack), safety limits ('never boosts'), input prerequisites ('first 0.5 seconds should be room tone'), and state constraints.

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?

Structure is logically front-loaded with purpose and safety profile, followed by technical pipeline details, Args block, and critical warnings. Every sentence earns its place—even the specific compressor ratios help distinguish from sibling cleanup tools. No redundancy detected despite length.

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 2-parameter async tool with no output schema or annotations, the description is complete. It covers pre-conditions (room tone requirement), execution details (background job), pipeline specifics, and post-processing workflow (loudness_normalize), leaving no critical behavioral 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?

Schema description coverage is 0%, but the description fully compensates. It documents both remove_noise ('Apply noise reduction using first 0.5s as noise profile. Default: True') and remove_silence ('Truncate long silences/dead air. Default: False'), including critical usage constraints for the noise profile.

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 'ONE-CLICK PODCAST CLEANUP: Professional broadcast-quality processing,' providing a specific verb and resource. It distinguishes from siblings by detailing the exact signal chain (DC offset > HPF 80Hz > NR 12dB > compress 3:1) tuned for podcasts, and explicitly contrasts with loudness_normalize for post-processing needs.

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?

Provides explicit when-to-use guidance ('Use check_pipeline_status to monitor'), when-not-to-use ('DO NOT call this again if a pipeline is already running'), and alternatives ('use check_pipeline_status instead'). Also clarifies safety for 'badly recorded audio' and recommends loudness_normalize for specific streaming targets.

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