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

Annotations already declare readOnlyHint=true but the description adds substantial context beyond them: it discloses the seller-scoped measurement limitation (brand-owner A+ may masquerade as coverage), per-marketplace document separation, the non-implemented write path, and the specific catalog_not_ready response with alternatives rather than a silent error. These are genuine behavioral traits an agent needs.

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 single-dense-paragraph format front-loads the core purpose well, but it crams purpose, output shape, error handling, disclosure obligations, marketplace caveats, and API limitations into one block. It is information-rich but not well structured for scanning, and several clauses are longer than needed.

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?

Given a read-only audit with no output schema, the description covers scope, limitations, and failure modes thoroughly. It could still be clearer about the pagination/truncation behavior implied by top_n, max_catalog, and max_documents, which materially affect what the agent reports.

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 top_n, account_id, max_catalog, and max_documents with defaults. The description adds no syntax or interpretation beyond the schema, which sets the baseline at 3 per the rubric.

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 (audit) and resource (A+ Content coverage) and defines exactly what is produced: which ASINs have an APPROVED A+ document and which do not, ordered by commercial weight. It is clearly distinguishable from siblings like get_aplus_document or list_aplus_documents (single document vs. catalog-wide audit).

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?

Gives explicit when-to-use framing ('which pages that actually sell are missing A+'), names alternatives for the failure case (list_aplus_documents / get_aplus_document when catalog_not_ready), and states the mandatory user disclosure limit and the per-marketplace restriction. It also explicitly states what the tool cannot do (creation/editing via API).

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