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

Annotations already declare destructive=true and openWorld=true, so the safety profile is covered; the description adds genuinely new traits beyond them: one-time confirmation receipts, idempotency semantics, and the fact that a linked draft may silently prepare (but not execute) the next preview, plus that Review Sandbox simulates writes. It never explains what a rejected/INDETERMINATE outcome looks like at the description level, but that is pushed into the parameter docs.

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 tool-level description is four short sentences that front-load the core action and the confirmation dependency, with the sandbox caveat last. The only weak spot is 'Review Sandbox simulates advertising writes and skips continuation,' which is terse to the point of being cryptic without prior context.

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 destructive, idempotent write tool with an output schema and full annotation coverage, the description supplies the confirmation gate, retry/idempotency model, continuation side effect, and sandbox behavior — enough to call it correctly. Residual gaps (retry-on-timeout and INDETERMINATE reconciliation) are handled in the parameter schema rather than here.

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% and the nested applyContinuation object is thoroughly documented in the schema, so the schema already carries parameter meaning. The description only restates that a receipt and idempotency key are required, adding no syntax or format detail beyond the structured fields. Baseline 3 is appropriate.

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 concrete verb (Executes) and resource (a confirmed AD_AD_CHANGE plan on the Amazon Ads account), and the second narrows scope to ad states and supported Sponsored Brands ad names. That distinguishes it from apply_product_ad_creation and the other apply_* siblings in the fleet, though it never names an alternative explicitly.

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?

'Executes only a confirmed ... plan' plus the receipt and idempotency-key requirements implicitly set the precondition (confirm_workflow_plan must have run first) and the continuation/sandbox exceptions carve out when behavior differs. It gives clear context but stops short of naming the prepare/confirm siblings or stating explicit when-not conditions at the description level.

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