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

Annotations already declare readOnlyHint=true and destructiveHint=false; the description adds material context beyond that: token cost per marketplace per ASIN (1 000 tokens each, 14 000 per ASIN), the per-marketplace return shape (title, local-currency price, estimated monthly sales), and the recommended output presentation. This is exactly the kind of behavioral disclosure the rubric rewards.

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?

Front-loaded with the core purpose, then the marketplace list, return fields, cost, and usage rules. The marketplace enumeration and cost warning are long but each earns its place: the cost information changes agent behavior, and the do-not-call rule prevents expensive misuse. No filler sentences.

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?

No output schema exists, so the description carries the burden of explaining return values — and it does: 'title, price in that marketplace's local currency, estimated monthly sales' plus the presentation format '(country, link, local price, sales)'. Combined with cost, usage restrictions, and sibling routing, nothing an agent needs to invoke this correctly 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 coverage is 100% and the schema already specifies '1–5 ASINs to locate (B0 + 8 characters). Pass several only when they will be analyzed together.' The description adds value by explaining the per-ASIN cost scaling and that multiple ASINs are checked across all marketplaces, which informs how many the agent should pass. Slight overlap with the schema keeps this at a 4 rather than 5.

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 and resource: 'Find which Amazon marketplaces list an ASIN, and get its product link on every marketplace.' It enumerates the 14 covered marketplaces, describes the returned fields, and differentiates itself from siblings by naming amzscout_analyze_product / amzscout_get_keywords as the downstream tools for analysis, so an agent can distinguish it without opening other schemas.

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?

Explicitly states when to call it ('ONLY when the user asks where / on which Amazon marketplaces a product is sold'), when NOT to call it ('Do NOT call it just to choose a marketplace for analysis'), gives the alternative behavior (ask the user once and reuse the marketplace), and routes follow-up to specific sibling tools. This is model usage guidance.

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