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

Annotations say only readOnlyHint=false and openWorldHint=true, so the description carries the real burden and does it well: exact credit pricing (500 Sinapses per 1.200 chars, minimum 50), cache reads are free, repeated speech isn't re-billed, clientApiKey is rejected without charge, and the 5000-char ceiling with pre-chunking. It also discloses that output always bills in Sinapses because 'a casa não recebe chave de provedor' and that text must arrive pre-cleaned (no em-dash, no markdown). This is the kind of cost/auth/constraint context an agent needs before calling a paid, open-world 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?

Front-loaded with the identity and sub-actions, which is good, but it degenerates into a dense wall of run-on sentences with nested parentheses and backticked inline code. Some content is redundant with the schema (the language enum list, the 5000-char limit and pricing appear both here and in the text parameter description). Roughly a third of the text could be cut without losing meaning.

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, two-action, paid TTS tool with no output schema, the description covers the essentials: what speak returns (audioBase64+mimeType+sizeBytes), billing, caching, storage behavior, and provider routing. What's thinner is failure behavior beyond the clientApiKey case and the interaction between `store` and cached responses, which is described only in the schema. Close to complete, with a few gaps.

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 93%, so the baseline is 3; the description still adds value beyond it by stating the operational constraint that text is pre-processed by the caller and chunked above 5000 chars, and by spelling out the cost consequence of text length. It also explains the provider/model interdependency (drama-3 only meaningful for fish, native pt voices only on Gemini 3.8) that the flat schema can't express. Remaining params (outputFormat, voiceSettings, fishReferenceId) are documented only in-schema, which is acceptable at this coverage.

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?

Opens with a specific verb+resource: 'Helen Voice TTS via ElevenLabs, Google Gemini ou Fish Audio', and immediately enumerates the two sub-actions (list_presets, speak) with what each returns. An agent knows this is the speech-synthesis tool. It does not, however, contrast itself with nearby siblings such as sapiens_stock_audio, sapiens_musicator or sapiens_sintetico, so the differentiation work is left to the agent.

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 genuinely actionable routing between the three providers ('provider=fish ... o mais forte em japonês, mandarim e coreano: fala de personagem e cena de anime pedem ele') and between models ('modelId=drama-3 vira o Drama 3, a fala dirigida'), plus a cache/cost hint. It never states when NOT to use this tool or which sibling to pick for a non-TTS audio need. Clear context, but no explicit exclusions.

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