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

Annotations already declare destructiveHint=true, idempotentHint=true and readOnlyHint=false, so the safety profile is largely covered. The description usefully adds the gating precondition that a prior user confirmation in the conversation must exist, plus the two required tokens, but says nothing about what happens on digest mismatch or whether a status change can be reverted.

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?

Two sentences, front-loaded with the action and its confirmation precondition. The trailing 'Requires approval_ref and expected_plan_digest' partly duplicates the schema's required list but functions as a useful pre-flight reminder rather than 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?

Output schema exists, so return values need not be described. For a destructive, approval-gated mutation with zero parameter documentation, though, the definition is thin: the semantics of the two required tokens and the fate of the 'reviewed status' field are underspecified.

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 0% across 5 parameters, so the description must carry the load. It only names approval_ref and expected_plan_digest without explaining where the approval token comes from or that the digest guards against stale plans, and new_value, old_value and entity_name are entirely undocumented. Only the 'from current to approved value' phrasing indirectly hints at what old_value/new_value mean.

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?

States a specific verb and resource: set the reviewed status field of one Meta ad from current to approved. The phrase 'one Meta ad' implicitly distinguishes it from the singular/plural sibling operations_confirm_ad_statuses and from the ads_prepare_status_change family, 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?

'Run the change the user just confirmed in this conversation' establishes a clear trigger condition for use. However it does not say when NOT to use it (e.g. when no approval exists yet, use ads_prepare_status_change), nor does it route the agent to operations_confirm_ad_statuses for multi-ad changes.

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