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

No annotations are provided, and the description does not disclose behavioral traits such as idempotency, rate limits, or authorization requirements. It only states that it returns metrics, which implies a read-only operation.

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 clear header, metric list, parameter info, return type, and an example. Every sentence serves a purpose.

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

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

The description covers the tool's purpose, key parameters, and provides an example. It does not mention the output schema structure, but an output schema exists. The date_range default is in the schema but not in the 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?

The description includes an Args section with clear explanations for `customer_id` (no hyphens) and `date_range` (with example values like 'LAST_30_DAYS'). Since schema coverage is 0%, the description adds significant 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 clearly states 'Get account-level performance overview' and lists specific metrics, distinguishing it from campaign-level or ad-level tools. However, it does not explicitly contrast with sibling tools.

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

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

The description does not provide guidance on when to use this tool versus alternatives like `google_ads_campaign_performance`. It only describes what it does.

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?

No annotations provided. Description only states it adds audience targeting and lists targeting_mode. Does not disclose behavior on existing audiences, error conditions, or consequences. Lack of detail 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?

Very concise with clear structure: purpose sentence, similarity note, bullet-point args, return statement, and example. No redundant 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?

With 4 parameters and output schema (not shown), description covers core operation and parameter meanings but lacks error handling, duplicate behavior, and detailed return value beyond 'Success message'. Adequate but 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 0%, description compensates with brief explanations for all 4 parameters, includes format note for customer_id, and enumerates targeting_mode values. Could clarify default behavior and mode semantics.

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

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

Description explicitly states 'Add audience targeting to an ad group.' as a verb+resource pair and distinguishes from sibling 'google_ads_add_audience_to_campaign' by noting it is applied at ad group level for granular control.

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?

Mentions similarity to campaign-level tool, implying ad group scenario, but no explicit when-not or alternatives for audience targeting tools like set_audience_exclusions. Guidance is present but limited.

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?

No annotations are provided, so the description must carry the burden. It explains the two modes and returns a success message, but does not disclose whether audience targeting is additive or replaces existing settings, nor does it mention permissions or error conditions.

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 well-structured with a clear purpose, separate sections for modes, args, examples, and a recommendation. Every sentence is informative and there is no redundant 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?

With an output schema available, the description need not detail return values. It covers essential aspects: operation, parameters, modes, and best practice recommendation. Missing prerequisites (e.g., user list must exist) and potential side effects, but is sufficiently complete for an additive 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?

Despite 0% schema description coverage, the description thoroughly explains each parameter: customer_id format, campaign_id, user_list_id, and targeting_mode with two options and a default. Examples illustrate usage clearly, adding significant value beyond the schema.

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

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

The description clearly states it adds audience targeting to a campaign and explains two distinct modes (OBSERVATION and TARGETING). It distinguishes from sibling tools like google_ads_add_audience_to_ad_group by specifying the campaign scope.

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 recommendations on when to use each mode (start with OBSERVATION) and explains the purpose of each mode. However, it does not compare with other audience-related tools (e.g., google_ads_set_audience_exclusions) or state when not to use this tool.

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

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

With no annotations, the description should reveal behavioral traits like idempotency, side effects, or error handling. It only states it 'adds' and returns a result, leaving agent unaware of behavior if extension already exists or if there are limitations.

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?

Description is well-structured with separate sections for purpose, parameters, returns, and an example. No unnecessary repetition, but minor redundancy in explaining call extension purpose in first paragraph could be tightened.

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?

Covers purpose, parameters, and return, but lacks usage guidelines and behavioral transparency. For a tool with no annotations and 5 parameters, additional context about idempotency or preconditions would improve completeness.

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 0%, but description compensates with detailed parameter explanations: customer_id format, campaign_id numeric, phone number format, country_code default, and track_calls boolean. This adds significant value beyond schema titles and types.

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

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

Description clearly states 'Add call extension to a campaign' and explains its function. While the name and first sentence differentiate it from sibling extension tools (e.g., add_callout_extension), it does not explicitly distinguish itself from other 'add' operations.

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 guidance on when to use this tool versus other extension tools or prerequisites (e.g., campaign must exist). The example is provided but lacks conditional context or 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?

No annotations are provided, so the description carries the burden. It states the tool adds callouts (a mutation) and mentions requirements, but does not disclose error handling, side effects, or prerequisites like permissions. This is adequate but not comprehensive.

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 well-structured with clear sections, front-loaded purpose, and an example. Every sentence adds value, and there is no redundancy. It is concise yet informative.

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 3 parameters and an output schema (present but not shown), the description covers input requirements adequately. It does not detail the output structure, but the existence of an output schema mitigates this. Slightly more detail on return format could raise to 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 coverage is 0%, but the description adds significant value: specifies format for customer_id (10 digits, no hyphens), provides an example JSON array for callouts_json, and gives a full schema. This fully compensates for the lack of schema 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 clearly states 'Add callout extensions to a campaign' and explains what callouts are. This distinguishes it from sibling tools like add_sitelink_extension or add_call_extension by specifying the type of extension.

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 requirements (character limit, min/max callouts) and an example, helping the agent understand proper usage. However, it does not explicitly contrast with alternatives or mention when not to use (e.g., when campaign already has max callouts).

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 no annotations, the description carries the full burden. It discloses the basic behavior (adds exclusions, returns success message) and mentions CIDR support for IP ranges. However, it does not address whether exclusions are additive or replacing, permission requirements, rate limits, or error 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?

The description is well-structured with Args, Returns, Note sections. It is relatively concise, though the examples add length. Every sentence adds value; no redundancy.

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

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

Given the tool's complexity and lack of annotations, the description should cover more: whether exclusions are added incrementally or replace existing, duplicate handling, limits, and full return structure. Output schema exists but its content is unknown, so description must do more. It is adequate but not 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 coverage is 0% (no descriptions in schema). The description adds significant meaning: it explains placement_exclusions as 'List of URLs/apps to exclude' with examples, and ip_exclusions similarly with CIDR note. Customer_id gets a 'without hyphens' hint, but campaign_id lacks detail. Overall, it compensates well for missing schema 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 clearly states the tool adds placement and IP exclusions to a campaign. It distinguishes from sibling tools like add_negative_keywords and set_audience_exclusions by focusing on placement and IP exclusions.

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 explains what exclusions do but does not explicitly state when to use this tool over alternatives (e.g., negative keywords, audience exclusions). Usage context is implied but no direct guidance on tool 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?

No annotations are provided, so the description carries full burden for behavioral disclosure. It states the tool adds keywords and returns a success message with a count, but does not detail side effects like duplicate handling, overwrite behavior, or permission requirements. Transparency is adequate but not thorough.

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 main purpose and includes structured arg descriptions and an example. It is reasonably concise, though the example could be trimmed. Each sentence adds value without redundancy.

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

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

Given the tool's moderate complexity and presence of an output schema (not shown), the description covers the inputs well and indicates the return type. It lacks details on error handling or batch size limits, but is largely complete for the intended functionality.

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

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

The description significantly enhances the input schema by specifying format details (customer_id without hyphens), required fields for keyword objects (text and match_type), and allowed values for match_type (EXACT, PHRASE, BROAD). It also clarifies the cpc_bid as optional and in currency units. With 0% schema description coverage, the description fully compensates.

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 'Add keywords to an ad group' with a specific verb and resource. It provides an example with keyword match types, making the action unambiguous. However, it does not differentiate from siblings like google_ads_batch_add_keywords or google_ads_bulk_add_keywords, so the purpose is clear but not fully distinguished from similar 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 provides no guidance on when to use this tool versus alternatives such as batch or bulk versions. It does not mention prerequisites, limitations, or context for use, leaving the agent to infer appropriate 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?

No annotations are provided, so the description bears full responsibility. It describes the effect (show address, phone, map marker) and mentions requirements and optional phone, but lacks details on idempotency, error handling, or permission needs.

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 well-structured with sections (Args, Example, Benefits, etc.) and front-loaded with purpose. However, it is somewhat lengthy with some repetition, such as benefits reiterating earlier points.

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 9 parameters and no schema descriptions, the description thoroughly covers all inputs, includes an example, and provides usage context and requirements. The output schema exists but is not shown; the description explains the return value sufficiently.

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 0%, but the description provides detailed parameter explanations (format, length, examples) for all 9 parameters, fully compensating for the missing schema 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 clearly states 'Add a location extension to display your business address in ads' and explains what location extensions do. It effectively distinguishes from sibling extension tools by focusing on address display, a unique purpose.

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

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

The description provides requirements (address verification, GMB linking, valid fields) and a note on advanced management, but does not explicitly compare with other extension tools or state when not to use this tool.

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

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

No annotations are provided, so the description must fully disclose behavioral traits. It identifies the action as adding negative keywords (a mutation) but does not mention any side effects, limits (e.g., maximum keywords per call), overwriting behavior, or required permissions.

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

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

The description is concise and includes a useful example, though it uses a docstring format with 'Args' and 'Returns' which adds some verbosity. Every part serves a purpose, making it 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?

Given the presence of an output schema (true in context), the description does not need to detail return values. However, it lacks information on error handling, rate limits, or prerequisites. For a simple tool, it is adequate but could be more complete given the large number of sibling 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?

The description adds significant meaning beyond the input schema by specifying that the 'keywords' parameter should be a list of dicts with 'text' and 'match_type' keys, and provides an example. The schema only defines an array of objects with additional properties, lacking structure.

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 ('Add negative keywords') and the resource ('to an ad group'). It distinguishes itself from siblings like 'google_ads_add_keywords' (adds positive keywords) and 'google_ads_add_shared_negative_keywords' (adds to shared library).

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

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

The description implies usage for adding negative keywords but provides no explicit guidance on when to use this tool versus alternatives. It does not mention when not to use it or contrast with sibling tools like 'google_ads_add_keywords' or 'google_ads_add_shared_negative_keywords'.

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 no annotations, the description should fully disclose behavior. It explains the operation and some parameter constraints (e.g., items count 3-8, qualifier values) but does not mention whether the operation is destructive, reversible, or what the return result contains beyond a vague statement. Key behavioral aspects are missing.

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 well-structured with sections for intro, args, schema, returns, and example. It is concise yet comprehensive, with no unnecessary words. Each section 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 existence of an output schema, the description need not detail return values. It covers parameter constraints and provides an example. However, it could include more context about prerequisites (e.g., campaign must exist) and potential errors, though the output schema may cover some of that.

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 0%, so the description carries the full burden. It provides detailed meaning for each parameter: customer_id format (10 digits, no hyphens), campaign_id, price_qualifier with enum values, and items_json with a JSON schema and count constraint (3-8 items). An example further clarifies usage.

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

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

The description clearly states the tool adds a price extension to a campaign and explains what price extensions are, distinguishing it from sibling tools like add_call_extension or add_promotion_extension. The verb 'Add' and resource 'price extension' are specific.

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 does not explicitly state when to use this tool versus alternatives or when not to use it. The implied usage is clear (when adding a price extension), but no exclusions or comparisons are provided, leaving the agent to infer from sibling names.

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 no annotations, the description must disclose behaviors. It only states the action ('add') without mentioning idempotency, error conditions, permissions, or side effects (e.g., whether existing promotions are overridden).

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?

Well-structured with a one-line summary, purpose paragraph, parameter list, returns line, and an example. Every sentence is informative, no fluff. The example is particularly helpful.

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?

Covers purpose, parameters, and returns (via example). Lacks behavioral details but includes an output schema (signal true). For a tool with 8 parameters, it is fairly complete, though usage guidance 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 0%, but the description provides detailed explanations for each parameter (e.g., customer_id format, occasion enum values, discount_modifier options). This fully compensates for the schema gap, adding significant 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 clearly states the tool adds a promotion extension to a campaign, specifying the action and resource. It distinguishes from siblings by naming the specific extension type 'promotion extension' and explains its purpose (highlighting special offers).

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 explicit guidance on when to use this vs. other extension tools like add_call_extension or add_callout_extension. The description implies it's for promotions but does not specify conditions or alternatives, leaving the agent to infer.

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 is a mutation operation (adds keywords) with no annotations. It mentions the return format (success message with count) but lacks detail on error cases like non-existent shared list or duplicate keywords. The behavior is adequately described but not exhaustive.

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 well-structured with a summary, args, returns, and example. However, the first two sentences are slightly redundant ('Add negative keywords' and 'This adds keywords'). Still clear and front-loaded. Minor verbosity.

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

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

Given the tool's simplicity and presence of an output schema, the description covers purpose, parameters, example, and return. It does not cover error conditions or prerequisites (e.g., shared list must exist), but overall it is sufficient for an agent to use 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?

The schema coverage is 0% and the schema for 'keywords' is vague (array of objects with string additional properties). The description adds crucial meaning by specifying each dict must have 'text' and 'match_type' and provides an example. This fully compensates for the schema gaps.

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 'Add negative keywords to a shared negative keyword list (account-level)' and explains that the list can be applied across multiple campaigns. This distinguishes it from sibling tools like google_ads_add_negative_keywords which likely operate at campaign or ad group level.

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

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

The description implies use for account-level negative keyword management across campaigns. It does not explicitly state when not to use or name alternatives, but the phrase 'account-level shared' differentiates it from campaign-specific tools. Some guidance is 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 are absent, so the description must disclose behavior. It mentions potential increases in CTR and ad size but does not elaborate on the impact on existing sitelinks, whether the operation is destructive, or performance side effects.

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 well-structured with clear sections for args, schema, requirements, returns, and an example. It is informative but slightly long; could trim redundant phrasing while retaining clarity.

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?

Input parameter details are thorough, but the output is vaguely described as 'Sitelink extension creation result' despite the existence of an output schema. No annotations are provided to fill 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?

With 0% schema coverage, the description significantly compensates by detailing parameter formats (e.g., customer_id: 10 digits, no hyphens), providing a JSON schema for sitelinks_json, and specifying character limits and an example.

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 'Add sitelink extensions to a campaign' and explains what sitelinks are, distinguishing it from other extension tools by naming 'sitelink' specifically.

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 requirements (link text length, minimum 2 sitelinks) but does not offer guidance on when to use this tool versus alternative extension tools like callout or price extensions.

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?

No annotations are provided, and the description does not disclose behavioral traits like request limits, authentication needs, or that the operation modifies the campaign. It only indicates creation without detailing side effects or restrictions.

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 well-structured with an Args section and an example, but it contains redundant explanations (e.g., repeating 'Structured snippets highlight...'). Still, it is efficient and front-loads the purpose.

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 presence of an output schema, return values are covered. The description adequately explains parameters and provides an example, but lacks details on error handling, prerequisites (e.g., campaign must exist), or limitations.

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 schema has 0% description coverage, so the description adds value by specifying customer_id format (10 digits, no hyphens), header options, and values_json constraints (3-10 items). However, campaign_id is not elaborated, and some parameters remain opaque.

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 "Add structured snippet extension to a campaign" with a specific verb and resource. It distinguishes from sibling tools like google_ads_add_callout_extension by focusing on structured snippets.

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 an example and lists common headers, offering implicit usage context. However, it does not explicitly state when to use this over alternative extensions or provide contraindications, so guidance is present but not comprehensive.

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 no annotations, the description carries the full burden. It clearly describes the output structure (campaign-level breakdown, aggregated by type, total campaigns) and prerequisites (SDK for in-app, automatic install tracking). Implies read-only nature, but does not explicitly state it as safe/read-only.

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?

Well-structured with sections (Args, Returns, Example, Notes, Conversion Categories) and front-loaded purpose. Some minor repetition (e.g., Notes restate SDK requirements from Conversion Categories), but overall 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?

Given the tool has an output schema (context) and 3 parameters with no enums, the description is very complete. Covers all parameters, output structure, example usage, conversion categories, and prerequisites. No missing critical details.

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 0%, but the description compensates fully. Explains each parameter: customer_id format (10 digits, no hyphens), campaign_id as optional filter, date_range with examples of valid values. Also includes an example call, making semantics clear.

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?

Clearly states 'Get detailed app conversion data by conversion type' and elaborates with specific breakdown by conversion action and category. Distinguishes from sibling read tools by focusing on app-specific conversions and listing conversion categories like App Installs, In-App Purchases, etc.

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 on when to use: for understanding which conversion events drive campaign performance. Includes prerequisites in Notes (SDK integration needed for in-app conversions). However, does not explicitly compare or exclude alternatives like get_conversion_performance.

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 no annotations, the description must fully convey behavioral traits. It warns that changes will be made, but does not disclose if changes are reversible, whether the operation is idempotent, or what permissions are required. It does describe the effect for various recommendation types, which adds 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?

The description is well-organized with clear sections (main purpose, args, returns, example, warning). It is slightly verbose but each part serves a purpose. The structure aids readability.

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

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

Given the tool has 2 required parameters, no annotations, and an output schema exists (but not shown), the description is fairly complete. It explains how to get the resource name, what the tool does, and includes a warning. It could add details about return format or error cases, but the output schema likely covers that.

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 schema has 0% description coverage, so the description fully compensates. It explains customer_id format (no hyphens) and recommendation_resource_name as obtained from google_ads_get_recommendations. It provides a concrete example, making parameter usage clear.

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

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

The description clearly states the tool applies a single optimization recommendation, with examples of recommendation types (keyword, budget, bidding). It distinguishes from sibling tools like google_ads_apply_recommendations_by_type, which applies multiple recommendations of the same type.

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 explains that the tool automatically implements recommendations and includes a warning to review carefully. However, it does not explicitly state when to use this tool versus alternatives like google_ads_bulk_apply_recommendations, nor does it mention any prerequisites (e.g., need to fetch recommendation details first).

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?

No annotations are provided, but the description warns that the tool will make changes to the account and advises reviewing recommendations carefully. This is good disclosure of destructive behavior. It doesn't mention rate limits or side effects, but the warning suffices.

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 well-structured with a summary, parameter descriptions, returns, an example, common types, and a warning. Every sentence adds value, and it is concise with no 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 no annotations and only a minimal input schema, the description provides complete context: purpose, usage, parameters, return value, example, and common types. It is sufficient for an AI agent to correctly select and invoke this 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?

With schema description coverage at 0%, the description compensates fully: it explains customer_id format, recommendation_type with examples and a common types list, and max_to_apply as optional. This adds significant meaning beyond the bare schema.

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

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

The description clearly states 'Apply all recommendations of a specific type' and distinguishes from sibling tools like 'google_ads_apply_recommendation' (single) and 'google_ads_bulk_apply_recommendations' (bulk without type filter). It includes examples of recommendation types and an example call.

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 explains when to use this tool ('bulk-applying all recommendations of a certain category') and provides common recommendation types. It also includes a warning about making changes. However, it does not explicitly contrast with similar tools or state when not to use it.

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 no annotations, the description carries full burden. Describes the operation as retrieving metrics, implying a read-only, non-destructive action. Lists specific metrics returned, but does not mention rate limits, authentication needs, or data freshness. Overall satisfactory but lacks some depth.

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?

Well-structured with headers for description, args, returns, example, and metrics. Content is relevant and front-loaded. Slightly verbose due to example and metrics list, but still concise overall.

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

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

Given the tool has an output schema (true) and only three parameters, the description is complete. Covers all parameter details, return structure, and examples, providing sufficient context for an agent to use the tool correctly.

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

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

Schema coverage is 0%, so description fully compensates by explaining each parameter: customer_id format, campaign_id as optional filter, date_range with enum examples. Also describes return structure and lists metrics, adding significant meaning beyond the bare 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?

Explicitly states 'Get performance metrics for App campaigns', using a specific verb and resource. Distinguishes from sibling tools like google_ads_campaign_performance and google_ads_app_conversions by focusing on app campaign metrics.

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 example usage and explains optional parameters, but does not explicitly state when to use this tool versus alternatives such as google_ads_campaign_performance or google_ads_app_conversions. No exclusion criteria or context for when not to use.

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?

No annotations are provided, so the description must fully disclose behavior. It states the action is an assignment that replaces the current strategy, but lacks details on side effects, permissions, reversibility, or error conditions. This is insufficient 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 concise: a clear first sentence, followed by an args list and example. Every sentence adds value without redundancy.

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

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

Given the simple 3-parameter signature and no annotations, the description covers purpose, inputs, and output (success message). It is largely complete for an agent to select and invoke correctly, though it could include prerequisites.

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 has 0% description coverage, but the tool description lists each parameter with a short explanation (e.g., 'customer_id: Customer ID (without hyphens)'). This adds basic meaning, but does not provide constraints or where to obtain IDs.

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

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

The description clearly states the tool assigns a portfolio bidding strategy to a campaign. The verb 'assign' and the specific resource 'portfolio bidding strategy' make it distinct from siblings like 'create_bidding_strategy' or 'update_bidding_strategy'.

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 explains that it replaces the current bidding strategy and mentions Google AI optimization across campaigns. While it does not explicitly list alternatives or when not to use, the context is clear enough for an agent to understand its use case.

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?

No annotations are provided, so the description bears full behavioral transparency burden. It discloses that 'The campaign will switch from its individual budget to the shared budget,' which is a key behavioral change. However, it does not mention whether the operation is reversible, what permissions are required, or what happens if the campaign already uses a shared budget.

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 very concise: a single sentence for the main action, followed by an Args list and a Note. Every sentence is essential and there is no extraneous text. It is well-structured and front-loaded.

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

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

Given the tool's simplicity and the presence of an output schema (though not detailed in the description), the description covers the main action, parameter sources, and a behavioral note. It lacks details on error handling or what happens if the budget resource is invalid, but overall it provides sufficient context for typical 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?

Input schema has 0% description coverage, but the description adds value by explaining parameter sources and formatting: customer_id (without hyphens), campaign_id, and budget_resource_name (from sibling tool). This helps the agent understand where to get the values, going beyond the schema's type-only fields.

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 'Assign a shared budget to a campaign.' It uses a specific verb ('Assign'), identifies the resource ('shared budget'), and the target ('campaign'), which distinguishes it from siblings like 'google_ads_create_shared_budget' or 'google_ads_update_campaign_budget_v2'.

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 indicates that the budget_resource_name should come from 'google_ads_create_shared_budget', implying a prior step. The note about switching from individual to shared budget provides context on when to use this tool (when a campaign currently has an individual budget). It does not explicitly state when not to use it or list alternatives, but the context 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?

No annotations are provided, so the description must disclose behavioral traits. It indicates that the tool returns data and is a read operation (no destructive hints), but does not mention rate limits, authentication requirements, or error handling. It provides basic transparency but lacks depth.

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 well-structured with headers (Provides, Args, Returns, Example) and a bullet list. Every sentence serves a clear purpose, and it is front-loaded with the tool's purpose. No redundant or vague statements.

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

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

Given the tool's moderate complexity and the existence of an output schema, the description covers the inputs, output nature, and example usage. It mentions returns 'Auction insights with competitive analysis' which, combined with the required parameters, is sufficient for an agent. However, it could briefly note that the output is a structured report or list.

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

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

Schema description coverage is 0%, so the description fully explains parameters: customer_id format (10 digits, no hyphens), campaign_id, and date_range with enumerated options (LAST_7_DAYS, LAST_30_DAYS, LAST_90_DAYS). The example further clarifies usage. This adds significant value beyond the bare schema.

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

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

The description clearly states the tool's purpose: 'Get auction insights and competitive intelligence for a campaign.' It lists specific metrics (impression share, competitive position) and outcomes (recommendations). This verb+resource specification distinguishes it from sibling tools like google_ads_search_impression_share or google_ads_campaign_performance.

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

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

The description provides a usage example and lists parameters, but does not explicitly state when to use this tool versus alternatives. It lacks guidance on when not to use it or comparisons to similar analysis tools. The example implies typical usage but does not cover 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?

With no annotations, the description carries full burden. It explains that the tool applies recommendations automatically, excludes high-risk ones, and includes a warning about potential performance impact. It also describes the dry_run parameter's behavior. It could be more explicit about the mutation effect, but the description is transparent enough.

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 well-structured with a clear purpose statement, bullet-list of safe recommendations, parameter explanations with examples, and a warning. Every sentence is essential and contributes to understanding, with no 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 simplicity (2 parameters, output schema exists), the description covers all necessary aspects: what the tool does, what recommendations are included/excluded, how to use dry_run, and a cautionary note. The examples further clarify usage. It is complete for effective use.

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 0%, so the description must compensate. It provides clear semantics for both parameters: customer_id format (without hyphens) and dry_run (preview vs. apply, default true). The example also demonstrates usage, adding significant value beyond the bare schema.

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

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

The description clearly states that the tool auto-applies low-risk, high-impact recommendations, and lists specific safe recommendations (keyword match type upgrades, responsive search ad suggestions, etc.) and explicitly excludes higher-risk ones (budget increases, bidding strategy changes). This differentiates it from other apply tools among 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?

The description provides clear context on when to use the tool (for safe recommendations) and when not to (higher-risk recommendations should be reviewed manually). It also recommends using dry_run=True first. However, it does not explicitly name alternative sibling tools for manual review.

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 no annotations, the description carries full burden. It details required/optional fields, defaults, match types, and return format. It does not mention destructive nature or auth, but is adequate for a creation 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?

Description is well-structured with sections (Args, Schema, Returns, Example) and front-loaded purpose. Slightly long due to schema reproduction but appropriate for complexity.

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?

Complex batch operation with nested JSON; description covers input structure thoroughly. Output is described as 'result with success/failure details' which is sufficient given output schema availability (though not shown).

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 0%, but description fully compensates: explains customer_id format (10 digits, no hyphens) and keywords_json as a JSON array with complete sub-schema (ad_group_id, text, match_type, cpc_bid, defaults, and match type enum).

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 function: 'Add multiple keywords in a single batch operation.' The verb 'Add' and resource 'multiple keywords' are specific, and 'batch' distinguishes it from singular add_keywords or bulk_add_keywords 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?

The description implies batching is for efficiency, but does not explicitly state when to use this tool versus alternatives like add_keywords or bulk_add_keywords. No when-not or exclusions 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?

With no annotations, the description adds context by explaining the JSON configuration structure and required/optional fields. However, it lacks details on idempotency, ordering, error handling, or batch limits that would help the agent anticipate 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?

Structured with clear sections (intro, args, schema, returns, example). Front-loaded with purpose. The code block is helpful but adds length; still efficient overall.

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?

Covers key aspects: how to call, parameter meanings, configuration structure, and example. Missing details like maximum batch size or error behavior, but adequate for a batch tool with output schema present.

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 0%, but description compensates well: explains customer_id format, ad_groups_json as JSON array, and provides a detailed schema with required/optional fields and example. Could be more precise on data types (e.g., cpc_bid as number).

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?

Clearly states 'Create multiple ad groups in a single batch operation,' specifying the verb, resource, and batch nature. Distinguishes from sibling 'google_ads_create_ad_group' by emphasizing batch.

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?

Implies usage for creating multiple ad groups at once, but does not explicitly state when to use this vs. alternatives (e.g., 'google_ads_create_ad_group'). No when-not or exclusion guidance 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?

No annotations are provided, so the description carries full burden. It discloses that it creates ads and returns success/failure details, but does not mention authentication needs, rate limits, whether the batch is atomic, or any side effects. Moderate transparency but missing important operational 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 well-structured: summary, parameter explanations, schema example, required fields, return type, and example call. Every sentence adds value, and the length is appropriate for the complexity.

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

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

The description covers most essentials: parameters, configuration schema, required fields, and a usage example. However, it lacks batch size limits or error handling details. Given the presence of an output schema (not detailed), it is nearly complete but could mention constraints.

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

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

With schema coverage at 0%, the description adds substantial meaning: it explains customer_id format, ads_json structure with a full schema example, required fields, and constraints (headlines 3-15, descriptions 2-4). This goes far beyond the minimal schema titles.

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 'Create multiple responsive search ads in a single batch operation,' specifying the verb (create), resource (responsive search ads), and scope (batch, multiple). It distinguishes itself from the sibling tool 'google_ads_create_responsive_search_ad' which creates a single ad.

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

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

The description implies usage for bulk creation via 'batch operation' and the JSON array schema, but it does not explicitly state when to use this vs the single ad creation tool, nor does it provide when-not or alternatives. The context is clear enough but lacks explicit guidance.

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

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

There are no annotations, so the description carries the full burden. It discloses that the operation is a batch creation that supports partial failure, and describes the input JSON structure and defaults. It does not mention any destructive behavior, auth needs, or rate limits, but for a creation tool this is sufficient.

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 well-structured with sections (Args, Campaign Configuration Schema, Required/Optional, Example). It is a bit longer but every sentence adds value given the complexity of the JSON parameter. Front-loaded with the main purpose.

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 tool has an output schema (so return details are not required), the description comprehensively covers input parameters, defaults, partial failure behavior, and provides a full example. It compensates for the missing schema descriptions and the complexity of batch creation.

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 descriptions are missing (0% coverage), so the description must compensate. It provides detailed semantics: customer_id format (10 digits, no hyphens) and campaigns_json as a JSON array with a full schema including required/optional fields, defaults (type=SEARCH, status=PAUSED), and an example. This goes far beyond the bare schema.

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

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

The description clearly states 'Create multiple campaigns in a single batch operation', which is a specific verb-resource pair. It distinguishes itself from sibling tools like google_ads_create_campaign (single campaign creation) and other batch tools like google_ads_batch_create_ad_groups.

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

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

The description implies batch usage and mentions partial failure, providing clear context. However, it does not explicitly state when not to use it or contrast with alternatives like sequential single creation. It also lacks prerequisites or constraints.

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?

No annotations exist, so description carries full burden. It says 'Enable' implying a state change, but fails to disclose consequences (e.g., campaigns become active, what if already enabled), permissions, idempotency, or effects on serving.

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?

Description is concise with clear sections (Args, Returns, Example). Every sentence adds value, and the example demonstrates usage. 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?

Has output schema (not shown) which reduces burden. Includes parameter constraints and example. However, lacks behavioral details and usage guidelines. Adequate but missing context for an agent to fully understand side effects.

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

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

Schema coverage is 0%, but description adds meaningful constraints: customer_id '10 digits, no hyphens' and campaign_ids 'comma-separated list'. This goes beyond the schema's title and type, aiding 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?

Description clearly states 'Enable multiple campaigns in a single batch operation,' specifying the verb (enable), resource (campaigns), and batch nature. This distinguishes it from sibling tools like google_ads_batch_pause_campaigns.

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 explicit when-to-use or when-not-to-use guidance. The provided example shows usage, but there is no mention of prerequisites, conditions, or alternatives. Missing context on when to prefer this over other batch status change 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?

No annotations provided; the description only states it pauses campaigns (a destructive action) but omits prerequisites (e.g., permissions), error handling for invalid IDs, behavior on partial failures, or any rate limits. The return is vaguely described as 'Batch operation result.'

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 front-loaded with the action; includes an example. Slight redundancy with schema but acceptable; no wasted sentences.

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?

Despite existence of an output schema, the description lacks completeness for a batch operation: no mention of batch limits, error handling, or what 'Batch operation result' contains. For a mutation tool with no annotations, more behavioral context 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?

Schema coverage is 0%, so the description must compensate. The 'Args' section adds meaning beyond the schema: customer_id format (10 digits, no hyphens) and campaign_ids as comma-separated list. However, it does not specify that IDs are numeric or maximum length, and the description is minimal.

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

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

The description explicitly states 'Pause multiple campaigns in a single batch operation,' clearly indicating the verb (pause) and resource (campaigns), and distinguishes from sibling tools like batch_enable_campaigns.

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 explicit guidance on when to use this tool vs. alternatives (e.g., pausing campaigns individually or using batch_status_change). The example implies usage but lacks context about when it's appropriate.

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

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

No annotations are provided, so the description carries the full burden. It identifies the operation as a bulk set (mutation) and returns a success message with count, but lacks details on idempotency, partial failures, rate limits, error handling, or whether suffixes are overwritten or appended. For a mutation tool, more behavioral context is needed.

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: two sentences for purpose, then structured Args and Returns. No extraneous words. It is front-loaded with the primary purpose, making efficient use of space.

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

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

Given no annotations and no output schema, the description covers the essential calling convention and return a message with count. However, it omits details on error handling, partial success, validation, and other important behavioral aspects for a bulk mutation tool. It is adequate but incomplete for production use.

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

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

Schema description coverage is 0%, so the description compensates by explaining `customer_id` format ('without hyphens') and `ad_group_suffixes` as a JSON string with an array of objects, including a concrete example. This adds significant meaning beyond the schema, though additional constraints on URL suffix format are missing.

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

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

The description clearly states the tool's purpose: 'Bulk set Final URL suffixes for multiple ad groups in one API call.' It specifies the verb 'set', resource 'Final URL suffixes for ad groups', and the bulk nature. This distinguishes it from the sibling 'google_ads_set_ad_group_url_suffix' which handles single ad groups.

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

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

The description implies usage for bulk updates by mentioning 'multiple ad groups in one API call' but does not explicitly state when to use this tool versus alternatives like the singular set tool. No when-not or exclusion criteria 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?

No annotations are provided, so the description must disclose behavioral traits. It confirms the tool mutates statuses but does not mention permissions, immediacy of changes, rate limits, or potential side effects. The return value is only 'Batch operation result', lacking 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?

The description is well-organized into sections (Args, Status Update Schema, Valid Statuses, Returns, Example) and is front-loaded with the purpose. Every sentence adds value, and the example is useful.

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

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

Given the presence of an output schema (indicated in context signals), the description adequately covers input parameters, format, and valid values. It lacks error handling or edge case details, but is sufficient for a batch operation 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?

With 0% schema description coverage, the description fully compensates by detailing customer_id format, entity_type options, and the JSON structure for status_updates_json with two variants and valid statuses per entity. This adds significant meaning beyond the bare schema.

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

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

The description clearly states the tool's purpose: 'Change status for multiple entities (campaigns, ad groups, keywords, ads).' This is a specific verb+resource combination that distinguishes it from siblings like google_ads_batch_enable_campaigns or google_ads_batch_pause_campaigns by explicitly listing supported entity types.

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 valid statuses per entity type and shows JSON schemas for updates. However, it does not explicitly mention when to use this tool over more specialized siblings (e.g., google_ads_batch_enable_campaigns for campaign-only enablement), leaving the agent to infer.

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?

No annotations provided, so description carries full burden. It mentions batch operation and returns 'success/failure details', but lacks details on atomicity, limits, idempotency, or error handling beyond vague result.

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?

Well-structured with Args, Schemas, Returns, Example sections. Every sentence is informative; no fluff. Purpose 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?

Given output schema exists, description doesn't need full return details. Parameters are well-explained. Could be improved by adding batch size limits or atomicity behavior, but overall sufficient.

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 0%, but description fully compensates by explaining each parameter: customer_id format, entity_type values, bid_updates_json with complete JSON schemas for both entity types and an example.

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

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

The description clearly states the tool updates CPC bids for multiple keywords or ad groups in a batch, with specific verb and resource. It differentiates from siblings like single-update tools by emphasizing 'batch 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 implies use for batch updates but does not explicitly contrast with single-update tools or provide when-not-to-use guidance. No 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?

With no annotations, the description carries the transparency burden. It discloses that it performs a batch operation and returns success/failure details, but does not mention permissions, mutability, partial failures, or side effects. It adequately describes the required input schema but lacks behavioral 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?

The description is well-structured with sections for Args, Schema, Required Fields, Returns, and Example. It is concise but includes a necessary code block. Every sentence is informative, though the code block could be slightly trimmed. It is front-loaded with the main purpose.

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 2 parameters and a custom JSON input, the description provides adequate completeness for input structure. It explains the return only generically, but an output schema exists (not detailed). It does not compare to sibling tools, but the name and description sufficiently differentiate.

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 provides only names and types (0% coverage), so the description adds crucial semantic information: customer_id format (10 digits, no hyphens), budget_updates_json inner schema with required fields (campaign_id, budget_amount), and daily budget unit. An example is provided, making parameter usage clear.

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 (Update), resource (budgets for multiple campaigns), and scope (single batch operation). It distinguishes from siblings like update_campaign_budget_v2 by emphasizing the batch aspect.

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 lacks explicit guidance on when to use this tool vs alternatives. It does not mention that for single campaign budget updates, one should use update_campaign_budget_v2, nor does it provide context on prerequisites or when not to use it.

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 no annotations, the description carries the behavioral burden. It uses 'Analyze' which suggests a read operation, but does not explicitly state that no changes are made or mention any side effects, rate limits, or permissions. Adequate but could be clearer.

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 well-structured with sections for summary, outputs, arguments, return, and example. It is concise but some bullet points could be integrated into prose for brevity.

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's complexity is moderate, and the description covers key outputs, parameter formats, and a usage example. The existence of an output schema helps, but the description still provides necessary context for initial understanding.

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?

Despite 0% schema description coverage, the description provides detailed parameter explanations (e.g., '10 digits, no hyphens' for customer_id) and an example call, adding significant value over the schema.

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

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

The description clearly states 'Analyze budget pacing and spending velocity for a campaign' and lists specific outputs (current spend, pacing percentage, etc.), distinguishing it from siblings like budget_recommendations or performance_forecaster.

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

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

The description implies usage for analyzing pacing but does not explicitly state when to use this tool vs alternatives like budget_recommendations or wasted_spend_analysis. No when-not-to-use or prerequisite info is 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?

No annotations are provided, so the description must carry the full burden of behavioral disclosure. It states the tool 'generates' recommendations, implying a read-only analysis, but does not explicitly confirm that it does not modify any data. It also does not mention permissions, rate limits, or potential side effects.

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 structured with bullet points and an Args/Returns/Example section, making it easy to scan. While it is slightly verbose, it efficiently conveys the tool's purpose, parameters, and return value. The main purpose 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?

Given the tool's moderate complexity (2 parameters, one required) and the presence of an output schema (as indicated by context signals), the description is complete. It explains both parameters, describes the return value, and includes an example. No additional information 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 input schema has 0% description coverage, but the tool's description provides detailed explanations for both parameters: customer_id format (10 digits, no hyphens) and allowed date_range values (LAST_7_DAYS, LAST_30_DAYS, LAST_90_DAYS). This fully compensates for the schema gap and adds value beyond the schema.

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

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

The description clearly states the tool's purpose: 'Generate AI-powered budget reallocation recommendations.' It then details the types of campaigns it identifies (budget-constrained, underperforming, high ROAS) and that it provides prioritized recommendations. This distinguishes it from sibling tools like google_ads_budget_pacing and google_ads_get_recommendations, which focus on different aspects of budget management.

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 tool is for analyzing campaigns to inform budget reallocation, but it does not explicitly state when to use it versus alternatives (e.g., google_ads_budget_pacing for pacing, google_ads_recommendations for broader recommendations). There is no guidance on prerequisites or when not to use it.

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?

No annotations provided, so the description carries full burden. It states it 'adds' keywords but omits important behavioral traits like idempotency, duplicate handling, permission needs, or side effects. For a mutation tool, this is insufficient.

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?

Well-structured with Args, Returns, and Example sections. The example is minimal but relevant. No unnecessary sentences, though could be more streamlined.

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 numerous sibling tools, the description does not differentiate from 'batch_add_keywords' or 'add_keywords.' Output schema exists but is not leveraged to describe return values, leaving agent uninformed about success details.

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%, but the description adds value by listing allowed match types, default, and optional bid. However, it lacks format constraints for IDs and keyword texts, limiting completeness.

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

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

The description clearly states 'Bulk add multiple keywords with the same match type,' specifying the action and resource. However, it does not differentiate from the sibling tool 'batch_add_keywords,' which likely performs a similar function, reducing clarity.

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 guidance on when to use this tool versus alternatives like 'add_keywords' or 'batch_add_keywords.' Missing prerequisites or exclusions, leaving the agent to infer 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?

No annotations are provided, so the description carries the full burden. It warns that applying changes is destructive ('This will make changes to your account') and advises reviewing recommendations. It also describes the return value. However, it does not disclose behavior on partial failures or idempotency, which would enhance transparency.

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 well-organized with sections for purpose, usage, arguments, returns, example, and warning. Each sentence adds value and there is no redundancy. It is concise yet comprehensive, 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 tool's complexity and the presence of an output schema, the description covers the core functionality and return value. However, it omits details like maximum number of recommendations per batch and does not differentiate from sibling tools like google_ads_apply_recommendations_by_type, which could be improved for completeness.

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 0%, so the description must add meaning. It explains the customer_id format ('without hyphens') and that recommendation_resource_names are resource names, supplemented with a concrete example. This fully compensates for the lack of schema descriptions, making the parameters clear and usable.

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 'Apply multiple recommendations at once' and provides an example with multiple resource names, effectively distinguishing it from single-recommendation tools like google_ads_apply_recommendation. The verb+resource and efficiency mention make the purpose specific and 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 explains when to use (applying several recommendations efficiently) but lacks explicit guidance on when not to use it, such as for individual application or type-based filtering. It does not mention alternatives like google_ads_apply_recommendation or google_ads_apply_recommendations_by_type, which would help an agent choose correctly.

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?

No annotations are provided, so the description carries full burden. It mentions the action is mutation (dismiss) and returns a success message with count. However, it does not disclose potential side effects, idempotency, rate limits, or whether dismiss is reversible. The example partially compensates.

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 uses a clear docstring format with Args, Returns, and Example sections. It is well-structured and not overly verbose. However, the Args section largely duplicates the schema, and some sentences could be merged.

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

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

Given the tool's simplicity (2 required params, no enums, output schema exists), the description provides a clear use case with an actionable example. It covers the essential information for an agent to invoke the tool correctly, though it lacks usage guidelines and deeper behavioral details.

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?