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

Annotations only declare readOnly/destructive=false, and the description goes far beyond that: the five data_availability states and what no_rows vs access_error mean, truncation signalling, when next_page_token is safe, currency conversion and the absent metrics.cost case, and a prompt-injection warning on returned strings. This is exactly the behavioral context an agent needs before calling.

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 correctly with purpose and read-only status, and most sentences carry information. However the metric mapping is written out three times in identical form ('metrics.impressions is returned as metrics.impressions' ...), which is pure repetition, and the closing Korean token-cost line and the phrase 'anonymous taste calls' read as leftovers. Roughly a third of the text could be compressed without loss.

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, nine parameters and a complex result shape, the description fully covers what comes back: per-row metric placement, channel_metrics fallback, currency_code/currency_minor_unit_digits, truncation flags and the data_availability vocabulary. An agent can interpret the response without additional documentation.

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 baseline is 3, but the description adds real meaning: row_limit is a local cap rather than a Google page size, page_token resumes only from a next_page_token that was emitted, and request_idempotency_key has an explicit generate-once/reuse-on-recovery protocol plus a note that provider idempotency_key is a different field. The metric-projection rules also explain how the metrics array behaves.

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: 'Report Search campaign performance for one Google Ads account over a date range.' That is enough to separate it from the pmax/display/demand_gen report siblings by channel. It stops short of naming an alternative sibling explicitly, so it is clear but not fully differentiated.

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 operating conditions: widen the date range on no_rows, narrow the range or raise row_limit when not resumable, and reuse the idempotency key only to recover a lost response. What it does not do is say when to pick this over google__ads__channels__report or google__analytics__report; the channel scoping is left implicit.

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