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

Annotations already declare readOnlyHint=true, destructiveHint=false, so safety is known. The description adds behavioral detail: it returns all enabled keywords with approval_status, system_serving_status, disapproval_reasons, and bundles campaign budget loss as `_campaign_budget_loss`. It does not describe pagination or rate limits, but it covers the key output semantics beyond the annotations.

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 long and includes a list of actions (keywords, search_terms, diagnostics, raw) that are not relevant to the tool since it's flattened to status. This extraneous content adds verbosity and could confuse an agent. The structure is organized with a summary, actions list, and bulk support note, but the irrelevant parts could be trimmed for conciseness.

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?

Given no output schema, the description must explain return structure well. It does mention key fields (approval_status, system_serving_status, disapproval_reasons) and the `_campaign_budget_loss` field. However, it lacks clarity on pagination, result size limits (for status it says ALL enabled keywords, but no mention of max results or batch handling), and how parameters like query play in. It covers essentials but not fully, making it adequate yet incomplete.

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%, so the description must explain parameters. It does clarify that account + customer_id set scope, supports campaign_id/ad_group_id filters, and mentions days=7|14|30 for diagnostics. However, it does not explain `query` (likely for raw action, but flattened to status? ambiguous), nor the exact meaning of `account` vs `customer_id`. Bulk ids are mentioned generically. Partial compensation but lacks completeness.

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 clearly state it provides keyword status/policy diagnostics (approval_status, system_serving_status, disapproval_reasons) and answers 'why is my keyword not serving?', distinguishing it from sibling like diagnostics and keywords. However, it lists multiple other actions (keywords, search_terms, raw) that are not the tool's actual scope after flattening to status, introducing some ambiguity about the core purpose.

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?

It explicitly contrasts status ('why is my keyword not serving?') with diagnostics ('is it bid or Quality Score?'), guiding when to use this tool versus alternatives. It also mentions bulk support and supported filters (campaign_id, ad_group_id, days=7|14|30), giving clear context for invocation. No explicit when-not-to-use statements, but the action differentiation provides strong guidance.

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