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

Annotations already declare readOnlyHint=false, idempotentHint=false, and destructiveHint=false, so the description need not re-state that it's a mutation. However, the description adds only the scope ('one ad group') and does not disclose whether the negatives are additive or replace an existing set, or any other behavioral nuance. With annotations providing the safety profile, the description's contribution is minimal.

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 primary action and scope, followed by a targeted pointer to an alternative. No filler or redundant information; highly efficient.

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 the output schema present, return values are covered. The description plus schema cover the essential call parameters and the primary alternative. The only notable gap is clarity on whether negatives are appended or replaced, which is a behavioral detail rather than a critical invocation requirement. Overall, the description is adequate for correct usage.

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 every parameter has a clear description, so the tool description does not need to elaborate on parameters. The baseline of 3 applies because the schema carries the semantic weight; the tool description adds no parameter-specific value beyond that.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action ('Adds negative keywords to one ad group') with a clear resource scope (one ad group). It explicitly contrasts with campaign-wide negatives, naming the sibling tool, so an agent can easily distinguish it from campaigns.add_campaign_targeting.

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 directly says 'For campaign-wide negatives use campaigns.add_campaign_targeting,' which is an explicit when-not and alternative. It implies when to use this (ad-group-level negatives) and the scope constraint 'one ad group.' This is clear and 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 indicate readOnlyHint=false, idempotentHint=false, and destructiveHint=false, and the description's 'adds' is consistent with a mutating but non-destructive operation. However, the description adds no behavioral context beyond that: it does not mention duplicate handling, default status behavior, validate_only dry-run capability, or consequences for existing keywords. It merely restates the basic action.

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, clear, front-loaded sentence: 'Adds keywords to an ad group.' It contains no filler or repetition and is appropriately sized for such a straightforward operation.

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 schema and output schema carry most of the burden, so an agent can likely invoke this tool correctly. Still, the description lacks important context around duplicate handling, positive-versus-negative keyword distinction, and when to prefer sibling tools, leaving meaningful gaps for selection and behavior.

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 the schema already provides rich parameter details such as match type guidance, CPC bid semantics, and validate_only behavior. The description itself contributes no parameter-level meaning, so the baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb and resource: 'Adds keywords to an ad group.' This is specific and unambiguous. However, it does not differentiate from the sibling tool ad_groups_add_ad_group_negative_keywords, so an agent may need to inspect names or schemas to determine which 'add keywords' tool is appropriate.

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 guidance about when to use this tool versus alternatives. The description does not mention that this is for positive keywords, nor does it contrast with ad_groups_add_ad_group_negative_keywords or ad_groups_set_keyword_status. Only the schema's keyword-level note about tight themes provides implicit usage context, but not explicit selection criteria.

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

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

Annotations already indicate a non-read-only, non-idempotent mutation. The description adds meaningful behavioral context: ad groups default to ENABLED while the campaign is PAUSED, and nothing serves until the campaign is enabled with confirm=true. This goes beyond what annotations provide, though it does not cover failure modes or auth requirements.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no filler: the first front-loads the purpose, and the second explains the non-obvious default behavior. 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?

Given the rich schema, output schema, and annotations, the description covers the key non-obvious behavior (default ENABLED status and the PAUSED campaign gating). It does not need to restate return values or parameter details because those are already present in structured fields.

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 all seven parameters already documented in the input schema. The description adds no parameter-specific meaning beyond what the schema provides, so the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action ('Creates'), a specific resource ('Search ad group'), and a location ('inside a campaign'). This clearly distinguishes it from sibling tools that update status, update bids, or add keywords.

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 intended use is implied by the verb 'Creates' and the campaign context, but the description does not explicitly contrast with sibling tools such as ad_groups_set_ad_group_status or ad_groups_update_ad_group_cpc_bid. The PAUSED campaign / confirm=true note provides useful workflow context, but not explicit when-to-use versus alternatives.

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 flag the operation as destructive and non-idempotent. The description adds the key operational requirement that REMOVED requires confirm=true and explicitly names the affected resource. This is meaningful context beyond what the annotations alone provide, with no contradiction.

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 one compact sentence with the action list front-loaded and the critical confirm requirement stated immediately after. Every word earns its place; there is no filler or redundant elaboration.

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 6-parameter mutation with full schema coverage and an output schema, the description captures the essential operation and the safety precondition. It does not describe response shape or permissions, but those are reasonably covered by the output schema and annotations. The tool can be invoked correctly from this description.

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 parameters are already well documented. The description repeats the status enum and the confirm requirement without adding materially new semantic detail beyond the schema. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a precise action set ('Enables, pauses or removes') on a specific resource ('an ad group'), which maps directly to the tool name and the status enum. It is easy to distinguish from sibling tools like ads_set_ad_status, campaigns_set_campaign_status, and ad_groups_set_keyword_status.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the use case: changing an ad group's lifecycle status among ENABLED, PAUSED, or REMOVED. However, it gives no explicit guidance on when to choose this over the sibling status tools, nor any exclusions or prerequisites. This is adequate but leaves routing to inference.

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 flag this as destructive, non-read-only, and non-idempotent; the description does not contradict those hints. It adds the operational guardrail that REMOVED requires confirm=true, though that is also present in the schema, and it does not describe the permanence or downstream effects of removal.

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 short and purposeful; the action and the one critical prerequisite are front-loaded. There is no filler or unnecessary repetition of the schema's enum values beyond the confirm caveat.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple mutation tool with output schema, annotations, and 100% schema coverage, the description covers the core operation, the destructive-removal caveat, and the ID-lookup workflow. The only meaningful gap is explicit routing to or away from sibling keyword tools.

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. The description goes beyond the schema by telling the agent exactly how to obtain criterion_ids ('Find criterion ids with search on ad_group_criterion'), which removes ambiguity about how to populate the key 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?

The description opens with a specific verb set and an unambiguous resource: 'Pauses, enables or removes keywords (ad group criteria)'. It clearly distinguishes this status-mutation tool from sibling tools that add keywords or set ad-group/ads status. The parenthetical maps the non-obvious Google Ads term to keywords.

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 intended use is implied by the action statement, and the description supplies a useful prerequisite: find criterion ids via ad_group_criterion. However, it does not explicitly say when to choose this over alternatives such as ad_groups_add_keywords or ad_groups_set_ad_group_status, nor does it state any 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 already declare destructiveHint=true and readOnlyHint=false. The description adds the MANUAL_CPC scope and the confirm=true prerequisite, reinforcing a key behavioral condition beyond the annotations. Though 'confirm' is also in the schema, the description's framing emphasizes it as essential to applying the change.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loads the core action, and ends with the key prerequisite. Every word earns its place with no fluff 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?

Given the output schema and annotation coverage, the description captures the core behavior, scope, and prerequisite. It does not detail optional parameters like validate_only or login_customer_id, but those are documented in the schema, and the MANUAL_CPC restriction is the key additional context an agent 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 description coverage is 100%, so all parameters are already documented. The description adds no new parameter semantics beyond referencing 'default max CPC', which maps to default_cpc_bid but adds no format or constraints. Baseline 3 is appropriate because the schema does all 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 names a specific verb ('changes'), resource ('ad group'), and field ('default max CPC'), scoped to MANUAL_CPC campaigns. This clearly distinguishes it from siblings like ad_groups_set_ad_group_status or ad_groups_create_ad_group.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description states the applicable campaign type (MANUAL_CPC) and requires confirm=true, giving clear context for when to use the tool. It does not name explicit alternatives or exclusions, but the condition is sufficient for selection.

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

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

Beyond the annotations, the description reveals that copy is validated locally against Google's limits before the API callpa and explains the ENABLED default as intentional because the campaign is PAUSED. This adds meaningful behavioral context without contradicting the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded: purpose first, then validation details, then a brief strategic recommendation. Every sentence earns its place; the line breaks make the constraints 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?

With a complete input schema, an output schema, and annotations, the description covers the remaining behavioral essentials: local validation, default status rationale, and content best practices. Nothing critical is missing for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema coverage is 100%, but the description adds value by spelling out validation criteria such as headline and description count ranges, character limits, display path constraints, and uniqueness rules. These constraints are not all present in the schema descriptions, so the description compensates usefully.

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 opening sentence uses a specific verb and resource: 'Creates a responsive search ad in an ad group.' This clearly distinguishes the tool from its siblings, especially ads_update_responsive_search_ad, by establishing creation as the operation.

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 concrete guidance on how to call the tool well: aiming for 8-15 headlines and 4 descriptions to improve ad strength, and noting limits like no all-caps and no '!' in headlines. It does not explicitly name alternatives or exclusions, but the create-vs-update distinction is evident from the name and sibling list.

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 signal readOnly=false and destructive=true. The description adds a meaningful operational constraint by warning that REMOVED requires confirm=true, which is a behavioral gotcha beyond the annotation metadata. It does not contradict the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two short sentences with the core action front-loaded and the important exception stated immediately after. Every word earns its place, and there is no filler or redundant elaboration.

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 that annotations cover destructive/read-only semantics, the schema documents all 7 parameters including validate_only, and an output schema exists, the description provides the key operational gotcha. It is slightly thin on when to prefer this over sibling status tools, but otherwise sufficient for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The only parameter-related detail in the description, 'REMOVED needs confirm=true,' largely restates what the schema already says for the confirm field, adding no new semantic meaning.

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: 'Enables, pauses or removes an ad.' It clearly names the exact state transitions the tool performs. However, it does not explicitly differentiate this from sibling status tools like ad_groups_set_ad_group_status, so it stops short of full sibling distinction.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The action itself implies when to use the tool: any time an ad's status must be changed. However, there is no explicit when-to-use guidance, no exclusions, and no mention of alternatives, so the agent must infer routing from the tool name and context signals.

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 signal this is a mutating operation (readOnlyHint=false), but the description adds the non-obvious side effect that 'Editing an ad resets its performance history in the UI.' This is valuable behavioral context beyond what the annotations or schema provide. It does not contradict the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences with no wasted text: the first states the core action, the second explains the critical full-list behavior, and the third gives the key trade-off and alternative. It is compact, front-loaded, and 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 complex update tool with 9 parameters, 100% schema coverage, an output schema, and useful annotations, this description covers the essential behavioral, usage, and side-effect information. It does not need to repeat schema details, and the combination of description plus structured fields leaves no important gap for an agent to call this tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3, but the description enhances parameter understanding by explaining that headlines and descriptions are replaced as whole sets and that the caller must pass the full intended list. The schema says 'Full replacement list, or omit to keep current,' and the description reinforces the practical implication, which is especially important for array-valued parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Replaces the copy of an existing responsive search ad.' It clearly identifies the operation as an update to an existing ad rather than a creation, and the additional sentence about A/B tests distinguishes it from ads_create_responsive_search_ad. This is unambiguous and differentiates the tool from its closest sibling.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly tells the agent when to use this tool (to replace copy on an existing ad) and when not to: 'for A/B tests prefer creating a second ad in the same ad group.' It also gives a critical usage instruction that replacement sets must be passed whole. This is direct, actionable guidance that prevents common misuse.

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

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

The description accurately describes a mutating create-and-attach operation, consistent with readOnlyHint=false and destructiveHint=false. However, it does not add behavioral context such as duplicate handling, partial-failure behavior, or the validate_only dry-run skipping the linking step; those details are left to the schema and 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 concrete examples and no filler. It economically states both the creation and the attachment behavior.

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 full parameter coverage, an output schema, and annotations covering the safety profile, so the call itself is fully actionable. The main gap is lack of routing guidance against the similar assets_add_sitelinks tool, but that does not prevent correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, including constraints for callouts (2-20 phrases, max 25 characters, no trailing punctuation) and the validate_only dry-run behavior. The description's examples illustrate the callouts parameter but add no semantic information beyond what the schema already provides, so the baseline of 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), resource (callout assets), and target (campaign). It is clearly distinguishable from the sibling assets_add_sitelinks tool because it names callouts specifically, not generic assets.

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 no explicit when-to-use or when-not-to-use guidance, and does not mention the similar assets_add_sitelinks tool. The intended usage is implied by the action and quoted callout examples, but an agent is not told how to choose between callout assets and other asset types.

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 indicate this is a non-read-only, non-idempotent mutation, so the description does not need to restate that. It adds useful context by noting that the sitelinks are attached to a campaign, but it does not go further into behavior like validation results or effects on existing assets.

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 core purpose and followed by an actionable tip. Every sentence earns its place and there is no redundant wording.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the rich input schema, output schema, and annotations, the description provides the key operational detail an agent needs: the action, the target, and a best-practice count. It is slightly brief but sufficient for a moderate-complexity 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 parameters are fully documented in the schema. The description adds one small recommendation about the number of sitelinks (at least 4), which is useful but does not substantially compensate or add beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb plus resource: it creates sitelink assets and attaches them to a campaign. This clearly differentiates it from sibling tools like assets_add_callouts and generic asset creation tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives a clear use case and adds a practical recommendation (add at least 4 sitelinks for full effect). However, it does not explicitly compare against alternatives such as assets_add_callouts or explain when to prefer this tool over another.

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

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

Annotations already cover read-only and destructive safety, and the description adds meaningful lifecycle context: creating the action alone is insufficient; the tag must be fetched and installed. This goes beyond the schema and helps the agent anticipate follow-up behavior without contradicting the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences front-load the core purpose and then provide the essential next step. Every sentence earns its place and no filler is present.

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 10-parameter schema fully described and an output schema present, the description does not need to restate return values. It completes the operational picture by telling the agent the required follow-up (tag install via GTM or site snippet).

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 carries parameter meaning. The description adds no extra parameter-level detail, which aligns with the baseline 3 for fully covered schemas.

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, resource, and scope: 'Creates a website conversion action,' with a parenthetical clarifying its role ('the thing bidding optimises for'). This is immediately distinguishable from sibling asset tools like assets_add_callouts or assets_add_sitelinks.

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 clearly frames creation as the first step of a two-step workflow by instructing the agent to fetch the tag via search and install or fire it through GTM afterward. It does not explicitly enumerate when to avoid this tool or name alternatives, so it lacks a full when/when-not specification.

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 indicate this is mutating (readOnlyHint=false), not idempotent, and not destructive. The description's 'Adds' is consistent with those annotations and clarifies that the operation is additive, but it adds little behavioral context beyond that—no mention of duplicate behavior, validation, or what happens to existing targeting.

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 that communicates the verb, the objects, and the scope without waste. Every word contributes meaning and 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?

Given the rich input schema (100% parameter coverage) and the presence of an output schema, the one-sentence description is largely sufficient to orient an agent. It clearly identifies the operation and scope, though it could be more complete by noting when the sibling ad-group-level or removal tools should be used instead.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all 8 parameters. The description's mention of 'locations, languages and campaign-level negative keywords' mirrors the parameter names and adds no new semantic detail beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Adds') with a clear resource: 'locations, languages and campaign-level negative keywords to a campaign.' This specifies both the object and the scope, and 'campaign-level' distinguishes it from sibling tools like ad_groups_add_ad_group_negative_keywords and campaigns_remove_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?

The intended use is implied: use this tool when adding locations, languages, or campaign-level negative keywords to a campaign. However, it does not explicitly state when not to use it or point to alternatives such as ad_groups_add_ad_group_negative_keywords for ad-group-level negatives or campaigns_remove_campaign_criteria for removals.

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 sparse (readOnly=false, idempotent=false, destructive=false), so the description carries the behavioral burden. It discloses a key non-obvious behavior: the campaign is always created PAUSED and must be enabled later. This adds meaningful context beyond the structured annotations, though it could also mention failure/side-effect 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?

The core behavior is front-loaded in the first sentence, and the second sentence is a dense, actionable lifecycle list. Every clause earns its place; there is no filler or repetition of schema 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 15-parameter create tool with a full output schema, the description supplies the missing operational context: paused-by-default state, prerequisite budget step, and the full path to activation. Combined with the schema, an agent has enough to invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description does not add parameter-level meaning beyond what the schema already provides; the workflow sequence references budget_id implicitly, but the schema already states budget_id must come from create_campaign_budget.

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 Search campaign, always PAUSED.' It also distinguishes itself from siblings by tying enablement to set_campaign_status, and the lifecycle makes the difference from create_campaign_budget and update_campaign clear.

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 explicit workflow guidance: create_campaign_budget -> create_campaign -> add_campaign_targeting -> ... -> set_campaign_status(ENABLED, confirm=true). This tells an agent exactly when to call it and what comes next. It doesn't explicitly say 'use campaigns_update_campaign for existing campaigns,' but the create/update distinction is clear enough.

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 indicate this is a write operation (readOnlyHint=false), non-idempotent, and non-destructive. The description adds the workflow context 'Do this before create_campaign' but no additional behavioral details such as side effects, duplicate handling, or validation behavior. This is acceptable because the annotations carry the safety profile, but the description adds only minimal extra 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?

The description is two short sentences with no redundant wording. The primary action is stated first, and the prerequisite is added in a single, clear follow-up sentence. Every word 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?

Given that the schema fully documents all parameters and an output schema exists, the description only needs to convey purpose and workflow context, which it does. The prerequisite relationship with create_campaign is a key piece of context that is present. It could be slightly more complete by naming the update alternative, but it is not a significant 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%, so all seven parameters are already documented in the input schema, including constraints like the daily amount cap and unique budget name. The description itself adds no parameter-level information, so it meets the baseline for a fully documented schema without adding extra value.

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 ('Creates') and resource ('campaign budget'), making the core function clear. It also signals the relationship to campaigns_create_campaign by saying 'Do this before create_campaign,' which helps distinguish it from the campaign creation sibling. However, it does not explicitly differentiate from campaigns_update_campaign_budget, relying on the name to carry that distinction.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides a clear usage condition: create the budget before creating a campaign. This is valuable sequencing guidance. It does not mention when to use an alternative like campaigns_update_campaign_budget, but the prerequisite context is sufficient to guide basic 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 destructiveHint=true and readOnlyHint=false, so the description's 'removes' is consistent. The description adds valuable behavior beyond annotations by explicitly requiring confirm=true for the operation to take effect, which is not captured in the annotations. It also provides a hint on how to locate criterion ids, offering extra practical guidance on the process.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two concise sentences with no fluff. The main action is front-loaded, and the critical requirement (confirm=true) is stated immediately. The additional hint about finding ids is useful and completes the purpose without redundancy. Every word 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 destructive operation with an output schema present, the description does not need to explain return values. It covers the main requirements (confirm flag, how to find ids) and the core action. Missing details like validation behavior or login_customer_id are likely standard across sibling tools and not critical for correct invocation. The description is sufficiently complete for an agent to call this tool correctly in most scenarios.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, meaning the description does not directly explain parameters. The description indirectly references 'criterion id' (criterion_ids) and 'confirm=true' (confirm), giving some semantics for two of the six parameters, but it leaves customer_id, campaign_id, validate_only, and login_customer_id unexplained. With such low coverage, the description should compensate more thoroughly; it only partially does.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('removes') and the resource ('campaign criteria'), and even lists the types of criteria (locations, languages, negatives). It distinguishes itself from sibling tools like 'campaigns_add_campaign_targeting' by explicitly indicating removal, though it does not name the alternative directly. This is clear and specific enough for an agent to know what it does.

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 some usage context by stating the prerequisite of finding criterion ids via a search on campaign_criterion and the requirement to set confirm=true. However, it does not explicitly instruct when to use this tool versus alternatives (e.g., when to remove versus add or update criteria), leaving the decision partly to inference. There is no mention of when not to use it or what other tools to consider.

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

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

The description adds meaningful behavioral detail beyond the destructiveHint annotation: it explicitly states REMOVED is permanent, PAUSED only stops spend immediately, and without confirm=true the call returns a validated preview rather than applying the change. This fully discloses the tool's side effects and confirmation guard.

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 brief and front-loaded with the primary purpose. Every sentence adds necessary behavioral information, and the two-paragraph structure keeps the core action and critical nuances separate without wasted words.

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 rich input schema, output schema, and annotations, the description covers the essential behavioral nuances an agent needs to invoke the tool safely: permanence, immediate spend effects, and confirmation requirements. No critical invocation context 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. The description adds value by explaining the interaction between status and confirm: ENABLED and REMOVED require confirm=true, while without it the agent gets a validated preview. This goes beyond the schema's simple boolean 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?

The description opens with a specific verb and resource: 'Enables, pauses or removes a campaign.' This clearly distinguishes the tool from sibling status tools like ad_groups_set_ad_group_status and ads_set_ad_status by naming the campaign resource directly.

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 clear context for when each status is appropriate: PAUSED applies immediately and only stops spend, ENABLED starts spend, and REMOVED is permanent. It does not explicitly name alternative sibling tools, but the resource specificity plus status semantics provide clear usage guidance.

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

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

The readOnlyHint annotation already covers the safety profile, and the description consistently describes a non-mutating lookup. It adds a useful sequencing hint, but it does not disclose other behavioral traits such as response size, matching behavior, or error cases. The output schema covers some of this, so a middle score is appropriate.

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. The core purpose is front-loaded, and the workflow instruction is directly appended. Every word 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 read-only lookup tool with four documented parameters and an output schema, the description covers what an agent needs to select and invoke it correctly. The usage hint completes the picture by clarifying where it fits in the broader campaign-targeting workflow.

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 parameters including defaults and examples. The description adds no additional parameter-level meaning beyond restating that place names map to geo target IDs, which is expected at the baseline.

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 ('Looks up') and resource ('geo target ids for place names'), making the tool's function immediately clear. It also distinguishes itself from the sibling campaigns_add_campaign_targeting by framing this as the lookup step in that workflow.

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?

'Use before add_campaign_targeting' explicitly tells the agent when this tool fits in the workflow. This is direct, actionable guidance that prevents misordering the lookup and the subsequent targeting step.

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 readOnly=false, idempotent=false, destructive=false. The description adds useful behavioral context beyond that: bidding strategy changes are intentionally excluded to avoid disturbing learning history. This explains why a seemingly obvious operation is not available.

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 primary actions and ending with a useful design rationale. No filler or repetition of schema details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the rich schema, output schema, and annotations, the description is sufficient for an agent to understand scope and exclusions. It could mention that unspecified fields remain unchanged, but that is largely implied by the update semantics and not a critical 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%, so the schema already documents all eight parameters individually. The description adds a high-level semantic grouping (rename, dates, budget) but no new parameter-level details or constraints beyond what the schema provides. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: it renames a campaign, changes dates, or reassigns it to another budget. It distinguishes this from sibling tools like campaigns_set_campaign_status and campaigns_update_campaign_budget by naming the exact campaign-level fields.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly names a key when-not-to-use condition: bidding strategy changes are deliberately excluded, and the alternative — creating a new campaign — is given. This is clear routing guidance for an agent deciding between this tool and campaigns_create_campaign.

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

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

Annotations already convey destructiveHint=true and readOnlyHint=false. The description adds meaningful behavioral context beyond the annotations: the two-phase commit behavior ('Needs confirm=true to apply'), implying that without confirm the change is only previewed. This helps an agent understand that invocation without confirmation won't mutate state, which annotations alone do not capture.

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, 15 words, with the core action front-loaded and the critical behavioral gate (confirm=true) stated immediately after. Every clause earns its place; 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?

For a destructive update tool with a 6-parameter schema at 100% coverage, an output schema, and annotations carrying the safety profile, the description covers the one critical behavioral nuance an agent must know (the confirm gate). It could additionally clarify interplay between validate_only and confirm, but the schema already documents both fields, so the description is adequately 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 every parameter (confirm, budget_id, customer_id, daily_amount, validate_only, login_customer_id) is already documented in the input schema. The description itself adds no parameter-level detail. Per calibration, the baseline of 3 applies 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 states a specific verb and resource: 'Changes the daily amount of an existing budget.' It clearly identifies the target (budget daily amount) and distinguishes itself from siblings like campaigns_create_campaign_budget (creation) and campaigns_set_campaign_status (status changes). It doesn't explicitly name sibling alternatives, so it loses the top point, but the action 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?

The description offers no guidance on when to choose this tool over alternatives like campaigns_create_campaign_budget or campaigns_update_campaign. The 'Needs confirm=true to apply' is a prerequisite, not a usage-context signal. No exclusions, no alternative routing, and no conditions 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?

Annotations declare readOnlyHint=true, which aligns with the description's read-only nature. The description adds value beyond annotations by noting that it returns only directly accessible customershare, implying a permission filter, and that the output is a list of IDs (though this is also in the output schema). It does not contradict annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, with a brief purpose statement and a usage hint, followed by a return type section. It is front-loaded with the key action and avoids unnecessary detail.

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 parameterless tool with a simple output (a list of strings), the description is fully sufficient. It explains what the tool does, when to use it, and what it returns. The output schema already documents the return type, so no additional return detail is needed.

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 has zero parameters, so there is no parameter semantics to clarify. The description correctly focuses on the output and usage context, which is appropriate for a parameterless tool.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it returns IDs of customers directly accessible by the authenticated user, with a specific verb ('Returns') and resource ('customers'). It is distinct from siblings like search_search and metadata_get_resource_metadata, as it lists customer IDs rather than performing search or fetching metadata.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly tells the agent to use this tool first to discover customer IDs if the user hasn't provided one, and notes that most other tools require a valid customer ID. It does not explicitly mention when not to use it or name alternatives, but the guidance is clear enough for this 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?

The annotation readOnlyHint=true already covers the safety profile, and the description complements it by disclosing the response contents (fields, metrics, segments) and the naming convention for metrics/segments. It also adds an operational trait: 'responses ... should be cached, as they don't change frequently'. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose and adds concise, actionable guidance. There is minor redundancy: the first sentence says 'including compatible metrics and segments' and the third sentence repeats that metrics and segments can be selected. Still, it is well-structured and every section adds value.

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 metadata-lookup tool with an output schema and readOnlyHint annotation, the description covers everything an agent needs: what the tool returns, naming conventions, mandatory usage before querying, and caching guidance. No significant gaps remain for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already describes both parameters comprehensively (100% coverage), so the description need not repeat them. It adds a small amount of extra context with examples like 'campaign', 'ad_group', but this does not significantly exceed what the schema provides. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Retrieves') and names a clear resource: the selectable, filterable, and sortable fields for a Google Ads resource, including metrics and segments. This clearly distinguishes the tool from the siblings: search_search executes queries, while this tool provides metadata for building 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?

The description explicitly states when to use the tool: before constructing a query for the `search` tool, and it warns 'Do not guess fields, you MUST use this tool to discover them'. This gives the agent an unambiguous directive and contextual placement relative to the sibling search tool.

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

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

The only annotation is readOnlyHint=true, which already tells the agent this is a safe read operation. The description adds no additional behavioral context—nothing about pagination, limits, error handling, or response format. It fails to enrich the annotation-provided information.

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 only one sentence and is technically concise, but it is under-specified to the point of being nearly useless. It does not front-load critical information or structure the content in a way that helps an agent understand the tool's scope. The brevity is a deficiency, not a virtue.

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?

This is a 7-parameter tool with 3 required parameters, yet the description provides no context about what the tool actually accomplishes beyond a generic 'search'. It lacks any explanation of the query syntax, the relationship between fields and resource, or expected output. Given the complexity, the description is grossly incomplete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, meaning all parameters have descriptions in the schema. The description adds no extra meaning beyond what the schema already provides, so the baseline of 3 applies. It does not compensate with any additional clarifications about parameter relationships or formatting.

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 verb ('Fetches data') and a resource ('Google Ads API') but is extremely vague about what kind of data or which resources are searchable. It does not differentiate from sibling tools like metadata_get_resource_metadata or customers_list_accessible_customers, making it unclear when this tool is the right choice.

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 guidance on when to use this tool versus the siblings. No mention of alternatives, exclusions, or prerequisites. An agent has to infer that this is a general search tool, but the description gives no contextual hints about when it should be preferred.

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