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

Beyond the readOnlyHint/destructiveHint annotations, it discloses server-side resolution of adProduct/Campaign/Ad Group, grouping of compatible items into one Amazon request, brief caching of successful group responses, and nuanced partial-failure semantics where rate-limited groups preserve earlier successes and skip later groups of the same product while other products continue. The TOO_MANY_REQUESTS code-sharing detail is exactly the kind of non-obvious behavior 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 core purpose and targeting rules are front-loaded, but the retry/caching guidance is restated several times ('retry only retryItemIndexes after retryAfterSeconds,' 'do not repeat an unchanged request,' 'reuse successful items') across the middle and final sentences. Roughly a third of the text could be cut without losing information.

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, return values need no explanation, and the description covers everything else an agent needs: input shape selection, server-side resolution, caching, partial rate-limit failure, and retry protocol. Nothing material is missing for correct invocation.

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 baseline is 3; the description goes further by explaining the mutually exclusive parameter combinations (targetingId alone vs adGroupId + targeting) and clarifying that adProduct and campaignId are deliberately absent because the server resolves them. That adds real meaning beyond the field-level descriptions.

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 opening sentence gives a specific verb, resource, and scope: read-only POST returning Amazon suggested bids and bid ranges for 1-100 Sponsored Products/Brands/Display targeting items. It is clearly separable from siblings like query_advertising_target_recommendations and the prepare_*/apply_* families, which mutate rather than read.

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 states explicit selection rules: existing items use targetingType + targetingId only; uncreated candidates require creating the ad group first, then passing targetingType, adGroupId, and targeting. It also gives negative guidance ('this operation does not create the candidate'), warns that historical CPC is not a suggested bid, and prescribes the retry path on TOO_MANY_REQUESTS.

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