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

Annotations already declare the tool read-only and idempotent, but the description adds additional behavioral context: data comes from the last-30-day change_event, per-customer scope, includes user_email/client/operation/field-mask/resource, and supports bulk execution via customer_ids. It also states exactly which entity types are covered, which is non-obvious without the description.

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 description is compact and efficient: a clear summary sentence, a rich specification of coverage, then a quick usage/format line for date filtering, one line on polling, and one line on bulk support. Every sentence earns its place; there is no verbose fluff or repetition.

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?

Without an output schema, the description delivers substantial context about return values (user_email, client, operation, field mask, old/new resource) and behavior (30-day window, per-customer, bulk). It only misses details about 'limit' behavior, default page size, and the precise semantic of 'account' meaning, so it is complete but not exhaustive.

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?

With zero schema description coverage, the description carries the burden of explaining parameters. It successfully explains 'since', 'until', 'days', 'customer_ids', and the incremental pattern. It leaves 'limit' and 'account' vs 'customer_id' under-explained, but the most critical filtering semantics are well documented.

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 starts with 'Change history / audit log' and immediately states the resource: 'who changed what in the account and when.' It differentiates itself from sibling tools like google_ads_campaigns or google_ads_ads, which return current entity states, by explicitly listing covered entities (campaigns, ad groups, ads, keywords, budgets, bids) and event metadata (operation, field mask, old→new resource).

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?

The description gives clear usage context: use this tool to inspect audit history, with specific filter options ('since'/'until'/'days') and an explicit incremental-polling pattern. It does not name alternate tools to use instead, make it clear when not to use this tool. The guidance is strong but lacks explicit exclusions.

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