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

The description discloses a lot of behavioral detail beyond the read-only/idempotent annotations: 7-day default, top-50 limit, approval_status/system_serving_status/disapproval_reasons, bundled `_campaign_budget_loss`, supported filters, and days values. The main transparency gap is the cryptic flattened-action note and the lack of an action-selection mechanism, but nothing contradicts 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 dense but front-loaded with an overall summary, followed by labeled actions and bulk support; nearly every sentence adds useful information. The '[Flattened action: search_terms]' line is confusing and unintegrated, which slightly harms structure, but overall it is compact for the amount of detail provided.

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?

The description gives strong return expectations for each action—metrics, statuses, diagnostics fields, and the custom `_campaign_budget_loss`—and lists filters and day ranges. However, there is no output schema, and the missing action-selection mechanism means the description does not fully equip an agent to invoke the tool correctly, especially if the tool is actually only the search_terms action.

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 0% schema description coverage, the description compensates partly by explaining account/customer_id scope, campaign/ad_group filters, days options, and bulk IDs (campaign_ids, ad_group_ids, customer_ids). However, it does not clearly explain the `query` parameter for raw GAQL SELECT, and it never maps the listed actions to a parameter that selects them, which is a significant invocation gap.

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 explicitly lists multiple actions—keywords, search_terms, status, diagnostics, raw—and gives specific verbs and resources, so it is not vague. However, the tool name and the '[Flattened action: search_terms]' note suggest the actual tool is only the search_terms action, and the description heavily overlaps with sibling tools like google_ads_keywords_status and google_ads_keywords_diagnostics without clarifying the distinction.

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 provides useful intent guidance for sub-actions, e.g., status answers 'why is my keyword not serving?' and diagnostics answers 'is it bid or Quality Score?'. However, it never states when to use this combined tool versus the dedicated sibling tools, and it does not explain how to switch between the documented actions, leaving usage ambiguous.

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