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

Annotations already declare readOnlyHint, destructiveHint=false and openWorldHint=false, but the description adds real value: it states there are 'zero payment and Provider effects', describes the completed-order payload (csc.delivery.v4 with 1-3 source-backed suppliers and English report data), and warns against repaying. That is meaningful behavioral context beyond the structured hints.

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?

Three sentences with no egregious padding, and the core action is front-loaded. However, the jargon-dense phrasing and the tangential Stripe recovery sentence add noise rather than clarity, so structure is adequate but not crisp.

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?

With no output schema, the description does partially compensate by describing the returned csc.delivery.v4 payload. But for a tool with an untyped second parameter and 0% schema coverage, it omits parameter guidance and sibling disambiguation, leaving real 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 description coverage is 0% for 2 parameters, so the description must carry the load, but it never explains the order_id format (^csc-[0-9a-f]{64}$) or the purpose of the untyped 'purchase' parameter. The only faint signal is 'Do not repay for existing results', which does not adequately compensate for the coverage 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?

The description names a verb+resource ('Read your durable Agent CSC order'), which is a real action, but the purpose is buried under jargon ('independent signed-wallet authentication', 'csc.delivery.v4') that obscures what CSC stands for. It never distinguishes itself from the sibling result_china_supply_check_v0, so an agent cannot confidently tell status from result.

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?

There are implied usage cues ('Do not repay for existing results', 'Stripe users use their secure card recovery link'), which help for repeat lookups. However, there is no explicit when-to-use-this-vs-alternatives guidance and no mention of the sibling result/prepare/purchase tools that clearly overlap in purpose.

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