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

Annotations already cover readOnly, idempotent, non-destructive, closed-world behavior, and the description adds real value on top: default 'all states unless filtered', stale assets omitted unless include_stale, only newest asset version by default, DRAFT widgets for brand_store_page, and money returned in the profile's native currency. These defaults are the sort of behavior an agent could not infer from the schema, though return shape details remain thin for some entities.

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?

It is telegraphic and dense but well front-loaded: each clause opens with the entity name it governs, so an agent can scan to the relevant segment. The brace-and-pipe notation for Ads v1 objects is cryptically compressed, but it is concise with essentially no filler.

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 32-parameter polymorphic read tool with no output schema, the description carries the return-shape burden and does so per entity (object envelope with nextToken for Ads v1 objects, columns/rows for campaign_settings, config+performance+search terms for campaign_details). A few entity/parameter interactions (pagination via idOffset, id filtering on ads/targets) remain unstated, so it stops short of completely self-contained.

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 84% schema coverage the baseline is 3, and the description earns a bump by mapping parameters to entities: negative=true for negative targets, ids for assets/campaign_details/brand_store_page, entity-specific states, and path+widgetTag linkage to ads.brand_store.update_page_asins. Some params (ad_group_ids, campaign_ids, nextToken, idOffset) are left to the schema, so it is 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 description enumerates every entity value (campaigns, ad_groups, ads, targets, portfolios, assets, campaign_settings, campaign_details, brand_store_page) and states what each returns, so an agent can tell which read it gets. The verb is only implied ('get'/'Read'), and nothing distinguishes it from siblings like query or run_query, which keeps it from a 5.

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?

'Read before/after submit_mutation' is the only explicit usage directive, and it correctly frames this as a read-before-write/verify tool. There is no guidance on when to prefer get_entities over query, run_query, or get_report, and no stated preconditions, so usage is implied rather than spelled out.

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