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

Annotations cover the safety profile (readOnly=false, destructive=false, idempotent=false, openWorld=true), and the description adds genuinely useful non-annotation context: the default-on normalization cap, the per-job fee formula, and the fact that output structure (MP3/ASS) is unchanged when normalization is off. It does not explain whether the call returns a job handle or how to retrieve results, which is a notable omission for an async-looking job 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?

Three compact sentences, purpose front-loaded, no filler. The bracketed pricing formula is dense but is load-bearing information for a paid synthesis call rather than padding.

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?

With no output schema, the description usefully states the output artifact structure, but for a 14-parameter tool with nested objects (speakers, utterances) and multi_speaker routing it omits how multi-speaker mode is invoked and how/whether results are polled via the tts_jobs_* siblings.

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% across 14 parameters, so the schema already carries the semantics; the description only echoes the main input concepts (voice, style, text/utterances) without adding format or interaction detail beyond the schema. Baseline 3 applies.

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 concrete action — submit voice/style/body text to ChatGPT gpt-audio-mini for synthesis — naming both the engine and the inputs. It implicitly separates this from tts_gemini_create by naming the model, but it never explicitly contrasts the two sibling engines.

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?

Usage is only implied: the 2,000-character normalization limit and the fee structure hint at when normalization matters, but there is no explicit when-to-use-this-vs-tts_gemini_create guidance or stated prerequisites.

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