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

Annotations already declare destructiveHint=true and idempotentHint=true, and the description adds the important operational fact that the call previews by default and only mutates when confirm is true. It does not state what happens to search_partners/display when they're omitted, or that targeting changes are reversible, which is the main remaining behavioral gap for a mutation tool.

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 purpose is front-loaded in the opening clause, and the parenthetical buys its length by explaining a non-obvious default. It is dense in one spot but contains no filler sentences or repetition of the 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, open-world mutation with no output schema, the description supplies preview semantics, the meaning of both settings, and a discovery path via ads_diagnose. It stops short of saying whether omitted optional fields retain their current values and what the preview payload looks like, minor but real gaps.

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 only 17%, so the description carries most of the weight, and it does: the location enum's two values are explained with real consequences, and search_partners/display are described as on/off switches for a Search campaign. customer_id and campaign_id get no explanation, but they're conventional identifiers; confirm is covered by the schema.

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 verb and resource — 'Change who a Google Ads campaign reaches' — then names the two concrete setting groups it controls (location targeting, Search Partners/Display). An agent can separate it from ads_set_campaign_status, ads_set_campaign_budget, and ads_campaign_bidding without opening the 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?

Explicitly routes the agent: it points to ads_diagnose's 'Campaign settings' check as the way to discover which campaigns need this, and it uses the PRESENCE vs PRESENCE_OR_INTEREST tradeoff to explain why you'd pick one over the other, including the out-of-area click cost for local businesses.

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