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

Beyond the annotations, the description discloses the default-on text normalization with a 2,000-character total limit, that a skill fee applies, that disabling it leaves the MP3/ASS result structure unchanged, and the pricing model (5P base per job plus normalization skill fee). Cost and size-limit disclosure is exactly the kind of context annotations cannot carry. It stops short of saying what happens on failure or how results are retrieved.

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?

Four sentences with the purpose front-loaded, followed by normalization behavior and pricing. The bracketed fee formula at the end is dense and atypically formatted but still short. No filler sentences.

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 14-parameter, nested-object, async job-submission tool with no output schema, the description never states that it returns a job handle to be polled via tts_jobs_status/tts_jobs_result, nor how the returned MP3 and ASS artifacts are obtained. Given the absence of an output schema, that omission is a significant gap for correct downstream invocation.

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 100%, so the baseline is 3. The description adds genuine meaning for normalize_text (default on, 2,000-char ceiling, surcharge) beyond the schema's brief note, but the other 13 parameters including utterances and speakers get no additional explanation in the description.

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 a voice, reading style, and either body text or per-speaker utterances to Gemini speech. Combined with the tool name, an agent can tell this is the Gemini-backed TTS job submission. It does not explicitly contrast itself with tts_openai_create or tts_jobs_create, so sibling differentiation is left implicit.

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 explicit when-to-use guidance: nothing tells the agent when to pick Gemini over tts_openai_create, nor that voices should be resolved first via tts_gemini_voices. The normalization note describes a default, not a selection criterion. The agent must infer routing from the tool name alone.

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