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

Beyond the annotations, the description discloses that a persisted artifact is created (tenant/owner/token-bound, short-lived), that no Google-side mutation occurs, the permission requirements, the requestKey deduplication behavior, and the exact eligibility filter on ads. This resolves the ambiguity left by readOnlyHint=false plus destructiveHint=false — the write is a local preview record, not an ad change — which is exactly the context annotations cannot convey.

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 action and its scope are front-loaded, and every sentence carries distinct information. The negative constraints are somewhat repetitive across three separate clauses ('No Google mutation,' the exclusion list, 'A preview is not an actual ad booking'), and the telegraphic fragment style is dense but readable.

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 no-output-schema preparation tool, the definition covers safety, eligibility, and permissions well. However, it never tells the agent what the preparation yields or how to consume it — no mention of the resulting operation/token being retrieved via get_google_ads_tracking_operation or applied via apply_google_ads_tracking — leaving the lifecycle incomplete for a multi-step flow.

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 description coverage is 0%, so the description carries the burden. It explains requestKey's purpose ('Stable requestKey prevents duplicate preparation'), which is real value beyond 'format: uuid', but campaignIds appears nowhere — neither its meaning, its omission default, nor its relationship to the paused-campaign eligibility rule is stated. Half the parameters remain semantically undocumented.

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 chain and resource: reading the linked tenant Google Ads account and existing RSA final URLs, then persisting a short-lived preview. It explicitly separates itself from the mutating sibling by stating 'No Google mutation' and 'A preview is not an actual ad booking,' so an agent can tell it apart from apply_google_ads_tracking without opening either 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?

Eligibility is stated concretely ('Only ads referenced exclusively by paused campaigns are eligible') along with prerequisites ('current Owner Marketing-write and existing ads.amend account rights') and the negative scope ('No activation, budget, copy, payments or conversion export'). What is missing is an explicit forward pointer to the apply sibling or the operation-lookup sibling, so the sequencing after preparation must be inferred.

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