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

Annotations already establish read-only/non-destructive, and the description adds genuinely new behavioral context: average CPC is a historical reference and not an Amazon suggested bid, ratios must be recomputed from summed base metrics rather than averaged, and customer approval is required before mutating the draft. These are non-obvious operational constraints that materially change how an agent should use the output.

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 purpose and usage guidance are correctly front-loaded, but the second half is bloated: the 95-day window and non-overlapping-window splitting rules largely restate the startDate/endDate schema descriptions, and the passage about keyword ranking trend limits (DAILY 90 days / RAW 31 days) belongs to a different tool and is noise here.

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?

For a read-only query with an output schema and full annotation coverage, the description supplies what is needed to call it correctly: date-range constraints, dimension/values pairing, sorting guidance, and the bid-reference caveat. The misplaced keyword-ranking-trend text adds confusion but does not create a functional gap.

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%, so the baseline is 3, but the description adds usage meaning the schema does not: which dimension/values combinations to combine for candidate discovery and which sortBy fields (adOrders, adSales, roas) surface historical performers. It does not explain searchKey/resultType interplay, so it is above baseline but not exhaustive.

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 first sentence names a specific verb and resource and disambiguates the two return modes: "Returns product-scoped buyer search term performance or product-ASIN search term performance." Combined with the schema's dimension/resultType enums, an agent can tell exactly what this does versus siblings like query_aba_search_terms or query_advertising_targets.

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 an explicit triggering scenario (a manual AD_STRUCTURE_CREATE draft with productAds but no positive targeting) and a concrete recipe using dimension=sku|asin|parentAsin with values. It also states the approval gate before adding candidates. It stops short of naming an alternative sibling or an explicit when-not-to-use case, so it falls just below the top band.

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