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

Annotations already cover the safety profile (readOnly, non-destructive, closed-world), so the description earns its credit by adding semantics annotations cannot express: ledger is the default source rather than a live API sweep, the default window is deliberately narrow, and manager/closed/canceled accounts yield a skip reason instead of metrics. That partial-result behavior is genuinely useful non-obvious context.

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?

Two tight sentences with no filler: the scope constraint and the default-source caveat come first, and the skip-reason edge case is appended compactly.

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 an output schema present, return values need not be explained, and the description covers the key edge case (skip reason) plus default behavior. What is missing is routing guidance relative to the sibling insights tools, which an agent would need to pick this one confidently.

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 80% schema coverage the schema already documents source, dates, and customer_id, including the ledger default and narrow window. The description mostly restates those defaults rather than adding new meaning; connection_context remains undocumented in both places.

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+resource ('bounded daily spend') scoped to exactly one enabled non-manager customer, which is precise enough for an agent to know what it returns. It does not name or contrast with near-neighbors like google_ads_insights_overview_query or insights_query_consistent, so sibling differentiation is left implicit.

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 audience constraint ('one enabled non-manager customer') implicitly tells the agent when this applies, and the skip-reason clause hints at unsupported accounts. But there is no explicit when-to-use vs when-to-use-alternatives guidance against the sibling insights query tools, which is the main selection ambiguity here.

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