Plan: create a paused Google Ads Search campaign

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

The description adds real context beyond the annotations: the request is a Google-side dry-run, nothing downstream (ad groups, keywords, ads) is created, the bidding strategy is hard-fixed to manual CPC with no bid amount, and the campaign remains PAUSED until activated in the Google Ads UI. This is consistent with readOnlyHint=true and destructiveHint=false, though it does not address the declared idempotentHint=false (e.g. whether re-planning the same name yields a new plan).

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 and key constraints are front-loaded, and each sentence carries distinct information (budget ownership, network, atomicity, bid strategy, paused state, approval gate). It is dense and slightly fragmented by line breaks, but there is no filler.

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?

There is no output schema, yet the description covers everything needed to call this correctly: what gets created, what explicitly does not, the fixed bidding strategy, the budget semantics, the paused lifecycle and the approval/apply follow-up. Nothing material is left ambiguous for a four-parameter planning tool.

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 schema already documents name, client_id, customer_id and the micros budget. The description still adds meaning by clarifying the budget is the campaign's own and not shared, plus the account-currency micros convention, which is the one parameter most easily mis-scaled by an agent.

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 description names a specific verb and resource ('Plan creating one Google Ads Search campaign') and pins down scope precisely: PAUSED, own non-shared daily budget, Search network only, single atomic request. It also states explicitly what is NOT produced (no ad group, keyword or ad), which lets an agent distinguish this from sibling planning tools such as gads_plan_budget_change or gads_plan_add_negatives.

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?

It places the tool in a workflow by noting the plan stays paused and requires human approval before gads_apply, so the agent understands this is the planning step and gads_apply is the execution step. It does not explicitly say when to choose this over a sibling campaign-planning tool or what preconditions (e.g. an existing client/customer id) are required, so it falls short of full alternative routing.

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