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

Annotations only say readOnly=false/destructive=true; the description adds far more: all-or-nothing creation, a duplicate-name pre-check that aborts before sending, no product-level spend cap plus Google's 2x daily / 30.4x monthly behavior, ad review gating, and irreversible duplication risk. It also documents the WRITE_CONFIRMATION_REQUIRED handshake, token invalidation on any argument change, 10-minute single-use expiry, and the data_availability enum with an explicit warning that no_rows/access_error are not zero.

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?

Dense but front-loaded: the atomic payload comes first, then constraints, then behavior, then the confirmation protocol. It is long for a description, and the trailing "호출마다 토큰 1소진" arrives without context, while the confirm flow is buried mid-paragraph rather than surfaced early.

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 13 parameters, no output schema, and destructive writes, the description carries a lot and covers safety, arming ritual, and result-availability semantics. The remaining gap is the shape of a successful response — it never says what identifiers come back after creation (e.g. campaign/ad group IDs), so an agent must infer from the actual payload.

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 already 100%, so the baseline is 3; the description goes beyond it by giving character limits absent from the schema (headlines 3-15 of 30 chars, descriptions 2-4 of 90 chars, Korean counted as 2), the quote/backslash ban on campaign_name, and the currency-unit meaning of daily_budget_amount. It does not, however, explain the eu_political_advertising or account_link_id parameters, which remain schema-only.

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 ("Create one Search campaign") and enumerates the full atomic payload: budget, PAUSED campaign with Maximize clicks on Search + partners, ad group, responsive search ad, keywords. This immediately distinguishes it from google__ads__search__campaign__update and from the display/pmax/demand_gen create siblings.

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: enabling the campaign is done with "the Search campaign update tool," and this product "cannot delete a campaign." It also gives a hard when-not rule ("Do not call again when the result is unknown: a second call can create a second campaign") and a two-step preview/confirm protocol with the condition for using it.

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