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

Even with annotations present, the description adds substantial behavior beyond them: the Stripe payment-verification side effect, the fact that it may activate an already-paid license, the polling rate limit, and the confidentiality requirement for the token and download URL. None of this contradicts the annotations (readOnlyHint=false, idempotentHint=true).

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?

The main purpose is front-loaded in the first sentence, and each subsequent sentence adds a distinct operational rule (prerequisite, activation side effect, completion criterion, retry condition, polling limit, privacy). Given the behavioral complexity, the length is fully justified with no filler.

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 1-parameter tool with no output schema, the description covers the critical operational facts: what is retrieved, the completion condition, the retry condition, and the rate limit. The only gap is the precise response shape and failure-mode handling, which would normally come from an 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?

Schema coverage is 100%, so the baseline is 3. The description restates that order_token comes from create_4k_checkout and must be kept private, but the schema already says both of these things. No additional meaning is added beyond the schema for the single parameter.

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 specific verb and resource: verify a 4K order's payment with Stripe and retrieve the license, receipt, and private master download. It clearly differentiates from siblings — it references create_4k_checkout as its prerequisite and is distinct from quote_4k_license and license_clip, which handle quoting and licensing rather than post-payment fulfillment.

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?

Explicit when-to-use and when-not-to-use guidance is given: requires the token from create_4k_checkout, retry later if delivery_status is preparing, never claim completion until purchase_completed is true, and poll no faster than once every 10 seconds. This fully equips an agent to sequence the call correctly.

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