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

Annotations provide no hints (all false), so the description carries the burden. It discloses project-scoping ('acts only on the explicit project_id and returns the project identity'), that the picture is never shown, and that silent clips are reported rather than claiming sound was added. These are valuable behavioral traits beyond the schema. It does not explicitly mention side effects like file creation, but the description implies saving an audio file, and destructiveHint=false covers safety.

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 longer than average but every sentence adds value: project-scoping note, purpose, examples, usage guidance, and edge-case behavior. It is front-loaded with the critical scope constraint and remains focused without redundancy. Slightly verbose but justified by the tool's complexity.

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 tool with no output schema, the description provides everything needed: how to obtain the asset_key, what the return value is (a new storage_key), how to use that key, when to use this tool vs. direct placement, and handling of silent clips. It fully equips the agent to call this tool correctly without additional lookup.

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 describes project_id in detail, but asset_key is only a bare string. The description compensates by stating 'asset_key is a [video_clip] storage_key from list_assets,' which is essential for correct invocation. Since schema coverage is 50%, this added meaning raises the score from baseline 3 to 4.

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 explicitly states the action: 'Take ONLY the sound out of an uploaded VIDEO and save it as an audio file,' with concrete user-phrase examples ('use the song from this clip'). It clearly distinguishes from sibling tools like add_music by explaining that this tool returns a storage_key for later placement, so the agent knows exactly what this tool does and what it does not.

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 explicit usage guidance: 'call this when you want the file first (e.g. to get_audio_analysis its beats)' and contrasts with the alternative of passing the clip key directly to add_music/add_sfx/add_voiceover, which achieves the same in one step. It also notes that nothing enters the edit until placed, preventing misuse.

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