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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the closing 'Read-only.' sentence is largely redundant. What the description does add is behavioral: it returns typed findings each carrying a cost figure plus a concrete fix recommendation, and it does not apply those fixes. It omits other useful traits such as data freshness/lag, account-size or permission requirements, and result caps beyond the max_findings param.

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?

Three tight sentences, front-loaded with the value proposition and the concrete detection criteria, followed by the return shape. The 'Tools revision: d80f65c0.' trailer is pure noise that earns no place in a tool description, which keeps this from a 5.

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?

An output schema exists, so the description rightly does not need to enumerate return fields, and its one-line characterization of findings is sufficient there. But for a six-parameter analysis tool with zero schema descriptions, an agent still cannot tell how to tune the analysis window, thresholds, or output volume from the description alone.

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% across six parameters, so the description carries the full burden of explaining them and does not. Nothing tells the agent what days window controls, what summary vs full detail changes, what min_clicks=3 means for the zero-conversion threshold, how max_findings=12 truncates results, or what render does. Only 'campaigns under 1.0 ROAS' loosely gestures at a threshold the params presumably tune.

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 concrete analytical outcome ('find where money is going with nothing to show for it') and enumerates the specific waste patterns detected: zero-converting search terms/keywords, broad match on manual bidding, and campaigns under 1.0 ROAS. That is far more than a restatement of 'analyze_waste'. It stops short of 5 because it never distinguishes itself from adjacent siblings such as analyze_search_terms or bidding_audit, which an agent could plausibly pick instead.

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?

Usage is implied rather than stated: the agent can infer this is the diagnostic tool for wasted spend in a Google Ads account, and the mention of 'the exact negative-keyword or pause call that fixes it' hints that remediation flows go through add_negative_keywords or set_campaign_status. However, there is no explicit when-to-use, when-not-to-use, or named alternative against the many overlapping audit tools in the sibling list.

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