auto_cleanup_interview

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: it reveals asynchronous execution, immediate job_id return, the exact pipeline stages, the room-tone requirement, and the no-concurrent-call restriction. It does not state whether the operation is destructive/reversible or whether it applies to a selection or the whole project, which are notable gaps for a processing 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 well-structured with a clear headline, pipeline summary, parameter breakdown, and warnings. Each section adds actionable information, and there is no filler or repetition.

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?

The description covers the asynchronicity, monitoring path, pipeline behavior, both parameters, and an important input precondition. However, it omits what exactly the tool operates on (selection, track, or project), whether the change is destructive/undoable, and any details about how the job result is delivered beyond check_pipeline_status. Given no output schema, a bit more would make it fully complete.

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%, so the description must compensate for both parameters. It does: remove_noise is explained as applying noise reduction using the first 0.5s as a noise profile, and remove_silence as truncating long silences, with defaults included. It also adds an important prerequisite about room tone when remove_noise is True, which is critical 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 opens with 'ONE-CLICK INTERVIEW CLEANUP' and specifies a light-touch processing pipeline for dialogue and multiple speakers, so the target resource and action are unambiguous. It further distinguishes itself from the podcast cleanup sibling by noting it is 'lighter than podcast — preserves natural conversation dynamics.'

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 operational guidance: it runs in the background, returns a job_id immediately, and should be monitored via check_pipeline_status. It also explicitly warns not to call it again if a pipeline is already running. It compares to the podcast tool, but does not fully address when to choose this over other related cleanup tools such as auto_cleanup_vocal or auto_cleanup_live.

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