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

Annotations declare readOnlyHint=false, openWorldHint=true, destructiveHint=false. The description adds meaningful behavioral context beyond that: 'Nothing is added back, so the answer has no room and no music at all' clarifies the output is not just cleaned but fully stripped of non-speech, and billing is disclosed ('Billed per 10 seconds of audio'). It also notes the clean file is saved to the library. It does not, however, discuss permissions or rate limits.

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 core action and scope, then moves to input format and billing. It is slightly long but each sentence adds useful information; no obvious filler.

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 single-parameter tool with annotations covering safety and no output schema, the description provides sufficient context: use case, input format, output characteristics, billing, and a partial list of return fields. It could be improved by explicitly mentioning that the tool requires an external service (ElevenLabs), but the openWorldHint annotation already signals external effects.

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 already documents the single 'source' parameter with 100% coverage, including that it accepts a library id or public https link. The description mirrors this without adding new format details, so the schema does the heavy lifting. Baseline 3 is appropriate.

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 states a specific verb and resource ('Pull the voice out of a noisy recording with the ElevenLabs voice isolator') and elaborates on exactly what noise categories are removed vs. retained. This clearly distinguishes it from siblings like enhance_video_prompt, analyze_video, or generate_speech, which serve different purposes.

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 a clear context for use ('so a phone recording or a noisy location take can be used as clean dialogue'), which implies when to reach for this tool rather than alternatives. However, it does not explicitly name a sibling alternative or describe a when-not-to-use scenario.

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