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

Annotations already declare readOnly=false, destructive=true, idempotent=true, openWorld=true. The description adds two genuinely non-redundant facts: the call is 'billable' (cost implication) and returns a 'durable operation receipt' (async, pollable). However it never explains what 'destructive' means here (e.g., overwriting existing chapters) or how idempotencyKey affects replay behavior.

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?

A single front-loaded sentence with no filler, and the billing/return facts arrive early. It is efficient rather than bloated; its shortfall is under-specification, not verbosity.

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?

An output schema exists, so return-value detail is not required, and the 'durable operation receipt' phrasing usefully frames the async pattern. Still missing for a billable, destructive, idempotent-keyed mutation: cost/reversibility expectations, idempotency semantics, and how to poll the operation.

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 0% for two required parameters. The description conveys only that transcriptionId should point at a 'completed transcript'; it says nothing about idempotencyKey's role (deduplicating retries) or the expected tr_ format. The description does not compensate for the documentation gap.

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 and resource ('Starts billable AI chapter generation for a completed transcript') plus the return artifact ('durable operation receipt'). It is clearly distinguishable from summarize_transcript or repurpose_transcript by the 'chapters' resource, though it never names a sibling to route against.

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?

The phrase 'for a completed transcript' implies a prerequisite (the transcript must be finished), which is useful implicit guidance. But there is no explicit when-to-use/when-not, no mention of how this differs from summarize_transcript, and no guidance on following up the returned receipt via get_job_status or list_operations.

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