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

No annotations are supplied, so the description carries the full behavioral burden, and it only implicitly signals a safe read via "List". It does not state whether all voices are returned when the filter is omitted, whether results are paginated, or whether voices are engine/region-scoped, though the presence of an output schema offsets part of the gap in return-value disclosure.

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 purpose line is one sentence and front-loaded, with the parameter note following in a compact Args block. Minor waste in docstring scaffolding rather than user-facing content, but no padding of substance.

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-optional-parameter read tool with an output schema covering return values, the description supplies purpose, scope, and the one filter format an agent needs. Nothing required to call it correctly is missing.

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 coverage is 0% and the parameter is documented only as a bare string titled "Language Code". The description adds real meaning by marking it optional as a filter and giving concrete format examples ("fr", "ja-JP"), which is exactly the disambiguation the schema lacks.

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 ("List TTS voices") scoped to dubbing, which separates it from mutation siblings like clone_voice or delete_saved_voice. It doesn't explicitly name a sibling alternative, so it stays at 4 rather than 5.

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?

There is no when-to-use guidance and no mention of alternatives such as get_audio_capabilities or preview_voice. The phrase "for dubbing" hints at context but never tells the agent when this tool is the right choice over its siblings.

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