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

Far exceeds the annotations: it discloses that ad spend already incurred cannot be undone, that the result returns previous values enabling undo, that a preview must be shown to the user before execution, that changing arguments invalidates the token, and that no_rows/access_error do not mean zero. It also carries a prompt-injection warning about externally authored strings.

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 core action and the confirmation protocol are front-loaded, and the length is largely justified by the destructive, two-step nature of the write. There is some drag from boilerplate blocks (data_availability enumeration, spending-cap explanation) and an untranslated trailing line about token consumption that reads as misplaced.

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?

With no output schema, the description compensates by explaining what the result contains (previous values, data_availability statuses) and how to roll back. Combined with the precondition list and confirmation flow, an agent has everything needed to invoke this destructive tool safely.

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; the description adds a genuine cross-parameter constraint ('Send at least one of them; a value equal to the current one is not sent') and clarifies the currency unit for daily_budget_amount ('won for a KRW account'). It does not add format detail beyond the schema for individual fields, so it stops short of 5.

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 with scope: 'Update one Search campaign in the selected Google Ads account' plus the exact three mutable fields (name, status, daily budget). The 'Search' qualifier plus the refusal clause for 'a campaign of another type' implicitly separates it from the sibling demand_gen/display/pmax update tools.

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 explicit preconditions ('Send at least one of them'), refusal cases (other campaign type, removed campaign, shared budget, non-daily budget), a when-not ('Do not call again when the result is unknown'), and a full two-step confirmation protocol. An agent knows exactly when to call, when not to, and how to proceed after WRITE_CONFIRMATION_REQUIRED.

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