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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds useful output context (returned fields and account-wide metrics) but does not disclose operational behavior such as how date range selection interacts with parameters; the schema covers that.

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 sentence that front-loads the key output categories and lists precise fields and metrics. There is no filler, and every phrase contributes to understanding the tool.

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?

Even without an output schema, the description enumerates the returned account details and metrics well enough for an agent to understand what it will receive. Remaining invocation details are fully covered by the input schema.

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 100%, so the schema fully documents all four parameters. The description adds no parameter-specific detail beyond referencing the date range, which is already represented by start_date, end_date, and date_range.

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 identifies the resource (account) and the payload (account settings plus performance totals). It distinguishes account-level scope from sibling campaign/ad-group tools, but lacks an explicit action verb such as 'get' or 'list'.

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 phrase 'account-wide totals' gives clear context that this is for account-level reporting, which separates it from campaign_performance, ad_group_performance, and similar siblings. It does not explicitly name alternatives or exclusion conditions, but the scope is clear enough for selection.

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

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

Annotations already establish write, idempotent, non-destructive behavior, and the description adds valuable context about validate_only acting as a dry-run that checks policy/duplicate errors without saving. It also clarifies that cpc_bid is in currency units. No contradiction with 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?

Two sentences, front-loaded with the action, and no filler. Every clause carries meaning: the resource, the keyword fields, and the validation mode.

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 definition is adequate for invocation because required parameters are visible in the schema, but with no output schema and no sibling differentiation it leaves some gaps. An agent may not know what the response contains or when to choose add_negative_keywords instead.

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 coverage is only 20%, so the description must compensate. It explains the keyword subfields (text, match_type, cpc_bid) and validate_only, but it leaves ad_group_id and status semantics to the schema, which lacks descriptions. Helpful but not complete for all parameters.

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?

Description starts with 'Add keywords to an ad group,' a specific verb+resource statement that clearly distinguishes this from sibling tools like update_keyword and add_negative_keywords. It also outlines the main object shape (text, match type, optional bid), making the tool's job unambiguous.

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?

There is no explicit when-to-use guidance or comparison with alternatives. The only usage hint is the validate_only mode, but the description never states when to prefer this tool over add_negative_keywords, update_keyword, or mutate.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false. The description adds useful behavioral nuance: campaign-level negatives block the term for every ad group in the campaign, and campaign level is the default. It does not mention validate_only or response behavior, but annotations reduce the burden.

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?

Three short sentences, each earning its place: the action and default scope, the workflow context, and the practical effect of campaign-level negatives. The most decision-relevant information is front-loaded.

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?

For a five-parameter mutation tool, the description combined with the schema and annotations is largely sufficient: the agent knows the required keywords, the level selection, the default behavior, and the follow-up context. Minor gaps include no explicit mention of validate_only behavior or output/return format, but these are less critical given the annotations and schema.

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?

The description adds meaning beyond the schema by explaining the semantic choice between campaign_id and ad_group_id and identifying the default level. It does not detail match_type or validate_only, but those are partially covered by the schema and enum/default definitions, so the description adds meaningful value without needing to duplicate every field.

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: 'Add negative keywords at campaign level (default) or ad group level.' It clearly identifies the tool's scope and the level distinction, and 'negative' differentiates it from the sibling add_keywords tool.

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 phrase 'Typical follow-up to search_terms_report' gives a clear workflow context, and stating the campaign-level default plus the ad-group-level option tells the agent when to choose each scope. It does not explicitly name alternatives or say when not to use this tool, but the usage context is strong.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safe read-only nature is covered. The description adds some scoping behavior (date range, campaign filter, segmentation) but does not disclose return-value details, default date-range behavior, or any edge cases. No contradiction with 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?

A single, front-loaded sentence conveys the core scope and optionality without filler. Every phrase adds value and the description is appropriately compact for a straightforward reporting tool.

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 8 optional parameters and no output schema, the description gives enough to understand what the tool does and when to pick it, but it omits what specific metrics are returned and how date_range interacts with custom start/end dates. Schema descriptions and annotations compensate partially, making this minimally viable.

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 75%, with most parameters already documented in the input schema. The description lightly reinforces date range, campaign filtering, and segmentation but does not add meaningful detail beyond the schema. Baseline 3 is appropriate here.

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 names the exact resource level (ad groups), the nature of the data (metrics), and the scoping options (date range, campaign filter, segmentation). This distinguishes it clearly from sibling report tools like campaign_performance, keyword_performance, and geo_performance.

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 makes the primary use case clear: retrieving per-ad-group metrics, with optional campaign filtering and segmentation. However, it does not explicitly contrast with alternatives such as campaign_performance or keyword_performance, nor does it state when not to use this tool.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds useful behavioral context beyond the annotations: the exact metric set, segmentation options, and the fact that money is in account currency units.

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 concise sentences: the first front-loads the core function and metric list, the second summarizes segmentation and currency. No filler or redundancy.

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 no output schema, the description appropriately enumerates returned metrics and explains the segmentation behavior. It does not describe row identity fields or default date-range behavior, but those are either implied by 'per-campaign' or covered in the input schema. The description is adequate for an agent to form a correct mental model.

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 88%, so the schema already documents most parameter meanings. The description reinforces the concept behind the 'segment' parameter and clarifies the output metrics, but it does not add per-parameter detail absent from the schema. Baseline 3 is appropriate.

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 states that this returns per-campaign metrics for a date range and enumerates the specific metrics reported. It lacks an explicit operative verb like 'retrieves' or 'returns', but the resource and scope are clear and the metrics list distinguishes it from sibling reporting tools such as ad_group_performance and keyword_performance.

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 provides clear context: this is the tool for campaign-level performance metrics with optional segmentation. It does not explicitly state when not to use it or name alternatives, but the per-campaign scope and metric list make the intended use obvious relative to the sibling tools.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds context about returned metadata categories and filtering behavior, but it does not disclose response shape, pagination defaults, or how limit applies to results. That is acceptable given the annotation coverage.

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 sentences deliver the core purpose, the query mechanism, and illustrative wildcard patterns with no redundant filler. The most important information is front-loaded, making it easy for an agent to parse quickly.

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?

For a read-only metadata lookup tool with four parameters and no output schema, the description covers the primary use case, the key parameter behavior, and the nature of returned metadata. It does not go into depth about output formatting or pagination, but those are not critical for an agent to invoke the tool successfully.

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 only 25% schema description coverage, the description compensates well by explaining the intended use of name_like with wildcard examples and by referencing categories (fields, resources, segments, metrics) that map to the category enum. It does not explicitly describe selectable_only or limit, but those are reasonably self-explanatory from their names and schema defaults.

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 object: 'Look up GAQL fields, resources, segments and metrics,' and enumerates the exact metadata returned. It is clearly distinct from sibling gaql_search, which would execute queries rather than describe schema metadata.

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 practical usage context by telling the agent to use name_like with SQL wildcards and provides concrete examples like 'campaign.%' and 'metrics.%conversion%'. It implies this is for metadata discovery rather than data retrieval, though it does not explicitly name gaql_search as the alternative.

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

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

The annotations already mark the tool as read-only and non-destructive, and the description adds important behavioral detail: pagination is handled, rows are capped by limit, and money fields are converted from micros unless disabled. This gives a clear picture of how the tool behaves 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 compact and well-structured, starting with the core action, then usage scope, then key behavioral notes. Each sentence adds necessary information without redundancy or fluff.

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 there is no output schema, the description still provides enough context: it indicates rows are returned, capped by limit, and that micros conversion is applied. It also points to gaql_fields for discoverability, making the tool self-sufficient for a generic query interface.

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?

Every parameter is meaningfully documented: query has an example, limit is described as max rows, customer_id has format and default, and convert_micros behavior is explained in the description. The schema coverage is supplemented by the description, leaving no parameter ambiguous.

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 states the tool runs any GAQL query against a customer and explicitly positions it as the fallback for anything not covered by specific report tools, with concrete examples. This distinguishes it from the many sibling report tools and from gaql_fields.

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 says to use this tool when specific report tools do not cover the need, and gives examples of uncovered areas. It also provides practical guidance on pagination, row limits, micros conversion, and using gaql_fields for field discovery.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, covering the safety profile. The description adds location scoping and the gaql_search companion step, but does not disclose further behavioral traits such as response shape, pagination, or metric definitions. No contradiction with 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?

Two short sentences with no filler. The core purpose is front-loaded, followed by a useful pointer to gaql_search. Every clause contributes meaning.

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 is sufficient to recognize the tool as a location-based performance report and to know how to resolve constants. However, there is no output schema, and the description does not enumerate which metrics are returned or the response structure, leaving an agent somewhat blind to call results.

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 83%, so most parameters are already documented. The description does not add parameter-specific detail beyond mentioning geo target constants, and it does not clarify how those constants relate to the listed input properties. The undocumented campaign_id parameter is not addressed.

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 identifies this as a location-based performance metrics tool: 'Metrics by user location for a date range' and names country/region/city geo target constants. This distinguishes it from sibling reports like campaign_performance or keyword_performance, though it lacks an explicit action verb such as 'get' or 'return'.

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 usage context is implied: use this when geographic/location-based performance metrics are needed. It also gives a practical pointer to gaql_search for resolving geo target constant names. However, it does not explicitly state when to prefer this over sibling reporting tools or what scenarios are not appropriate.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral facts: returned metrics are per-keyword, results are sorted by cost, and campaign/ad-group filtering is available. There is no contradiction with 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 a single sentence that front-loads the core return value, then states the filters and sort order. Every clause adds useful information with no redundant or filler content.

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?

For a read-only report tool without an output schema, the description states the key returned fields, the available filters, and the ordering, which is enough to guide invocation. It does not mention defaults for date range or limit or clarify include_removed behavior, but those are partially addressed by the schema, so the remaining gap is modest.

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 coverage is about 63%, so the schema already documents the date and customer parameters. The description adds meaning for the campaign_id and ad_group_id parameters by stating they serve as filters, and it mentions the sort order that affects the limit parameter's usefulness. However, include_removed remains unexplained and no extra format or syntax detail is provided beyond the schema.

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 identifies the resource as per-keyword metrics for a date range and lists distinguishing fields such as match type, status, quality score, and effective CPC bid. It is specific enough to separate it from campaign- or ad-group-level reports, though it does not explicitly name or contrast sibling tools.

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 implies use for keyword-level reporting and says results can be filtered by campaign or ad group, giving some contextual guidance. However, it does not explicitly state when to prefer this tool over sibling reporting tools like campaign_performance or search_terms_report, nor does it provide exclusion conditions.

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

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

The annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds behavioral detail by explaining the scope of the listing (direct accounts plus client tree), which is not fully covered by the annotations alone. It does not describe the exact output format, but that is not required for a read-only listing tool.

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 concise, consisting of two clear sentences with no redundant information. It front-loads the primary action (list accounts) and provides essential context (reachable with credentials) and a direct use case (find customer_id).

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 the tool has no input parameters and no output schema, the description provides sufficient context: it explains what is listed (accessible accounts), the scope (direct and client tree), and the intended use (finding a customer_id). This is complete for a simple listing tool.

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?

There are no parameters in the schema, so parameter semantics are trivially complete. The description does not need to add parameter-specific information, and the baseline of 3 is appropriate given the high schema coverage (100% with zero parameters).

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 states the tool lists Google Ads accounts reachable with the configured credentials, specifying both direct access and the client tree under a login customer ID. This distinguishes it from sibling tools that list other resources like campaigns or ad groups.

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 explicitly instructs to use this tool to find a customer_id, providing a clear call-to-action. It implicitly indicates this is the tool for identifying accessible accounts, making the use case unambiguous.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral detail by stating the exact output fields and the optional campaign filter, going beyond what annotations provide.

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 two short sentences with no filler. The core purpose and key scope are front-loaded, and every phrase adds useful information.

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?

For a simple read-only list tool, the description covers the resource, returned fields, and optional filtering. It does not explain include_removed semantics or pagination, but the schema documents limit and the name is reasonably self-explanatory, so the tool is usable without further clarification.

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 coverage is 50%; limit and customer_id are already described in the schema. The description adds meaning to campaign_id via 'Optionally filter to one campaign', but it does not clarify include_removed, which has no schema description. Overall, the description partially compensates for the schema gaps but not fully.

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 uses a specific verb and resource ('List ad groups') and enumerates the returned fields (id, name, status, type, default CPC bid) plus the campaign association. This clearly distinguishes it from siblings like list_campaigns, list_ads, and ad_group_performance.

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 implies when to use the tool: when you need ad group details with their campaign, optionally scoped to a single campaign. However, it does not explicitly contrast it with alternatives such as list_ads or ad_group_performance, leaving some selection judgment to the agent.

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

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

The annotations already declare readOnlyHint=true and destructiveHint=false, so the read-only behavior is known. The description adds value by detailing what fields are returned, especially the special handling for responsive search ads with headlines, descriptions, and pinning. This goes beyond what structured annotations provide.

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 a single, dense sentence that front-loads the core purpose and immediately lists useful output details. Every clause contributes meaningful information with no redundancy or filler.

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?

For a read-only list tool with no output schema, the description covers the main return fields and available filters, which is largely sufficient. The main gap is the undocumented include_removed parameter, but the overall context is strong enough for an agent to understand and invoke the tool correctly.

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 only 40%, and the description only partially compensates by clarifying that campaign_id and ad_group_id act as filters. It does not explain include_removed, which is a non-obvious boolean parameter, and it adds minimal semantic value beyond the schema's own descriptions for limit and customer_id.

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 uses a specific verb ('List') and identifies the exact resource ('ads'), while also enumerating the returned data (type, status, policy approval, ad strength, final URLs, and responsive search ad assets). This clearly separates it from sibling tools like list_campaigns and list_ad_groups.

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 states that filtering by campaign or ad group is possible, which gives some usage context. However, it does not explicitly explain when to choose this tool over alternatives such as gaql_search or other list tools, nor does it provide any exclusion criteria.

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

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

Annotations already cover read-only, non-destructive, open-world behavior, so the bar is lower. The description adds useful behavioral context by listing exactly which campaign attributes are returned and by confirming that performance metrics are intentionally excluded. It does not mention pagination behavior, but for a simple read-only list tool this is a minor gap.

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 compact sentences with the core purpose and returned fields front-loaded, and the metric exclusion placed second. No filler or repetition of schema details.

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?

For a read-only campaign list tool with no output schema, the description is complete: it states what is returned, what is not returned, and where to go for the excluded data. Parameter defaults and constraints are already covered by the input schema and annotations.

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 75% and the schema documents limit, status, and customer_id. The description does not add input-parameter meaning beyond mentioning output fields; include_removed remains undocumented in both schema and description, though its name is reasonably self-explanatory.

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 names a specific operation (List) and resource (campaigns), and enumerates the fields returned (status, channel type, bidding strategy, daily budget, schedule, serving status). It also distinguishes itself from campaign_performance, so an agent can tell them apart.

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 states 'No metrics; use campaign_performance for those,' which gives a clear when-not-to-use condition and names the alternative tool. This is more than enough routing guidance relative to sibling tools.

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

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

The description discloses destructive behavior through 'create/update/remove' and mentions atomicity and dry-run validation, going beyond the annotations. It does not detail error response shapes or partial-failure result handling, but the provided guidance is sufficient for a raw mutation tool.

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 well-structured, including a concrete example, scope, and usage cautions in just a few sentences. Every sentence adds meaningful information without redundancy.

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 the tool's advanced and open-ended nature, the description covers the essential aspects: syntax, supported resources, validation flow, and failure semantics. The absence of an output schema is acceptable because the description focuses on request construction and side effects.

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?

The description compensates for the sparse schema by explaining the operations parameter with a concrete camelCase example and clarifies validate_only and partial_failure behavior. customer_id is already described in the schema, while validate_only and partial_failure are implied through the text.

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 states 'send raw GoogleAdsService.mutate operations using REST field names', which clearly identifies the tool's function and resource scope. It also contrasts with sibling tools by labeling itself 'Advanced' and covering 'every resource the API can create/update/remove'.

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 provides direct guidance: use camelCase field names, 'Use validate_only: true first to dry-run', and notes atomicity unless partial_failure is true. This effectively advises when and how to use the tool relative to the more specific sibling operations.

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

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

The description goes beyond the annotations by explaining that removal is permanent, that it is a soft-delete in reporting terms, and that removed entities remain visible with status REMOVED. This is valuable behavioral context that the destructiveHint and idempotentHint annotations do not fully convey.

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 two sentences with no unnecessary words. The core action and resource types are front-loaded, and the permanence caveat is placed second for emphasis. The example resource name is compact and useful.

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?

For a two-parameter tool with strong annotations, the description is mostly complete: it states the resource types, the input format, and the post-removal behavior. It could mention what happens on success or whether an error is returned for invalid resource names, but the core invocation context is sufficiently covered.

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 coverage is 100%, so the schema already documents both parameters. The description adds a concrete example of a resource_name and clarifies that the resource name is the addressing mechanism, but it does not add substantive semantics beyond the schema.

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 states a specific action (remove/soft-delete) and names the exact resource types it applies to: keyword, negative keyword, ad, ad group, or campaign. It also clarifies the addressing mechanism via resource name. This clearly distinguishes it from sibling tools like set_ad_status or update_keyword.

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 implies when to use the tool by listing the resource types and requiring a full resource name 'as returned by other tools.' However, it does not explicitly compare against alternatives such as mutate or set_ad_status, nor does it state when not to use this tool.

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

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

Annotations already establish that the tool is read-only and non-destructive, so the description only needs to add behavioral context. It adds that results are sorted by impressions and include a status field with ADDED/EXCLUDED/NONE values, but it does not disclose pagination, metric definitions, or open-world response behavior.

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 short sentences pack the core output, the main use case, and sorting behavior with no filler. Every sentence earns its place and the most identifying information is front-loaded.

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?

For an 8-parameter report with no output schema, the description is serviceable but not complete. It conveys the main columns and purpose, but leaves filter scoping, date-range behavior, and metric details to the schema or agent inference.

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?

The description adds no parameter-level meaning; it never mentions date ranges, filters, limit, or min_impressions. With 8 parameters and only 63% schema description coverage, the text should compensate for the undocumented ad_group_id, campaign_id, and min_impressions, but it does not.

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 identifies the report as actual search queries that triggered ads, with keyword, status, and metrics, which clearly states what the tool returns. It does not use an explicit verb like 'retrieves' and does not name sibling tools, but the content is specific enough to distinguish it from keyword_performance and other reports.

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 explicitly frames the tool as 'the main source for finding negative keywords to add,' giving agents a clear trigger for when to use it. It stops short of naming alternatives or stating when not to use it, so it lacks the full when/when-not guidance of a 5.

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

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

The description does not contradict the annotations (e.g., readOnlyHint=false aligns with 'set'). It adds no context about side effects beyond the annotations, but the annotations already convey safety profiles.

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 a single, concise sentence with no fluff. It directly states the action and the target resource.

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 is sufficient for a simple setter tool. It does not mention output format, but given the simplicity and the presence of schema and annotations, nothing critical is missing. Slight lack of explicit mention of required parameters, but those are in the schema.

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 only 33%, with only customer_id having a description. status is self-documenting via enum, but ad_group_id has no description and the tool description does not compensate for the lack of parameter details.

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 states the verb 'set' and the resource 'ad group', and specifies the two possible statuses (ENABLED, PAUSED). It distinguishes itself from sibling tools like set_campaign_status and set_ad_status.

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 implies usage for changing ad group status but does not explicitly state when to use it versus alternatives. It is clear enough from context but lacks explicit guidance.

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

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

The annotations already cover mutation (readOnlyHint=false), idempotency (idempotentHint=true), and non-destructiveness (destructiveHint=false). The description adds little behavioral context beyond the operation itself, although the parenthetical 'within its ad group' clarifies the required relationship between ad_id and ad_group_id.

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 a single focused sentence with no filler. The verb, resource, scope, and possible states are all front-loaded, and the parenthetical adds the necessary ad-group relationship without bloating the text.

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?

For a simple status-setter with annotations covering idempotency and non-destructiveness, the description is mostly complete: it states the operation, the target resource, the allowed states, and the parent scope. The main missing piece is explicit guidance about when to choose this tool over sibling status tools, but the name and resource wording make that reasonably inferable.

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 only 25%, so the description carries part of the parameter-explanation burden. It adds the useful clue that the ad lives 'within its ad group,' which helps explain ad_group_id, but it does not elaborate on ad_id or the meaning of the status values beyond what the enum already provides.

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 uses a specific verb and resource: 'Set an ad ... to ENABLED or PAUSED.' It clearly identifies the object as an individual ad, scoped 'within its ad group,' which differentiates it from sibling tools like set_ad_group_status and set_campaign_status.

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 context is implied by the resource type and title: this tool is for enabling or pausing a single ad. However, it does not explicitly say when to use it versus sibling status tools like set_ad_group_status or set_campaign_status, nor does it mention any exclusions or prerequisites.

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

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

Beyond the annotations, the description adds useful behavioral context: it looks up the budget resource first and refuses to change shared budgets unless allow_shared is true. This gives agents a clearer picture of side effects and guardrails.

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 concise and well-structured: it states the action, gives a concrete example, and explains the key guardrail in two sentences with no redundant wording.

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 covers the core purpose, the input unit, and the shared-budget restriction. It does not describe return values or error behavior, but no output schema is provided and the tool's behavior is reasonably complete for a mutation 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?

The description adds meaning to daily_amount by specifying account currency units and explains allow_shared through the shared-budget refusal behavior. The schema already documents customer_id, and campaign_id is self-evident from the tool purpose.

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 states the action ('Change a campaign's daily budget') and the specific resource (campaign budget), distinguishing it from sibling tools that operate on statuses, keywords, or reports.

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 implies when to use the tool (when changing a daily budget) and provides important caveats about shared budgets and currency units, but it does not explicitly mention alternatives or contrast with sibling tools.

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

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

Annotations already convey readOnly=false, destructive=false, and idempotent=true, so the behavioral safety profile is covered. The description itself adds no extra behavioral context beyond the status assignment, such as effects on serving or reversibility, but it does not contradict 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 a single, direct sentence with no filler or redundancy. It front-loads the action and includes the only essential operational detail: the allowed statuses.

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?

For a simple three-parameter status setter, the description combined with the schema and annotations is largely sufficient to invoke the tool correctly. A bit more detail about return behavior or side effects would be helpful, but nothing critical is missing for correct invocation.

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 only 33%: only customer_id has meaningful schema documentation. The description repeats the status enum values already present in the schema but does not explain campaign_id or clarify when customer_id is needed, so it fails to compensate for the low schema coverage.

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 uses a specific verb ('Set') and names the exact resource ('a campaign') plus the two valid target states ('ENABLED or PAUSED'). This clearly distinguishes it from sibling tools like set_ad_group_status and set_ad_status by focusing on campaign-level status changes.

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 provides clear context: this tool is for campaign status changes, so an agent can infer it is the right choice for campaigns and not for ad groups or ads. However, it does not explicitly name alternatives or state when not to use it, so it stops short of full routing guidance.

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

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

The description clearly states the mutation effect (change status and/or bid) and does not contradict annotations such as readOnlyHint=false, destructiveHint=false, and idempotentHint=true. It adds modest behavioral context like currency units and identifier sourcing, though it does not describe side effects beyond the mutation itself.

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 sentences with no fluff. The first sentence states purpose and parameters, the second gives identifier sourcing. Well organized and front-loaded.

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?

Sufficient for a mutation tool with no output schema: it states what will change, which fields are involved, and how to identify the target keyword. Minor gap: it does not explicitly state that at least one of status or cpc_bid must be provided, though 'and/or' implies this.

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?

The description adds meaning for ad_group_id and criterion_id by pointing to keyword_performance, and reinforces that cpc_bid is in currency units. Schema already covers customer_id and status enum values, but ad_group_id and criterion_id formats are not detailed.

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 action (change status and/or max CPC bid) on a specific resource (keyword) and identifies the keyword via ad_group_id and criterion_id from keyword_performance. This clearly distinguishes it from sibling tools like set_ad_status, add_keywords, or remove_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?

Provides useful context for sourcing identifiers from keyword_performance, implying use after listing keywords. However, it does not explicitly contrast with sibling tools such as add_keywords, remove_resource, or set_ad_status, so when to use this tool versus alternatives is only implicit.

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