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

Annotations already declare this as a non-read-only, open-world, non-idempotent write, so the description is not obligated to re-state that. It adds real behavioral context the annotations lack: the operation consumes one of the account's voice slots (a quota consequence) and requires an explicit user-confirmed rights gate before setting rightsConfirmed. It does not say what happens on failure or whether a slot is consumed by a rejected sample.

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?

Two sentences, front-loaded with purpose and input provenance, then the consent constraint and slot consumption. Every clause carries actionable information; nothing is redundant with the title or schema.

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 three-parameter write tool with no output schema, the description covers what the tool does, what inputs are acceptable, the legal/consent precondition, and the resource cost (voice slot). An agent has everything needed to decide to call it and how to prepare the arguments.

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 100%, so the baseline is 3, but the description meaningfully enriches sampleUrl beyond the schema's 'https link to the audio sample' by specifying acceptable provenance, duration (10-60s), single-speaker requirement, and formats (MP3, WAV, OGG). It also clarifies that rightsConfirmed must only be set after the user actually confirms, which is stronger than the schema's constant note.

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?

States a specific verb and resource ('Add a voice to the user's Lazybird account from an audio sample') and immediately distinguishes it from the sibling design_voice by describing that tool's output as one valid input source. An agent can tell save_voice (persists a voice) apart from design_voice (creates one) without opening either schema.

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?

Gives concrete selection conditions: use this when you have either a design_voice result or a public link to a 10-60 second single-speaker recording, and it states the consent gate for cloning a real person's voice. It does not address what to do when the sample fails those constraints or how it relates to search_voices, so it is clear context rather than exhaustive routing.

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