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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and a closed-world scope, and the description adds real value beyond that: a hard 30-day lookback, known omissions (Editor changes and some Change History rows), and propagation lag. It does not explain result caps or what 'detail'/'max_findings' truncation does to the returned set, so it is strong but not exhaustive.

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?

A single dense sentence front-loads the core action and layers the coverage caveats in a logical order, with the read-only note last where it belongs. The trailing 'Tools revision: d80f65c0.' is non-semantic noise that costs it the top mark.

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 return values need no explanation, and the annotations cover the safety profile. What is missing is behavioral detail the schema cannot supply: whether `max_findings` silently truncates results, what `detail=full` expands to, and how `render` affects the agent's consumption of the response.

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 whole burden, yet it only clarifies one: `days` gains a 1-30 bound and a default of 7 that the schema does not state. `detail`, `render`, `campaign_id`, `max_findings` and `customer_id` are left entirely undocumented, which is a significant gap for two enum parameters whose effect on output shape is unknown.

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 opens with a specific verb and resource ('List what changed in the account') and enumerates the exact dimensions returned: when, by which Google login, and through which channel (AdCopilot, website, auto-applied recommendations, scripts, rules, another API tool). No sibling tool in the list covers change history, and the account-level scope is explicit, so an agent can identify it without opening the 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?

Usage is clearly implied by the scope statement plus the coverage caveats (30-day retention, Google Ads Editor changes omitted, some Change History rows missing, minutes of lag) which tell an agent when the answer may be incomplete. It stops short of naming an alternative for older windows or for Editor changes, so it is clear context without explicit exclusions.

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