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

No annotations are provided, so the description carries the full behavioral burden. It hints at an address-matching check ('exact ... to the invoice recipient') but says nothing about what a failed verification returns, whether the call is read-only or mutates order state, idempotency, or which chains/assets count as 'crypto'.

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 waste, and the verification intent plus the delivery gate are stated immediately. It is arguably too terse for the tool's complexity, but there is 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?

With no annotations, no output schema and zero parameter documentation, the description is the only source of behavioral information – yet it omits the verification criteria, failure semantics, and asset scope. An agent cannot confidently call this or interpret its result.

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% – both order_id and tx_hash are bare strings with no documentation. The description mentions the invoice recipient but never explains how order_id identifies the invoice or how the tx_hash is matched, so it fails to 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?

States a specific verb (verify) and resource (crypto transfer to the invoice recipient), which is clear on its own. However, it never distinguishes itself from the sibling verify_usdc_payment, leaving the agent to guess whether 'crypto' here excludes USDC or overlaps with it.

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 'before delivery' gives an implied trigger point, so the agent can infer this is a pre-fulfillment gate. But no alternative is named and no when-not condition is stated, so the choice between this and verify_usdc_payment remains implicit.

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