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

Annotations already establish readOnlyHint=true and destructiveHint=false, so the 'Read-only' tag adds nothing. The description earns credit by disclosing the pagination contract ('Page with next_token until truncated is absent') and the 'never auto-applied / act via stage_* tools' consumption behavior, neither of which is inferable from annotations or schema.

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?

Three dense sentences with no filler, ordered as scope, consumption rule, and pagination behavior. The third sentence is grammatically awkward ('until truncated is absent') and 'Read-only:' partially duplicates the annotation, but every sentence carries information an agent needs.

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 7-parameter read tool with no output schema, the description conveys the data source, the full scope of returned recommendation types, how to consume the output, and how to paginate. Missing pieces are a mapping from each recommendation type to the specific stage_* tool (e.g., NEW_NEGATIVE_KEYWORD → stage_negatives) and response-structure details beyond the truncated flag, but nothing blocks a correct first call.

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?

With 71% schema coverage, the schema documents most parameters, so the baseline is low-but-not-minimal. The description compensates for the undocumented next_token by explaining the pagination loop and the truncated signal, and its domain enumeration (bid, budget, negatives, targets, placement, state) maps directly onto plausible RECOMMENDATION_TYPE values. campaign_id stays undocumented in both schema and description, but it is a self-explanatory filter.

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?

Opens with a specific resource — Amazon's consolidated unified Recommendations API — and enumerates the exact domains it covers: bid/budget/bidding-strategy changes, keywords, negatives, targets, placement, and state suggestions across SP/SB/SD. The 'Amazon's own consolidated' phrasing contrasts with sibling suggestion tools such as ppc_bid_recommendations and ppc_optimization_suggestions, making the scope identifiable without opening their schemas.

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?

Provides explicit consumption guidance: treat the output as ONE input alongside break-even math, and route actions through the stage_* tools rather than applying anything directly ('never auto-applied'). It does not name the specific sibling alternatives or the conditions under which one would pick ppc_bid_recommendations or ppc_optimization_suggestions instead, so exclusions are implied rather than explicit.

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