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

Annotations already cover read-only, idempotent, and non-destructive behavior, so the description adds value by disclosing the important caveat: 'Provider output is unverified; decode and confirm token, price, and terms before execution.' This is a meaningful behavioral warning beyond what the annotations or schema express.

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 description is two sentences with no filler. The core purpose is front-loaded, and the only additional sentence carries essential trust-and-verification guidance.

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 simple read-only tool with fully documented parameters and an output schema, the description covers the call context and the key output trust warning. It does not define what makes an order 'best' (e.g., lowest price vs. highest bid), which keeps it from being fully complete.

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?

The schema has 100% coverage and already describes side as 'listing' or 'offer' and tokenId as the NFH token id. The description does not add extra semantics about parameter format or allowed combinations, so the baseline score of 3 is appropriate.

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 ('Find'), a specific resource (best listing or offer hash), and an explicit scope ('for one NFH token'). It reads as a clear lookup tool and is readily distinguished from the prepare_* sibling tools that build transactions.

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 description gives a clear use context — locate the best order before some execution step — and the phrase 'before execution' implies a pre-trade role. However, it does not explicitly state when to choose this over alternatives, nor does it name any sibling tool as a better fit for a different scenario.

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