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

The annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds substantive behaviour beyond them: the billing model (per synthesis call, one call per 5000 characters), the conversion rate (1 credit = $0.10), the 1-credit minimum, and that the call itself is free. That is exactly the non-obvious information an agent needs before committing to a paid synthesis.

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, zero filler, and the key points (read-only, what it returns, what it costs the caller) are front-loaded. The clipped 'Free.' fragment is slightly abrupt but does not waste space.

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 one-parameter quoting tool with an output schema, the description supplies the pricing formula, the billing granularity and the sibling relationship — everything needed to call it correctly and interpret the result. Return-value shape is legitimately delegated to the output schema.

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?

With a single parameter at 100% schema coverage, the baseline is 3, and the description goes slightly beyond by explaining that cost is computed for 'the script' and that billing chunks at 5000 characters, which tells the agent that longer text multiplies the quoted charge.

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+resource ('Read-only cost preview for synthesize_voiceover') and immediately names the sibling it complements. An agent can distinguish it from synthesize_voiceover (which actually spends credits) and from get_credit_balance 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?

It clearly positions itself as the pre-flight check for synthesize_voiceover and flags that it is 'Free', which naturally routes an agent to call it before synthesizing. It does not, however, state any exclusion or compare itself to other cost-related siblings such as get_credit_balance or list_credit_packs.

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