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

With no annotations provided, the description carries the transparency burden. It discloses that the tool compares against Lowvyn's price history, returns one of five specific verdicts, and includes an explanation. It also explains the behavior when claimedPrice is omitted via the schema, and the language ('return', 'compares') implies a non-mutating operation, though it doesn't state read-only explicitly.

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 three sentences with no filler: it front-loads the core action, lists the return verdicts, and then gives the usage trigger and integration hint. Every clause earns its place, and the most important information appears first.

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?

The tool has only two parameters, no output schema, and no annotations, so the description must explain both inputs and outputs. It does this thoroughly: accepted input forms, optional claimedPrice handling, verdict values, explanation output, when to use it, and compatibility with other tools' result fields. Nothing essential for correct invocation is missing.

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 100%, so the schema already explains idOrUrl and claimedPrice well. The description adds meaningful integration context by explicitly saying the tool accepts the id or canonicalUrl directly from a search_products/intent_search result, which helps an agent know what values to feed in. This goes beyond the schema's standalone parameter descriptions.

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: verifying whether a deal is genuine for a given product, and names distinct possible verdicts. It clearly differentiates itself from siblings like find_cheaper, get_price_history, and get_product by focusing on deal authenticity rather than alternatives or raw history.

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 an explicit trigger: 'Use this first when a user asks is this actually a good price?' It also clarifies that it accepts ids or canonicalUrls from search_products/intent_search results, which is practical routing guidance. However, it does not explicitly say when to prefer a sibling tool instead, so it doesn't reach the full 'when/when-not/alternatives' bar.

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