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

Annotations already declare readOnlyHint=false and destructiveHint=true, so the mutation profile is known; the description adds genuinely new behavior: a hard 25-item batch cap and per-id read-after-write outcome verification. It omits that writes only take effect when the same payload is resent with the confirm_id preview token, which is the most consequential operational detail for this 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?

Front-loaded and dense with zero filler – verb/scope first, then SINGOLA/BATCH variants, then the outcome guarantee and the negative scope. The telegraphic labeling is efficient, though the parenthetical (enabled|paused) is imprecise enough to cost a point.

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 7-parameter mutation with no output schema, the description covers the core operation but leaves gaps: profile_id is undocumented anywhere, the preview/confirm two-step is not mentioned, and the enum mismatch on state could cause a wrong-value call. Adequate but not complete for the risk level.

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 43% (below 50%), so the description must compensate and it partly does: it explains the single-vs-batch alternation, the items shape, and the max size. However it never mentions account_id or profile_id, and it lists state as (enabled|paused) while the schema enum also allows "archived", leaving one parameter's real domain misrepresented.

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+resource ("Aggiorna una o PIÙ campagne Sponsored Display ESISTENTI") plus the mutable fields (daily_budget, state), and explicitly rules out the nearest sibling behavior with "NON crea campagne SD." An agent can distinguish it from ads_create_sp_campaign / ads_create_sp_ad_group 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?

Gives concrete mode-selection guidance (SINGOLA: campaign_id + daily_budget/state; BATCH: items=[...], MAX 25), so the agent knows which parameter shape to pick. It does not name alternative tools (e.g., ads_update_sb_campaign or ads_update_sd_ad_group) or state prerequisites, so it stops short of full when/when-not routing.

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