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

Beyond the readOnlyHint and destructiveHint annotations, the description discloses the return structure in useful detail: composite risk score range, up to 10 MAP events with specific per-event fields, up to 10 unauthorized sellers, and 1–3 recommended actions. This is strong behavioral transparency, especially with no output schema to rely on.

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?

Two tight sentences: the first packs purpose and output details, the second adds concrete trigger phrasing. No fluff, front-loaded, every clause earns its place.

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 description covers purpose, output shape, and usage prompts, which is valuable given the missing output schema. However, with 24 optional parameters and only 33% schema coverage, it leaves significant ambiguity about which inputs are central (e.g., asin vs. brand) and how the filters affect results. Adequate but with clear 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 only 33%, and the description does not compensate. It only says "for an ASIN or brand," which loosely maps to the `asin` and `brand` parameters, but the 20+ filter parameters (prices, fulfillment, counts, date ranges, severities) are not explained anywhere in the description. The agent gets little help understanding which parameters matter or how they combine.

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 clearly states the tool performs risk and protection assessment for an ASIN or brand, then enumerates concrete outputs: a risk score, MAP violation events, unauthorized seller list, and recommended actions. It differentiates from sibling tools like map_violations_today and unauthorized_sellers by presenting a synthesized composite assessment, and the trigger-phrase examples reinforce intent.

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 explicit usage guidance: "Use for 'flag risk events on my brand' or 'is this ASIN risky?' style prompts." This tells an agent when to invoke the tool, though it does not explicitly name alternatives or state when *not* to use it, so it falls just short of a 5.

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