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

Annotations only say readOnly=false and destructive=false, so the description carries most of the burden and does it well: flat per-recording price, charge gated on confirm_cents matching the quote, hard audio limits, and precise idempotency semantics (keyed on token+tool+key, replay with different args returns the first result). What is missing is what happens on a failed or partial transcription and whether the charge still applies.

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-loads cost and purpose in one sentence, then uses compact Args/Returns blocks that are easy to scan. A few lines restate schema descriptions almost verbatim (quote_only, idempotency_key), which is mild duplication but not harmful.

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 paid, mutating, six-parameter tool with no output schema, the definition supplies the cost gate, the prerequisite sources for both required arguments, size and duration limits, idempotency behavior, and an inline return shape. An agent has everything needed to call this correctly and safely.

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 schema coverage at 67%, the description closes the gap on the important ones: it explains what library_id references, what quote_only does to confirm_cents, and adds real semantics beyond the schema for idempotency_key (scoped to the token, not the arguments). language and timestamps get only a bare gloss, and the 0-with-quote_only rule for confirm_cents is the main added value over the schema text.

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?

Names a specific verb and resource ('turns a voice or music item from your Library into text') and front-loads the pricing model, so an agent immediately knows both the action and its cost consequence. The 2 MiB / 3 minute limits further pin down scope in a way no sibling tool shares.

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 the required flow explicitly: library_id comes from library_list, the price from tool_cost_estimate, and quote_only to get a price without buying. It does not name an alternative transcription path or state when-not to use it, but the prerequisite chain covers the practically important guidance.

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