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

Annotations declare destructiveHint=true and openWorldHint=true, but the description goes well beyond them: campaign-level dates overwrite every channel including switched-off ones, draft date writes are partial and can fail entirely, and budget_move_verification returns verified=false with errors even when success=true because the budget group already changed. It also states 'No schedule rollback is attempted', which is exactly the irreversibility an agent needs before calling.

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?

Purpose and the partial-edit rule are front-loaded, but the back half drifts into a dense procedural block on budget-move verification and readback reporting, with mid-sentence line breaks that hurt scanning. Several sentences restate the same irreversibility idea ('No schedule rollback is attempted', 'Do not report dates preserved without that readback'), so it is longer than it needs to be.

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 single deeply nested campaign_data object with no output schema, the description covers return shape ('updated configuration and per-operation results or errors') and the budget_move_verification field, plus the date-write constraints. It omits prerequisites — permissions, whether the campaign must be a draft or launched for each edit class, and what a per-operation error looks like.

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 baseline is 3, but the description adds real semantics on top: a concrete payload example ({"campaignId": 12345, "budgetGroup": "Destination"}) and the rule that only campaignId is required while other fields are additive partial edits. It does not explain channel-block precedence or how google/reddit/linkedin blocks interact, which the schema only partly covers.

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 opening sentence names a specific verb set (add/edit) and resource (audiences, ads, offers, targeting, settings on a Precision Optimization campaign), plus the return value. It scopes itself to Precision Optimization campaigns, which implicitly separates it from add_and_edit_native_campaign_elements, but it never states that contrast explicitly, so an agent must infer the boundary.

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?

Strong intra-tool guidance: 'CRITICAL: PARTIAL EDITS ONLY', omit name/startDate/endDate/channel blocks unless requested, and a worked budget-group-only payload. What's missing is sibling routing — nothing tells the agent when to prefer add_and_edit_native_campaign_elements, update_reddit_channel_settings, or the remove_* tools instead of this one.

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