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

Annotations only supply destructiveHint=false, so the description carries most of the behavioral burden. It hints that created keywords start enabled, but says nothing about duplicate keywords, partial-batch failure, per-keyword error reporting, or that match_type applies uniformly to the whole call.

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?

It is a single front-loaded sentence with no filler, which is good, but for a six-parameter mutation tool it is under-specified rather than genuinely concise. The parenthetical is the only extra information and it is ambiguous.

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, but the description still omits essential mutation context: duplicate handling, batch semantics, and how match_type/cpc_bid interplay with the required inputs. Only destructiveHint=false is available to characterize risk.

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 all six parameters including cpc_bid, match_type and validate_only are already documented with good detail. The description adds no parameter-level meaning beyond the implicit '(ENABLED)' status note, which makes the baseline 3 correct.

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?

It states a clear verb and resource — 'Adds keywords to an ad group' — so an agent knows the core action without opening the schema. It offers no differentiation from closely named siblings such as add_negative_keywords, and the trailing '(ENABLED)' is unexplained shorthand.

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 when-to-use guidance, no prerequisites, and no routing to alternatives like add_negative_keywords for negative keywords or set_keyword_status for pausing existing ones. The agent must infer scope from the schema alone.

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 are minimal (destructiveHint=false only), so the description carries most of the behavioral burden. 'Adds' implies an additive mutation consistent with the annotation, but the description does not say whether existing targeting is replaced or merged, whether permissions are required, or what a conflict does. It adds some but not rich behavioral 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 short sentences, front-loaded with the action and followed by the prerequisite. Zero filler; every sentence earns its place.

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?

An output schema exists, so return values need not be described, and schema coverage is complete. The prerequisite workflow is covered. It lacks mutation details (merge vs replace, permission needs) that would matter for a write tool with sparse annotations, so not a 5.

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 already documents all five parameters (including negative, validate_only, and the id format example 1013962). The description only reinforces the id-resolution requirement for `geo_target_ids`, which the schema itself covers, so 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?

States a specific verb and resource ('Adds location targeting criteria to a campaign'), and explicitly names the sibling tool (`suggest_geo_targets`) it depends on rather than duplicating. An agent can distinguish this writer from the resolver and from `remove_campaign_criterion` and `add_negative_keywords` without opening schemas.

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?

Clear prerequisite: resolve human-readable places to ids via `suggest_geo_targets` first. This is an actionable routing instruction rather than generic advice. It stops short of an exclusion ('do not call with place names directly') or a when-not-to-use case, so it is not a full 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?

Annotations only declare destructiveHint=false, so the description must carry the rest. It does disclose the real-world effect of adding negatives, but is silent on duplicate handling, permission needs, whether validate_only alters behavior meaningfully, and irreversibility. Reasonable but not rich.

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, purpose front-loaded before the workflow hint. Every clause earns its place with no padding.

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?

An output schema exists so return values need no explanation, and all five parameters are documented in the schema. What remains thin is behavioral edge cases (duplicates, match-type interactions) for a mutation tool with minimal 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 100%, so the baseline is 3. The description adds no syntax or format guidance for keywords, match_type, or validate_only beyond what the schema already documents.

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 and resource ('Adds campaign-level negative keywords') plus the concrete effect ('preventing ads from showing on those queries'). The word 'negative' cleanly distinguishes it from the sibling add_keywords, and the 'campaign-level' scope is explicit.

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?

Names the upstream workflow explicitly ('the usual follow-up to reviewing get_search_terms_report'), which tells the agent when this tool belongs in a sequence. It stops short of stating when NOT to use it (e.g., ad-group-level negatives) or naming a conflicting 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 only declare destructiveHint=false, so the description carries more of the burden. It usefully discloses that the ad group is created ENABLED and is a 'standard search' type, but omits what happens on duplicate names, permission/auth requirements, and whether failures are atomic. The added status detail is genuine value beyond 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 with no filler; the core action and resulting state come first, and nothing is wasted.

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?

An output schema exists, so return values need not be explained. However, for a creation/mutation tool with minimal annotations and three required parameters, the description leaves gaps around duplicate handling, error behavior, and failure semantics that an agent would benefit from.

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 already documents all five parameters, including cpc_bid, validate_only, and required ids. The description adds no parameter-level detail, so the baseline 3 applies.

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 verb and resource ('Creates a standard search ad group') plus the resulting state ('ENABLED in a campaign'). It is clearly distinguishable from siblings like update_ad_group or create_responsive_search_ad, though it does not name those alternatives.

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 says what the tool does but gives no guidance on when to use it, prerequisites (e.g. needing a valid campaign_id), or how it relates to update_ad_group. No when-not conditions or alternatives are mentioned.

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?

Only destructiveHint=false is annotated, so the description carries most of the burden. It usefully discloses the return value (resource name) and the downstream workflow step, but says nothing about permissions, account-level scoping, or whether repeated calls duplicate assets — modest but real added value.

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, zero padding, and the core definition plus the actionable next step are both front-loaded. Every clause earns its place.

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 single-resource creation tool with a rich schema, an output schema, and one annotation, the description covers purpose, returned handle, and the required follow-up call. Nothing an agent needs to invoke it correctly is missing.

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 all five parameters including validate_only and call_conversion_action_id are already fully documented. The description adds no parameter-level syntax or format detail, which is the expected baseline when the schema does the heavy lifting.

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 and resource ('Creates a call asset') and immediately clarifies what that resource is ('clickable phone number shown with ads'), so no sibling tool like create_ad_group or create_campaign could be confused with it.

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?

Explicitly names the follow-up action and the sibling that performs it ('attach it to a campaign with link_asset_to_campaign'), giving a clear workflow context. It does not state when this tool would be inappropriate or what alternatives exist, so it stops short 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?

With only destructiveHint=false provided, the description adds meaningful behavioral context: the campaign starts PAUSED and cannot spend money until a human enables it. This is non-obvious, safety-relevant information not present in annotations or schema. It stops short of describing auth needs or return behavior, but output schema covers the latter.

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 tightly written sentences, front-loaded with the tool's purpose and the safety-relevant PAUSED state. Every clause earns its place.

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 10-parameter creation tool with full schema coverage and an output schema, the description covers the two things an agent most needs: the creation state and the budget prerequisite. Missing only minor niceties like validation-mode guidance (though validate_only is documented in 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 all ten parameters are already documented in the schema (including budget_resource_name's origin and bidding strategy enums). The description only reinforces the budget dependency. 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?

States a specific verb (Creates) and resource (campaign) and adds the crucial default state (PAUSED). This clearly distinguishes it from siblings like create_ad_group and create_campaign_budget. An agent knows exactly what this tool produces without opening the schema.

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?

Explicitly gives the prerequisite ('Create a budget first with `create_campaign_budget`'), which routes the agent to the correct preceding tool. It does not name exclusion conditions or alternatives, but the ordering constraint is clear context.

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 only declare destructiveHint=false, leaving the write semantics to the description, which does say it 'Creates' and what it returns. It does not disclose permission requirements, the effect of explicitly_shared, or error/validation behavior beyond what the schema already covers.

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, front-loaded with the action and then the return-value consequence. No filler; every clause carries 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?

An output schema exists, so return values need not be re-explained, and the description still supplies the one fact an agent needs for chaining (the resource name feeds campaign creation). For a mutation tool with thin annotations, slightly more on preconditions would make it complete.

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 all five parameters including validate_only and explicitly_shared are already documented in the schema. The description adds no parameter-level meaning beyond that, so the baseline 3 applies.

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 and resource ('Creates a daily campaign budget') and adds the workflow-relevant fact that it returns a resource name needed by campaign creation. It does not explicitly contrast with the sibling update_campaign_budget, so it falls short of full sibling differentiation.

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 mention that the returned resource name is required when creating a campaign implies the ordering context, but there is no explicit when-to-use guidance or named alternative (e.g., update_campaign_budget for modifying an existing budget). Usage is only implied.

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 only declare destructiveHint=false, so they say little. The description supplies the genuinely useful behavioral fact that the ad is created PAUSED and must be enabled with set_ad_status, which an agent could not infer otherwise. It stops short of covering permissions, validation failures, or duplicate handling.

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?

One compact sentence; the creation act and the paused-state caveat are front-loaded with zero filler, and the follow-up tool is named in parentheses.

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 described, and the schema covers all 8 parameters. For a mutation tool with thin annotations, the description covers the essential state behavior but leaves error/permission context unstated.

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%, with headline/description counts, character limits, and path constraints all documented in the schema. The description adds no parameter-level detail, so the baseline 3 applies.

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 ('Creates a responsive search ad') and adds the non-obvious initial state (PAUSED). It does not explicitly contrast itself with sibling creation tools like create_ad_group, though the resource is distinct enough to disambiguate.

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?

Gives a clear lifecycle instruction: the ad lands paused and is enabled later via set_ad_status, implying a review step. No explicit when-not-to-use or alternative creation path is offered, but the follow-up routing is actionable.

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, so the safety profile is covered. The description adds useful behavioural detail beyond that: the result set is scoped to descendants of the given manager and includes the parent account itself, which affects how the agent interprets the output. Return format and pagination are not discussed, but an output schema exists.

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, zero filler: the first defines what is returned, the second the situation that motivates the call. Front-loaded and easy to scan.

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 one-parameter read-only tool with a full schema, an output schema and readOnly annotations, the description supplies the remaining context (manager context, result scope). It omits what happens when a non-manager ID is supplied, a minor gap for this complexity level.

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% and there is a single parameter, so the schema already documents customer_id thoroughly (digit-only format, accepted variants). The description only echoes the intent ('run this against the manager's customer ID'), adding no format or edge-case detail beyond the schema. Baseline 3.

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 and resource ('Lists all client accounts under a (manager) account') and adds a distinguishing scope detail ('including the account itself'), so it separates itself from a plain customer listing. It does not explicitly contrast with the sibling list_accessible_customers, which covers similar ground, so it stops short of a 5.

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?

Gives a concrete usage context ('when the authenticated user works through an MCC/manager account') and the purpose of the call ('to find the child account IDs to use with reporting and management tools'). It does not name an alternative tool or state when not to use it, so it is clear context rather than 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?

readOnlyHint=true in annotations already establishes this as a safe read. The description adds the output sorting behavior ('Ordered by cost'), which is a genuine trait beyond the annotation, but says nothing about time-range defaults, auth requirements, or rate limits.

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, zero waste, with the resource scope front-loaded and the metric list and ordering compactly attached. Nothing extraneous, though it is not richly informative either.

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?

An output schema exists, so return-value structure need not be described, and the description still adds the metric list and sort order. With full schema coverage and a read-only annotation, the remaining gap is only the absent usage/alternative guidance.

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 all five parameters (customer_id, date_range, start_date, end_date, campaign_id) are already documented in the schema. The description adds no parameter-level meaning, which is the expected baseline when the schema does the heavy lifting.

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 ('Ad-group-level performance report') and enumerates the metrics returned, so the agent knows exactly what this tool produces. The 'ad-group-level' scope inherently distinguishes it from get_campaign_performance and get_keyword_performance siblings, though it never names them.

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?

No when-to-use, when-not-to-use, or alternative routing is given. The agent must infer from the name alone that this is the ad-group granularity counterpart to the campaign and keyword reports. 'Ordered by cost' describes output, not usage.

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 the description adds genuinely useful behavior beyond that: results are ordered by cost descending, and cost/budget fields are in micros requiring division by 1,000,000. This is real operational context, not a restatement of the safety hint.

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 paragraphs, both front-loaded: the metric list first, then the ordering and unit convention. No filler sentences and nothing repeated from the schema.

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?

An output schema exists, so return structure needn't be explained, and the description still covers ordering and unit interpretation. Given the low-complexity read-only nature of the tool, this is close to complete; only the sibling routing to finer-grained reports is missing.

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 baseline is 3, but the description goes further by documenting the micros unit convention for cost and budget fields, which is a non-obvious domain quirk not present in the schema property descriptions.

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 ('Campaign-level performance report') and enumerates the metrics returned (impressions, clicks, CTR, cost, conversions, conversion value, status, bidding strategy, daily budget). The 'campaign-level' scoping implicitly separates it from sibling reports like get_ad_group_performance and get_keyword_performance, though those siblings are never named.

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 is implied by the report name and by the mention of date granularity, but there is no explicit 'use this when...' statement, no exclusions, and no pointer to the ad-group or keyword-level reports that cover the same ground at finer granularity.

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, so the safety profile is covered. The description adds useful context by naming the change sources (users, tools, the server itself), but says nothing about pagination, event granularity, or truncation behavior beyond what the schema implies.

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, front-loaded with the resource and the returned fields, followed by the single use case. 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?

An output schema exists so return values need not be explained, and readOnlyHint covers safety. The description is adequate for a simple read tool, though it could say more about the volume/ordering of events returned.

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% – limit, days_back, and customer_id are all documented in the schema, including the API limits. The description adds no parameter meaning, so baseline 3 applies.

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 resource (recent account changes) with explicit facets: what changed, when, and by whom. It is unambiguous about what the tool returns, but it never differentiates itself from any sibling, which the 5-level requires.

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?

"Useful for a weekly review of account activity" implies a usage context, but there is no guidance on when NOT to use it, what alternatives exist, or prerequisites such as needing a valid customer_id. Usage is only implied rather than stated.

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?

readOnlyHint=true already declares this is a safe read, and the description adds genuinely useful behavioral context by stating the ordering ('by cost, highest first'). It does not mention pagination/limit behavior or how the default 200-row cap interacts with ordering, so it goes modestly beyond annotations but not far.

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 tightly packed sentences, front-loaded with the resource and its granularity, followed by the returned fields and sort order. No filler or redundant restatement of the title.

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?

An output schema exists, so return-value explanation is not required, and the read-only annotation covers the safety profile. The only real gap is that limit/pagination interaction with the cost ordering is never addressed, which is minor for a report 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?

Schema description coverage is 100%, so the schema already documents all six parameters including defaults and formats. The description adds no parameter-level meaning beyond what the schema provides, which is the expected baseline when the schema does the heavy lifting.

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 ('Keyword-level performance report') and enumerates the returned fields, so an agent can tell it is the keyword-granularity counterpart to get_campaign_performance and get_ad_group_performance. It does not name those siblings explicitly, but the granularity is 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?

Usage is implied by the phrase 'keyword-level performance report', but there is no explicit statement of when to prefer this over get_campaign_performance or get_ad_group_performance, nor any prerequisites. The date_range parameter only points back to a sibling's docs rather than giving guidance here.

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, so safety is covered structurally. The description adds genuinely useful behavior beyond that: the caching note ('responses can be cached; they rarely change'), which informs an agent that re-fetching is usually unnecessary. It stops short of describing cache invalidation or return shape, but the output schema covers the latter.

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 tight paragraphs: what it returns, when to use it with the alternative named, and the anti-guessing/caching caveat. Every sentence earns its place and the most decision-relevant content (purpose plus usage) 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 one-parameter discovery tool with a full output schema, annotations covering safety, and 100% parameter coverage, nothing an agent needs in order to call it correctly is missing. Discovery-before-query guidance is exactly the context this tool needs.

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% with a single well-described resource_name parameter, so the baseline is 3. The description reinforces the parameter's domain (resource names like 'campaign', 'ad_group') but largely repeats schema content, and the metrics./segments. prefix note describes output fields rather than the input parameter.

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 (retrieves) and resource (selectable/filterable/sortable fields for a Google Ads resource), plus the scope of what's returned (compatible metrics and segments). An agent can distinguish this discovery/meta tool from the sibling query and mutation tools at a glance.

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?

Explicitly says when to use it ('to find out which fields you can select, filter by, or sort by ... with the `search` tool') and adds a clear directive not to guess fields before constructing a query. The alternative path (the `search` tool) is named, so routing is 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?

readOnlyHint=true already tells the agent this is a safe read. The description adds a genuinely useful trait beyond the annotation — 'ordered by cost' — which tells the agent how results are ranked. Beyond that it is thin: no mention of row limits, pagination, or truncation 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?

Three short sentences, front-loaded with what the resource is and what it is for, with no filler. Nothing is padded, though the brevity leaves room for more concrete routing 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?

An output schema exists, so return values need not be described, and the annotations cover the safety profile. For a read-only report with fully documented params, the description covers what an agent needs; only limit/pagination behavior is left unaddressed.

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%, and each parameter (limit, date_range, start/end date, campaign_id, customer_id) is documented inline in the schema. The description adds no parameter-level meaning beyond that, so the baseline of 3 applies.

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 resource and clarifies its semantics: 'the actual user queries that triggered ads, with the core metrics.' This implicitly distinguishes it from keyword-based siblings, but it never names an alternative, so the differentiation is left for the agent to infer rather than made explicit.

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 main input for finding negative keyword candidates and new keyword opportunities' gives a clear usage context, which is more than most report tools offer. However, it names no alternatives or when-not-to-use conditions (e.g., versus get_keyword_performance), so routing between sibling report tools is still implied rather than guided.

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?

With only destructiveHint=false available, the description must carry the behavioral burden. It discloses that linking causes the asset to serve with campaign ads, but omits key details such as required permissions, whether the operation is idempotent, what happens on validation-only calls, or whether existing links are replaced. These gaps leave the agent under-informed for a 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 a single, front-loaded sentence with no wasted words. It states the action and outcome efficiently, and every clause earns its place.

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 tool has an output schema, so return values need not be described, and the input schema is fully documented. However, for a mutation tool with minimal annotations, the description still lacks important contextual details such as prerequisites, permissions, or side effects. It is adequate but leaves clear gaps.

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 input schema already documents all five parameters in detail, including defaults and examples. The description adds only the example 'call asset' and does not meaningfully expand on parameter meaning beyond the schema. A baseline 3 is appropriate when the schema does the heavy lifting.

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 ('Links') and names both resource types ('asset' and 'campaign'), making the action unambiguous. It also states the outcome ('so it serves with that campaign's ads'), which helps distinguish it from creation tools like create_call_asset. However, it does not explicitly name or contrast any sibling tool, so it falls short of a full 5.

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 the use case by stating the effect on ads, but provides no explicit guidance on when to call this tool versus alternatives, when not to use it, or any prerequisites. It assumes the agent will infer that the asset must already exist and be suitable for linking.

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?

readOnlyHint=true already covers the safety profile, but the description adds a useful formatting detail (10-digit strings, no dashes) that an agent needs when passing IDs onward. It does not mention auth scope or empty-result behavior, so it stops short of full disclosure.

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, front-loaded blocks (purpose, when-to-use, return shape) with no filler, each earning its place.

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?

A no-parameter read tool with annotations and an output schema; the description covers purpose, usage ordering, and ID format, leaving nothing essential unstated.

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 tool takes zero parameters, which is the baseline 4 case; the description correctly implies no filtering input is accepted.

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 (returns) and resource (IDs of Google Ads accounts directly accessible by the authenticated user), with the 'directly accessible' qualifier distinguishing it from hierarchy-style siblings like get_account_hierarchy.

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?

Explicitly says to use it first when the user hasn't supplied a customer ID and explains why ('Most other tools require a valid customer ID'), giving the agent a clear selection rule.

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 readOnlyHint annotation already declares the safe read nature, and the description usefully enumerates what categories of criteria are returned. However, it adds no other behavioral context such as permission requirements, pagination, or scope limits. With annotations carrying the safety profile and an output schema present, this is adequate but not rich.

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 with zero filler. It leads with the action and resource and then lists the relevant criteria categories, every element earning its place.

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 readOnlyHint annotation, full schema coverage, and an existing output schema, the description covers what the agent needs to select and invoke the tool. It could mention scope or ordering, but nothing essential is missing for a simple read-only list operation.

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% and both parameters are documented in the schema itself. The description adds no parameter-level meaning beyond confirming the campaign context, so the baseline 3 applies.

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 (Lists) and resource (a campaign's targeting criteria) and enumerates the criteria categories covered: locations, proximity radii, ad schedules, devices, negative criteria. This is clearly distinguishable from siblings like remove_campaign_criterion (mutation) and unrelated list tools such as list_conversion_actions.

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 is implied by the read-only listing verb and the resource, but the description never states when to use this instead of related tools (e.g., get_campaign_performance) or any exclusions. No prerequisites or context beyond the obvious are provided.

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?

readOnlyHint=true already establishes that this is a safe read. The description adds that the result conveys optimization primacy, which is useful framing, but the enumerated fields largely restate what the output schema already defines and it says nothing about pagination, result volume, or account-scope constraints beyond record count.

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 the what (fields returned) front-loaded and the why (Smart Bidding check) second. No filler, though the field enumeration is slightly verbose without adding much beyond the output schema.

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-value detail is not required, and the description covers purpose, contents, and usage intent for a simple single-parameter read. It is complete enough to call correctly, missing only pagination/volume expectations.

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?

Only one parameter (customer_id) with 100% schema description coverage, so the schema fully documents it. The description adds no syntax, format, or ID-source guidance beyond what the schema provides; baseline 3 applies.

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 (Lists) and resource (conversion actions) and enumerates what is returned: category, type, status, and primary_for_goal. An agent can distinguish it from write siblings like set_conversion_action_primary or set_campaign_conversion_goals at a glance.

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 second sentence gives a concrete usage context — checking what Smart Bidding optimizes toward, e.g. whether phone calls are primary. It does not name an explicit alternative or a when-not-to-use condition, so it stops short 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?

Annotations already declare destructiveHint=true, so the safety profile is known. The description adds meaningful scope disclosure -- removal affects targeting only and leaves ads/keywords/budgets untouched -- which helps the agent reason about blast radius. It doesn't mention irreversibility or validation-only behavior (that lives in the schema).

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 paragraphs, front-loaded with the action and followed by the id-lookup pointer and scope boundary. Every sentence carries information; no 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?

Output schema exists, so return values need no explanation, and the destructive scope is stated. For a mutation tool the description covers what is affected and how to source the id; only minor gaps like reversibility/validation-only guidance remain.

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 all four parameters are documented structurally. The description only indirectly helps by pointing to the id-lookup tool; it adds no format or semantics beyond what the schema already states, so baseline 3 applies.

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 (removes) plus resource (targeting criterion) and scopes it to a single criterion of a campaign, with concrete examples ('wrong location', 'obsolete ad schedule'). Clearly differentiable from create/update siblings and from list_campaign_criteria.

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?

Explicitly routes the agent to `list_campaign_criteria` for obtaining criterion ids, which is a real prerequisite. It also clarifies scope boundaries (does not touch ads, keywords, budgets). No explicit when-not-to-use or alternative removal tools are named, so it stops short 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 readOnlyHint=true annotation covers the safety profile, so the bar is lower, but the description adds nothing beyond what annotations already state. It does not mention rate limits, pagination/limit behavior, permission requirements, or that it is a general read-query escape hatch.

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?

It is a single short sentence with no padding, so it is concise, but the brevity comes at the cost of substance rather than from tight editing of useful 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 generic query tool with three required and three optional parameters manipulated in combination (resource + fields + conditions), the description is far too thin. Although an output schema exists so return values need not be explained, the agent gets no help composing a valid query or routing to more specialized siblings.

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% and all six parameters (fields, resource, conditions, orderings, limit, customer_id) are documented in the schema. The description adds no meaning beyond the schema, so the baseline of 3 applies.

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 essentially restates the tool name and title ("search" → "using the search method") plus a generic "fetches data from the Google Ads API." It does not say what kind of data, what query dialect is used, or how it differs from the many specific sibling tools like get_campaign_performance or list_campaign_criteria.

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 when-to-use guidance at all. With roughly thirty sibling tools, the agent is given no signal about when this generic query tool is preferable to the dedicated report/list tools, nor any prerequisites or exclusions.

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 only supply destructiveHint=false, so the description carries most of the burden. It discloses the critical replacement gotcha (include every window you want covered) and the account time-zone assumption, which an agent would otherwise get wrong. It does not cover auth requirements or response behavior, keeping it short of 5.

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 with zero filler. Purpose is front-loaded, then the two behavioral caveats that matter most. Every sentence earns its place.

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 mutation tool with an output schema present (no need to explain returns) and only a destructiveHint annotation, the description supplies the semantics that matter most: full-window coverage and time zone. Adequate, though it could note interaction with remove_campaign_criterion or validate_only's role.

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 both the schedule entry shape and validate_only are already documented; baseline would be 3. The description adds genuinely new information not in the schema: hours are interpreted in the account's time zone.

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 and resource ('Adds ad schedule criteria to a campaign') and parenthetically clarifies what an ad schedule is (which days/hours ads run). Clear enough to distinguish from siblings like remove_campaign_criterion, though it never names an alternative tool explicitly.

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 meaningful operational context: a campaign with no schedule runs 24/7, and once entries exist ads run ONLY in the listed windows. This tells the agent exactly when and how to use it. It stops short of naming sibling alternatives for removing or listing 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?

The destructiveHint=true annotation already tells the agent this can destroy data, and the schema description carries the key behavioral warning (REMOVED is permanent). The description itself adds nothing beyond restating that it removes an ad — no idempotency, permission requirements, or validate_only behavior 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?

A single front-loaded sentence with zero filler; the verb and resource come first and the three operations complete the picture. Nothing needs trimming.

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?

An output schema exists and the input schema fully documents all five parameters including the risky REMOVED option, so the description need not repeat them. It is adequate for a mutation tool, though a sentence on validate_only or confirmation workflow would have closed the remaining gap.

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%, including the critical REMOVED permanence note and validate_only semantics, so the baseline is 3. The description lists the operations but supplies no parameter-level detail beyond what the schema 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 names a specific resource (an ad) and enumerates the three operations it performs (pause, enable, remove), so an agent can distinguish it from set_campaign_status and set_keyword_status by resource. It is clear, though it never explicitly contrasts itself with those siblings.

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?

No when-to-use guidance, no prerequisites, and no mention of alternatives. The only routing signal is the resource name. An agent must infer that this tool applies only to ads and not ad groups or campaigns.

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?

Only destructiveHint=true is annotated, and the description adds crucial behavioral detail beyond that: this switches the campaign into campaign-level goal configuration (a mode change), and it must be called with every category/origin combination in the account, marking non-target goals biddable=false. That replace-style requirement is exactly the kind of consequence the annotation alone cannot 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?

Two sentences, front-loaded with the override semantics followed by the use-case trigger and the enumeration requirement. Dense but every clause carries information; there is no 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 destructive mutation tool, the description covers purpose, the when-to-use condition, and the non-obvious completeness requirement for the goals array. An output schema exists, so return values need no explanation, and nothing needed to call this correctly is missing.

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 baseline is 3, but the description adds real semantic value: the goals array must enumerate every existing category/origin pair rather than just the desired ones, which is not evident from the schema alone. It does not add format detail beyond the enum examples already in 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?

States a specific verb (overrides) and resource (per-campaign conversion goals for Smart Bidding), and immediately scopes the behavior as distinct from account-level primary/secondary settings. An agent can distinguish this from set_conversion_action_primary without opening either schema.

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?

Gives an explicit triggering scenario: use when account-level conversion actions cannot be edited (system-generated 'Local actions') but the campaign must optimize only to real outcomes. It contrasts with account-level configuration, though it does not name a sibling tool as the alternative, so it stops just short 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 destructiveHint=true annotation already tells the agent this tool can cause irreversible change, so the bar is lower. The description reinforces this with 'removes' but adds no supplementary context such as permission requirements, reversibility of pause/enable, or rate limits. It does not contradict the annotation.

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 six-word sentence with no filler, and the operation verb leads. Every word earns its place; nothing is buried or repeated.

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?

An output schema exists and full parameter coverage means the return value and inputs are handled elsewhere, so the description need not restate them. The main remaining gap is the absence of any permission or confirmation guidance for a destructive mutation, though the destructiveHint annotation and the schema's permanence warning partially compensate.

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 all four parameters are already documented, including the critical 'REMOVED is permanent — confirm with the user' note and the validate_only dry-run flag. The description adds nothing beyond what the schema provides, so the baseline of 3 applies.

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 set (pauses, enables, removes) against a specific resource (campaign), so the agent knows exactly what operation this performs. It distinguishes itself from siblings like set_ad_status and set_keyword_status by resource, though it does not name any alternative explicitly.

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 no when-to-use guidance, no prerequisites (e.g. required account permissions), and no routing to alternatives such as create_campaign or update_campaign_budget. The only usage constraint — that REMOVED is permanent and needs user confirmation — lives in the schema, not the description.

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 only declare destructiveHint=true; the description adds prerequisites and failure modes the annotations cannot convey: the bidding-strategy requirement, the ~30-conversion history floor, and delivery throttling from setting tCPA too early or too low. It stops short of saying what happens on an invalid campaign or whether the change is reversible.

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, zero filler. The operation is stated first and the risk guidance follows, which is the right front-loading for a mutation 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 an output schema present, return values need no explanation, and the description covers the bidding-strategy prerequisite and the conversion-history threshold. It could say more about error behavior on a non-Maximize-Conversions campaign or whether validate_only is worth using first.

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% with units and meaning already documented for target_cpa, campaign_id, customer_id and validate_only. The description adds only indirect meaning ('too low throttles delivery') and no syntax or format detail, so the baseline 3 applies.

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 (sets/updates), a specific resource (target CPA on a campaign), and an explicit precondition (campaign must use Maximize Conversions bidding). No sibling tool touches tCPA, so an agent can route to it immediately.

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?

Gives a concrete when-to-use condition ('only do this once the campaign has ~30+ conversions of history') plus a warning about the consequence of premature or low values. It does not name an alternative tool for campaigns on other bidding strategies, which is the only gap.

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 only provide destructiveHint=true, which is somewhat counterintuitive for a setting toggle but acknowledges mutability. The description adds valuable context about what primary vs secondary means, the error behavior for system-generated actions, and the optimization implications. It doesn't cover reversibility or exact API error formats, but provides solid beyond-annotation detail.

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?

Efficiently front-loads the core action in the first sentence, then explains the semantic impact, provides a discovery hint, and notes an edge case—all in three concise sentences with zero waste.

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 a boolean mutation tool with full schema coverage and an output schema, the description is nearly complete. It covers purpose, side effects, discovery, and a known limitation. A bit more on idempotency or required permissions could push it to 5, but it's strong.

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 parameters are fully documented in the schema. The description adds no parameter-specific syntax or format details beyond what's in the schema, though it does clarify the primary parameter's meaning in context. 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?

States a specific verb (sets/marks) and resource (conversion action primary/secondary), and explains the domain meaning (Smart Bidding optimization target). Clearly distinguishable from siblings like list_conversion_actions or set_campaign_conversion_goals.

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 clear context for why you'd use it (optimizing toward real outcomes vs soft actions) and points to list_conversion_actions for finding IDs. However, it doesn't explicitly state when NOT to use it or name direct alternatives for setting conversion goals.

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 destructiveHint annotation already signals this is a mutating, potentially destructive call, so the bar is lower. The description's warning that REMOVED is permanent adds context, but that same warning is already present verbatim in the status parameter's schema description, so the incremental value is small; it says nothing about permissions or reversibility of ENABLED/PAUSED.

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 zero filler and the core action front-loaded. The prerequisite lookup cue follows the action statement rather than burying it.

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?

An output schema exists, so return values need no explanation, and the destructive hint plus the permanence note cover the safety profile. What remains thin is the distinction between ENABLED and PAUSED effects on an existing REMOVED keyword, which is left to the agent to infer.

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 baseline is 3, but the description does contribute one real thing the schema does not: the origin of criterion_id, pointing the agent to get_keyword_performance and the ad_group_criterion.criterion_id field. That materially helps fill the most obscure required parameter.

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 set (pauses, enables, removes) and the exact resource (a keyword), which cleanly separates it from set_ad_status and set_campaign_status in the sibling list. An agent can pick the right status-mutation tool without reading any schema.

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 second sentence gives concrete workflow guidance: find criterion ids via get_keyword_performance before calling, and it names the exact field (ad_group_criterion.criterion_id). It does not state exclusions or alternatives for the status change itself, but the sequencing advice is genuinely actionable.

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, so the safety profile is covered. The description adds that the operation is a name-to-ID resolution, but says nothing about ambiguous or unresolved names, rate limits, or partial-match behavior, so it adds only modest context beyond 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 tight sentence with the core transformation front-loaded and the downstream dependency appended. Every clause carries information, though the example pair is mildly redundant.

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 lookup with an output schema present and read-only annotations, the description covers the essential purpose and integration point. Only edge-case behavior (no match, ambiguous match) is left unaddressed.

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 baseline is 3. The examples ('Phoenix, Arizona') clarify the expected granularity of location_names slightly, but country_code scoping and array/format expectations are already documented in 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?

States a specific verb ('resolves') and a precise transformation (human-readable location names -> Google Ads geo target constant IDs), with concrete examples. It is clearly distinguishable in function from the sibling tools, though it does not name a sibling it is not.

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?

Explicitly ties the tool to its downstream consumer: 'for use with add_location_targeting', which tells the agent where this fits in the workflow. It stops short of stating when not to use it or how it relates to other lookup 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 only annotation is destructiveHint=true, and the description adds nothing beyond it. It does not disclose that setting status to REMOVED is irreversible or what other side effects the update has, so for a destructive mutation the description is thin relative to the safety profile it should explain.

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?

One tight sentence with the action and target front-loaded. Nothing is wasted, though it is arguably too terse to carry the needed behavioral context.

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 a rich schema and an output schema present, return values need not be explained. However, a destructive update tool should describe the irreversible REMOVED transition and the effect of applying only one of the two optional fields, which is missing.

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 already documents status, cpc_bid, ad_group_id, customer_id, and validate_only. The description restates the two mutable fields without adding format, validation, or interaction detail, so 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?

States a specific verb (Updates) and resource (ad group) plus the two mutable fields (status, default max CPC bid). This clearly separates it from create_ad_group and get_ad_group_performance, though it doesn't call out how it differs from sibling status setters like 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?

No when-to-use or when-not-to-use guidance is given, and no mention of prerequisites (e.g. that at least one mutable field should be supplied, or that validate_only is available). The agent must infer usage from the parameter names alone.

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 declare destructiveHint=true so the agent knows this mutates state; the description reinforces this with 'changes ... an existing campaign budget.' It adds the id-discovery path but says nothing about permission requirements, reversibility, or what happens to the prior amount, so it adds only modest value beyond 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 tight sentences, front-loaded with the core action, followed by the id-discovery hint. No filler or restatement of the title.

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 no explanation, and the required parameters are documented in the schema. The description covers the main practical gap (obtaining budget_id) but omits any note on the effect of validate_only or the mutation's scope, leaving a small gap for a destructive 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?

Schema coverage is 100%, so the baseline is 3, but the description goes beyond the schema's generic 'numeric id of the budget' by explaining where that id comes from (search tool / campaign_budget resource name), which materially helps correct invocation.

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 (changes), resource (campaign budget), and the exact field affected (daily amount), scoped to an existing budget. This cleanly distinguishes it from the sibling create_campaign_budget and read-only list 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?

Gives concrete preconditions for calling it: it tells the agent where to obtain budget_id via the `search` tool (campaign_budget.id) or a campaign's campaign_budget resource name. It does not, however, state when not to use it or name an alternative update path.

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