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

Beyond the annotations (destructive, non-idempotent, open-world), the description discloses dry-run semantics (previews unless confirm is true), the matching mode (phrase match), the acceptance constraint (only items the audit flags right now), and the reversibility path (re-enable via ads_set_keyword_status). This is exactly the extra context a destructive tool 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?

Three sentences, front-loaded with the primary action, then constraints, then scope exclusions. Each sentence carries distinct information (what, precondition/preview/revert, what is untouched) with no repetition of the title or schema.

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, no-output-schema compound mutation, the description covers behavior, constraints, and reversibility well. It does not sketch the preview's return shape, but the confirm parameter description carries that, so the gap is minor.

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 the baseline is 3, but the description adds genuine semantics beyond the schema: confirm produces a preview showing exactly what would happen, and negative terms are applied as phrase match while non-flagged terms are refused. That syntax and refusal behavior is not derivable from the schema alone.

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 states a specific verb (apply) and resource (Google Ads fixes from audit_client), then enumerates the two concrete actions: pause flagged keywords and add user-chosen search terms as negatives. An agent can distinguish this compound remediation tool from siblings like ads_set_keyword_status or ads_add_negative_keywords without opening any schema.

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 establishes the precondition that only currently-flagged items are accepted, ties itself to audit_client as the source of truth, and states the revert path via ads_set_keyword_status. Exclusions are explicit (no budgets, extensions or Meta campaigns). It stops short of routing the agent to sibling tools (e.g. ads_add_negative_keywords) for non-flagged terms, so not quite a full when/when-not map.

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