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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds real behavioral context: SKUs are matched case- and space-insensitively, the default account set is 'every connected marketplace account that can list offers', and it explains the shape of the comparison output. It omits cost/scan limits beyond the schema's page cap, so it is not exhaustive.

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 output shape, then matching semantics, then usage examples and default scope. Every sentence carries information, though the example queries could be trimmed slightly without loss.

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 an output schema present, annotations covering the safety profile, and 100% schema coverage on parameters, the description supplies the remaining decision-relevant context: what the comparison shows, how SKUs are matched, and what the default scope is. An agent has everything needed to select and invoke it correctly.

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 documents limit, accounts, max_pages, and missing_on. The description restates the default account scope (duplicating the accounts parameter description) and adds the case/space-insensitive matching rule, but gives no extra detail on how limit interacts with max_pages or how missing_on scopes the result. Baseline 3 applies.

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 names a concrete verb (compare/analysis) and resource (SKUs across marketplace accounts) and specifies the exact output shape: 'one row per SKU with a yes/no per account, and per account the SKUs it is missing.' This clearly separates it from siblings like listing_check, offers_summary, and price_parity_check, which do not produce a cross-account coverage matrix.

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?

It gives concrete trigger questions ('are all channels 1:1', 'what is missing on Temu Greece', 'which products are only on eMAG') plus a stated default scope. It does not explicitly name an alternative tool or state when not to use this one, so it falls 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.