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

The description adds the useful context that this is a batch link operation, but it does not explain behavior around duplicate links, validation failures, or whether the operation is atomic. The annotations already indicate non-read-only and non-idempotent behavior, so the description adds only modest behavioral context beyond them.

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 as an efficient docstring with args, accepted values, and a concrete example. It is somewhat verbose due to the full enum list, but every part adds necessary information for correct invocation.

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 provides all necessary input semantics and a clear example, which is sufficient for a mutation tool with no output schema. It does not describe the response format or edge-case behavior, but the core invocation requirements are well covered.

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

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

With 0% schema description coverage, the description fully compensates by defining each parameter, including the exact structure of the assets list and the accepted field_type values. The example further clarifies the expected format, leaving little ambiguity.

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

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

The description states a specific action ('Add assets to an existing asset group') and clarifies it is a batch link operation, which distinguishes it from single-resource creation and from the sibling remove_asset_from_group. The purpose is immediately understandable.

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

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

The description makes the intended use case clear: link multiple assets to an existing asset group. It does not explicitly discuss when not to use it or mention alternatives, but the action is direct and the sibling set makes the distinction obvious.

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

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

Annotations indicate a write operation that is not idempotent and not destructive. The description adds valuable behavioral context beyond annotations by stating that audience signals are 'suggestions, not hard targeting constraints,' clarifying the non-binding nature of the operation. It does not cover every side effect, but the annotations plus this context provide adequate 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 compact and front-loaded: the main purpose appears first, followed by a short conceptual note and a four-line parameter list. Every sentence contributes useful information without redundancy or filler.

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

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

For a 4-parameter mutation tool with no output schema, the description covers the core invocation details: purpose, parameter meanings, and the conceptual nature of audience signals. It lacks explicit guidance on parameter combinations or required-at-least-one behavior, but overall it is sufficient for correct tool selection and invocation.

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

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

Schema description coverage is 0%, so the description must compensate for all four parameters. It does so with a concise Args list explaining customer_id, asset_group_id, audience_resource_name, and search_themes, including that audience_resource_name comes from audience manager and search_themes are keywords describing the ideal customer. It stops short of clarifying whether the two optional signals can be combined or whether at least one is required, leaving a minor gap.

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

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

The first sentence states a specific verb, object, and target: 'Add audience or search theme signals to a PMax asset group.' It clearly differentiates from sibling tools like add_assets_to_group by focusing on audience/search theme signals. The added note that these are 'suggestions, not hard targeting constraints' removes ambiguity about the tool's role.

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

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

The description gives clear context for when to use the tool: when adding audience or search theme signals to a PMax asset group, and explains they help Google's AI find customers. It does not explicitly name alternative tools or state when not to use it, but the purpose and semantic distinction are clear enough for an agent to select it appropriately.

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

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

Annotations already indicate readOnlyHint=false, idempotentHint=false, and destructiveHint=false, so the mutation semantics are covered. The description adds 'batch operation' and optional cpc_bid details, but does not discuss failure modes, duplicate handling, quotas, or other operational consequences. No contradiction with annotations.

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

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

The description is front-loaded with the core purpose, followed by a compact Args list and a helpful example. Every sentence adds value, with no filler or repetition.

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?

All invocation-critical information is present: customer_id, ad_group_id, and keyword structure with allowed match types and optional bid. Minor gaps remain around maximum batch size, duplicate keyword behavior, and return/error details, but these are not essential for a correct call.

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 must fully compensate. It documents all three parameters, including the nested keyword dict structure, required and optional fields, allowed match_type values, and a concrete example. This is excellent parameter-level guidance.

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

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

The description uses a specific verb and resource: 'Add keywords to an ad group (batch operation).' This clearly identifies the action and differentiates it from sibling tools like remove_keyword, update_keyword_bid, and list_keywords.

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

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

The description makes the intended use clear: adding one or more keywords to a specific ad group. It does not explicitly state when not to use it or point to alternatives, but the sibling set and wording provide sufficient context.

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

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

The annotations declare readOnlyHint=true, so the safety profile is already covered. The description adds the conversion ratio and pure conversion nature, but it does not describe the return value format, rounding behavior, or any edge cases. This is useful but not rich behavioral context.

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

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

The description is compact and front-loaded with the main purpose, followed by the critical conversion context and a minimal Args list. Every sentence earns its place; there is no filler or repetition of schema details.

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

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

For a simple two-parameter utility tool, the description covers purpose and parameters well. However, there is no output schema and the description does not state what the tool returns or any precision/rounding behavior, which leaves a minor gap for an agent deciding how to use the result.

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 must carry the parameter documentation. It fully explains both parameters: 'value' is the number to convert, and 'direction' is explicitly given as 'to_micros' or 'from_micros' with their meanings. This exceeds what the minimal schema provides.

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

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

The description states a specific verb ('convert') and resource ('micros and currency amounts'), and gives the key domain fact that $1.00 = 1,000,000 micros. This clearly distinguishes the tool from the unrelated sibling account, campaign, and ad management 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 clear context: Google Ads uses micros for monetary values, so an agent knows when conversion is needed. It also explains both directions, making usage straightforward. No alternative tool exists among siblings, so explicit exclusion is unnecessary.

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

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

Annotations already indicate a non-read, non-destructive, non-idempotent operation. The description adds some behavioral context, such as target_cpa overriding campaign-level values and status representing the initial state, but does not disclose side effects, return behavior, or validation constraints beyond what the schema and annotations cover.

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

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

The description is a compact docstring with a one-sentence purpose followed by a clean Args list. Every bullet adds meaningful information, and there is no redundant or fluff content.

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

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

All seven parameters are explained, which is essential given the 0% schema coverage. The only gaps are that the description does not mention what the tool returns on success, and it does not clarify when to use cpc_bid versus target_cpa based on campaign bidding strategy. These are minor for a create tool with no output schema.

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

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

Schema description coverage is 0%, so the description carries full responsibility for parameter semantics. It explains every parameter, including cpc_bid with a currency example, target_cpa's override behavior, ad_group_type with concrete enum examples, and the default status. This goes well 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 opens with 'Create a new ad group in a campaign,' which states a specific verb, resource, and scope. This clearly distinguishes it from siblings like update_ad_group and set_ad_group_status, and aligns with the tool name without being tautological.

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 context is clear: this is the tool for creating ad groups, and sibling names like update_ad_group and set_ad_group_status imply alternatives for modification or status changes. It does not explicitly state when not to use it, but the creation-only framing is unambiguous.

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

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

Annotations already communicate that this is a mutating, non-idempotent operation, and the description's 'Create a new...' wording aligns with that. The description adds useful parameter-level behavior about delivery_method and explicitly_shared, but does not disclose side effects, return behavior, or any operational constraints. With annotations carrying the core safety profile, this is adequate but not rich.

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

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

The description is a single purpose sentence followed by a compact, alphabetized Args block. There is no filler or repetition, and each line adds necessary information. The structure is easy to scan and front-loads the core action.

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?

All parameters are fully explained, which makes the tool invocable. However, with no output schema present, the description omits any mention of what the tool returns, such as the created budget's resource ID. It also does not explain how the created budget relates to campaigns or other budget operations, which leaves some contextual gap.

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

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

The input schema provides only names and types, so the description must compensate, and it does thoroughly. It explains customer_id, name, amount with a currency example, delivery_method with both options and their meanings, and explicitly_shared with a clear real-world consequence. Every parameter receives meaningful context.

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

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

The description opens with a specific verb and resource: 'Create a new campaign budget.' This clearly distinguishes it from sibling tools like update_budget (new vs. update) and create_campaign (budget vs. campaign). The scope is unambiguous.

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

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

The description does not state when to use this tool versus alternatives such as update_budget or create_campaign, nor does it mention that budgets are typically created before being attached to campaigns. This leaves the selection decision entirely to the agent's inference 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?

Beyond the annotations, the description adds important behavioral details: the operation is a single atomic creation involving both budget and campaign, and campaigns start as PAUSED by default for safety. This informs the agent about side effects and safety defaults that annotations alone do not convey. No contradiction with annotations.

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

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

The description is well-structured with a clear intro followed by an Args bullet list. There is minor redundancy between the first and second sentences (both convey creation of a campaign and budget), but overall it is focused and each bullet 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?

With 11 parameters, no output schema, and 0% schema coverage, the description is impressively complete on inputs, covering all parameters and key defaults. However, it does not describe the return value or result format, which would be useful given there is no output schema. Still, for a creation tool, the input guidance is strong enough to be considered almost complete.

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

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

Schema description coverage is 0%, so the description carries the full burden for parameters. It does so thoroughly, explaining formats, defaults, conditional requirements (e.g., target_cpa required with TARGET_CPA), and accepted values for channel_type and bidding_strategy. This adds substantial meaning beyond the bare input 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 opens with a specific verb and resource: 'Create a new campaign with a budget.' It also clarifies that it creates both the campaign budget and the campaign in one atomic operation, which distinguishes it from related tools like create_budget and create_performance_max_campaign. The purpose is unmistakable.

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

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

The description states that the operation is atomic and creates both budget and campaign together, implying it is the right tool when both need to be created in one step. It does not explicitly name alternatives or state when not to use it, but the atomic-operation framing provides clear contextual 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?

Annotations already indicate the operation is not read-only, not idempotent, and not destructive. The description adds useful context by specifying the ad can serve on multiple channels and includes constraints like character limits and default status, but it does not disclose side effects such as duplicate creation on repeated calls or dependency on previously uploaded assets.

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

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

The description is well-structured with a clear one-line purpose followed by a compact argument list. Every listed item adds needed parameter context, though some lines simply restate what the schema already provides via titles and types.

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 all input parameters and their constraints, which is strong for a 10-parameter creation tool. However, with no output schema, it omits what the tool returns or how errors surface, leaving an agent without expectations for the operation's result.

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 carries the full parameter documentation burden. It explains each parameter beyond the raw schema, including counts for headlines/descriptions, character limits, image types, optional CTA, and the status default, which is meaningful added 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 the tool creates a Demand Gen ad and distinguishes it by specifying the channels it serves on (YouTube, Gmail, Discover). This differentiates it from sibling ad creation tools like create_responsive_search_ad and create_video_ad without needing to open any schemas.

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

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

The description implies the tool is for Demand Gen campaigns by requiring the ad group to be in such a campaign and by naming the ad type. However, it does not explicitly state when to prefer this tool over sibling ad creation tools or provide any exclusions or alternative routing.

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

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

Beyond the annotations, the description adds meaningful behavioral details: it creates everything atomically using temporary IDs, defaults to PAUSED for safety, and requires images to be pre-uploaded. This gives an agent useful operational context without contradicting the annotations.

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

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

The description is well-structured: purpose first, then safety/behavior, then requirements, then an Args list. It is longer than average but justified by the complexity of a 17-parameter composite creation tool. A few parameter one-liners like 'Campaign name.' add little, but the overall structure is 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?

For a complex creation tool with no output schema, the description covers inputs, defaults, prerequisites, and safety behavior thoroughly. It does not explain return values or clarify edge cases like conflicting target_cpa/target_roas with bidding_strategy, but these are relatively minor given the strength of the rest.

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 carries the full burden—and it delivers. It documents all 17 parameters with practical semantics, including ranges, char limits, dimensions, business constraints, and bidding-strategy-specific targets like target_cpa and target_roas.

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

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

The description opens with a specific verb and resource: 'Create a complete Performance Max campaign with budget, campaign, and asset group.' It clearly explains the tool's scope and distinguishes it from generic campaign tools by emphasizing the atomic batch creation of all three components.

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

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

The description gives clear context for when to use this tool: you need a complete Performance Max campaign and want everything created in one atomic operation. It also lists PMax minimum requirements and notes that image assets should be pre-uploaded, which serves as a precondition. It does not explicitly name alternatives like create_campaign or add_assets_to_group, so it stops short of a 5.

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

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

There is no contradiction with the annotations: readOnlyHint=false matches 'Create.' The description adds a useful precondition (ad group must be in a Display campaign) and detailed input constraints, but it does not describe return values, side effects, validation failures, or asset preconditions. Since the annotations already signal a mutating, non-idempotent operation, the added behavioral context is moderate.

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

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

The description is a tightly organized docstring-style parameter list with no filler. The purpose sentence is front-loaded, and every line in the Args section adds a meaningful constraint or definition. It is appropriately sized for a tool with 12 parameters.

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 12-parameter creation tool with no output schema, the description thoroughly covers all inputs and validation constraints, making it highly actionable. The main gap is the lack of return-value or failure-behavior information (e.g., what happens if the ad group is invalid or asset resource names do not exist), but the parameter coverage is strong enough for correct invocation.

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

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

Schema description coverage is 0%, and the description fully compensates. It explains every parameter, including cardinalities (1-5 headlines, 1-5 descriptions), max character lengths (30/90/25), image dimensions (1200x628, 1200x1200), the default status, and the constraint that ad_group_id must be in a Display campaign.

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

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

The description opens with a specific verb and object: 'Create a Responsive Display Ad for Display campaigns.' This clearly distinguishes it from sibling tools like create_responsive_search_ad, create_video_ad, and create_demand_gen_ad, which target different ad formats.

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 by stating the tool is for Display campaigns and explicitly warns that the ad_group_id must belong to a Display campaign. It does not explicitly name alternative tools or state when-not-to-use, but the Display campaign scope makes the routing decision fairly unambiguous.

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

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

Annotations already indicate this is a non-read-only, non-idempotent, non-destructive write operation. The description adds useful behavioral context: 'Google will automatically test combinations of headlines and descriptions.' It does not elaborate on side effects, response behavior, or failure modes, but given annotation coverage the description provides reasonable added value.

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

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

The description is well-structured with a brief purpose statement, a useful behavioral note, and a clean argument list. Every sentence and line adds necessary constraint information without redundancy or filler.

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

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

For a tool with 8 parameters, all parameter semantics are covered, including defaults and dependencies. There is no output schema and the description does not mention return values, which is a minor gap, but the information needed to invoke the tool correctly is present and complete.

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

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

Schema description coverage is 0%, yet the description thoroughly documents every parameter: customer_id, ad_group_id with a Search campaign constraint, headlines count/length limits, descriptions count/length limits, final_urls requirement, path constraints including the path2-requires-path1 rule, and status enum values. This fully compensates for the schema's lack of 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 states a specific action ('Create a Responsive Search Ad') and clearly scopes it to 'Search campaigns.' This distinguishes it from sibling tools like create_responsive_display_ad and create_video_ad, so an agent can tell them apart without opening schemas.

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

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

The description gives clear context by specifying that the ad group 'must be in a Search campaign,' which implies this tool is for Search campaign ad creation. However, it does not explicitly name alternative tools or state when not to use this tool, so it stops short of full usage differentiation.

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

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

Annotations already indicate a non-read-only, non-idempotent mutation. The description adds concrete creation behavior, the Video-campaign constraint, default status ENABLED, and meaningful ad_format differences (skippable, 6-sec non-skip, in-feed). It does not disclose permissions, failure modes, or return payload, so it is not fully transparent.

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 one-sentence purpose is front-loaded, followed by a clean one-line-per-parameter list. Every parameter is covered without prose padding or redundant narrative.

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 output schema and 10 parameters, the description covers all input semantics and the critical campaign-type constraint. It omits the return shape or created-ad resource name, which is a minor but real gap for a creation 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?

The schema provides no property descriptions, but the Args block fully compensates by documenting all 10 parameters. It includes an example YouTube ID, CTA examples, expansion of ad_format options, defaults, and optional/required distinctions.

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 opens with 'Create a Video ad for Video campaigns (YouTube)', giving a specific verb, resource, and channel. It clearly differentiates from sibling ad-creation tools like create_responsive_search_ad and create_demand_gen_ad by scoping to Video 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?

States the key prerequisite that ad_group_id must be in a Video campaign, and documents defaults for status and ad_format. It does not explicitly name alternatives or when-not-to-use conditions, but the Video-campaign scoping gives clear selection context.

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

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

The readOnlyHint and openWorldHint annotations already convey the safety and scope profile, and the description aligns by saying 'read query' and 'most flexible.' It adds some context about arbitrary query execution, but does not disclose potential behavior like pagination, result shape, or query limits. This is acceptable but not rich given annotation coverage.

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

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

The description is compact, front-loaded with the core purpose, and the Args section organizes parameter details clearly. Every sentence contributes useful information, including the external GAQL reference link.

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 arbitrary-query nature, empty schema descriptions, and lack of output schema, the description covers the essentials: purpose, fallback usage, arguments, and a reference link. It is slightly incomplete in not mentioning output shape or query limits, but the external reference and generic nature mitigate this.

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

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

With 0% schema description coverage, the description compensates by explaining both parameters: customer_id as a Google Ads customer ID and query as a full GAQL string with SELECT/FROM/WHERE structure. It adds real meaning beyond the bare schema, though the customer_id format is left underspecified.

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 executes an arbitrary GAQL read query, using a specific verb and resource. It explicitly positions itself as the flexible catch-all for queries not covered by other tools, which differentiates it from the large sibling tool set.

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

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

It provides explicit selection guidance: use this tool for any read query not covered by other tools. This both states when to use it and implies when not to use it, namely when a dedicated tool already exists for the query.

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

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

Annotations already declare readOnlyHint=true, which covers safety. The description adds useful behavioral context about the optional customer_id: 'Uses default if not provided.' This clarifies behavior beyond what the schema alone shows. It does not contradict the annotations.

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

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

The description is compact and front-loaded, with no filler. The main purpose appears first, followed by a clarifying sentence and a concise parameter note. Every part earns its place.

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

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

For a simple tool with one optional parameter and read-only annotations, the description is nearly complete. The only notable gap is ambiguity about whether 'all child accounts' means direct children only or a recursive hierarchy tree, which matters for some callers.

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 does so by defining customer_id as 'MCC customer ID' and explaining the default behavior. This gives essential meaning to an otherwise bare schema parameter, though it omits format specifics like numeral vs hyphenated ID.

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

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

The description clearly identifies the verb ('Get'), the resource ('MCC account hierarchy tree'), and the scope ('lists all child accounts under the given MCC account'). This makes it distinguishable from siblings like get_account_info or list_accessible_accounts.

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: use this when you need child accounts under an MCC account. However, it does not explicitly state when not to use it or mention alternative tools that might be more appropriate for retrieving a single account or accessible accounts.

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

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

Annotations already mark the tool as readOnlyHint=true and openWorldHint=true, and the description is consistent with those hints. The description adds only a hint of the returned fields rather than deeper behavior such as access requirements, error cases, or output structure, which is acceptable for a simple read-only getter but not rich.

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

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

The description is very concise, front-loads the purpose in the first sentence, and then clearly documents the argument. Every sentence earns its place with no redundant or filler content.

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

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

The tool is simple and the annotations cover read-only safety, but there is no output schema and the description only says 'etc.' rather than enumerating the expected response fields. It also does not clarify that this is for account configuration details rather than performance data, leaving minor ambiguity relative to nearby account-related tools.

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

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

Schema description coverage is 0%, so the description must compensate, and it does so effectively. The Args section explains the single parameter and gives concrete valid formats ('123-456-7890' or '1234567890'), which is essential for 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?

The description states a specific verb ('Get') and resource ('details for a Google Ads account'), and gives characteristic fields such as name, currency, and timezone. It is clearly distinct from list_accessible_accounts and get_account_hierarchy, though it does not explicitly differentiate itself from get_account_performance_summary.

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 its siblings. It implies that it is for account-level details like name/currency/timezone, but it does not state exclusions, alternatives, or when to prefer another tool such as get_account_performance_summary.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds the daily granularity and account-level scope but does not disclose what performance metrics are returned, how data is aggregated, or timezone/currency conventions. No contradiction with annotations.

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

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

The description is short and front-loaded, with the core purpose stated in the first sentence. The Args block provides necessary parameter context without unnecessary filler.

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

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

The tool is simple with 2 parameters and read-only annotations, so the basic call surface is understandable. However, there is no output schema, and the description leaves ambiguous what 'performance summary' includes, what predefined date ranges are allowed, and how results are structured. These gaps matter for a reporting tool.

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

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

Schema description coverage is 0%, so the description carries the burden of parameter meaning. It does clarify date_range by showing 'YYYY-MM-DD,YYYY-MM-DD' and mentioning predefined values, but it does not enumerate the accepted predefined values. customer_id is minimally explained as 'Google Ads customer ID', adding little beyond the schema title.

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

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

The description uses a specific verb ('Get') with a clear resource ('account-level daily performance summary'). The 'account-level' scope distinguishes it from sibling tools like get_campaign_performance and get_ad_group_performance.

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

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

The phrase 'account-level daily performance summary' provides clear context for when this tool is appropriate versus campaign-, ad-group-, or keyword-level reporting tools. It does not explicitly list exclusions or alternatives, but the scoping is strong enough to guide selection.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the read-only behavior is covered. The description adds useful output context by listing ad details like headlines, descriptions, URLs, and assets, but it does not disclose other behavioral aspects such as response size, errors, or permissions. This is adequate given the annotations.

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

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

The description is compact and front-loaded with the tool's purpose. The Arg list is necessary because the schema provides no parameter descriptions, and every line contributes useful, non-redundant context. No filler or promotional language appears.

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

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

For a simple three-parameter, read-only tool, the description is mostly usable. However, with no output schema, the return-value description is only a high-level list of content categories and does not explain the response structure or how these fields are organized. It is minimally viable but leaves gaps.

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

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

Schema description coverage is 0%, so the description must compensate. It does provide an Args section explaining each parameter: customer_id is a Google Ads customer ID, ad_group_id is the containing ad group, and ad_id is the ad ID. This adds some meaning beyond the bare schema titles, but the descriptions remain shallow and largely restate the parameter names.

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

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

The description uses a specific verb and resource: "Get full details of an ad," and enumerates the content areas returned (headlines, descriptions, URLs, assets). This clearly distinguishes it from sibling tools like list_ads (listing ads) and get_ad_group (ad group details).

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: when a caller needs complete details for a specific ad after already having the three IDs. However, it does not explicitly state when to prefer this over list_ads, get_ad_group, or other detail-fetching tools, nor does it mention how to obtain the required IDs.

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

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

Annotations already declare readOnlyHint=true, and the description adds no behavioral context beyond the basic read operation. It does not disclose return shape, not-found behavior, or the implications of openWorldHint, such as potentially varying returned fields. It does not contradict the annotations, but it adds little value beyond them.

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 first sentence is clear and front-loaded, and the Args block is minimal with no padding. It is appropriately sized for a two-parameter tool, though the parameter lines add only marginal value over the schema titles.

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

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

For a simple read-by-ID tool with two required string parameters and readOnlyHint, the description is minimally viable: an agent can construct a valid call. However, because there is no output schema and no description of return content or error behavior, completeness is only partial.

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 carries the burden of explaining parameters. It only provides generic glosses like 'Google Ads customer ID' and 'Ad group ID,' which essentially restate the parameter titles. It adds no format, validation, or relationship information, so it does not adequately compensate 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 states a specific verb and resource: 'Get details for a single ad group.' The word 'single' distinguishes it from list_ad_groups, but it does not explicitly contrast with get_ad_group_performance or get_ad_details, leaving some ambiguity about whether 'details' means entity fields or performance data.

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

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

There is no guidance on when to use this tool versus list_ad_groups, get_ad_group_performance, or other sibling retrieval tools. The Args block only documents parameters; no context, prerequisites, or exclusions are provided, so the agent must infer usage from the tool name alone.

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

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

The annotations already declare readOnlyHint=true and openWorldHint=true, covering the safety profile. The description adds scoping behavior (campaign_id filter and accepted date_range forms) but does not disclose return shape, metric fields, pagination behavior, or failure modes.

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 definition leads with a one-sentence purpose then a tight Args list; no line is wasted. It is appropriately sized for a four-parameter read-only tool.

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

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

Together with schema defaults and annotations, the description provides enough to construct a valid call: required customer_id, optional campaign_id filter, date_range format, and limit. The main missing context is the exact set of returned metrics and how this report differs from sibling performance tools, but the core invocation requirements are covered.

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

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

With 0% schema description coverage, the Args section compensates by giving a meaningful explanation for customer_id, campaign_id, date_range, and limit, including the optional flag, accepted date formats, and default max rows. It does not enumerate the valid predefined date_range values, which would make it fully unambiguous.

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

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

The description opens with a clear verb and resource: 'Get ad group performance metrics,' so an agent immediately knows this is a read-only retrieval for ad-group-level metrics. It does not explicitly contrast itself with sibling tools such as get_campaign_performance or get_keyword_performance, so differentiation is left to the name.

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 title and args make the basic use case obvious—fetch ad group metrics, optionally scoped by campaign_id—so usage is implied. However, there is no explicit statement of when to choose this tool over the many sibling performance/report tools, nor any exclusions or alternative recommendations.

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

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

Annotations already communicate that the operation is read-only and open-world. The description adds that the result includes linked assets and signals, but it does not disclose response structure, pagination, or other behavioral traits. Given annotation coverage, this is adequate but not rich.

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

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

The description is short and front-loads the core purpose. The Args section is somewhat redundant with the input schema, but because the schema has no field descriptions, the inline arg annotations still provide some value. Overall it is concise and not bloated.

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

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

This is a relatively simple read-only retrieval with two required parameters and no output schema. The description states what the result covers ('linked assets and signals'), but 'full details' remains vague and no return structure is described. It is minimally viable but leaves room for ambiguity.

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 must compensate. It provides 'Google Ads customer ID' for customer_id, which adds meaning, but asset_group_id is merely restated as 'Asset Group ID' with no format or example. The compensation is partial.

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

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

The description uses a specific verb ('Get') and resource ('asset group') and clarifies the scope: 'full details' including 'linked assets and signals.' This clearly distinguishes the tool from list_asset_groups, which lists groups rather than retrieving one group's details.

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 that this tool is for retrieving detailed information about a single asset group, but it does not explicitly state when to use it versus alternatives like list_asset_groups or get_asset_performance. Usage context is present but only by implication.

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

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

Annotations already establish readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds useful context by specifying the return kind (performance labels) and filter scope, but does not disclose other behavioral traits such as data aggregation, label thresholds, or response shape.

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

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

The description is concise and well-structured: a clear one-sentence purpose followed by an Args list with each parameter on its own line. There is no redundant or filler content.

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

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

For a simple read-only lookup tool with only one required parameter, the description is largely complete: it states the domain (PMax), the purpose, the output labels, and the optional filters. It could be slightly more explicit about what is returned when no filters are provided, but the overall context is 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 description coverage is 0%, so the description carries the burden of explaining parameters. It provides one-line explanations for all three parameters, including that campaign_id and asset_group_id are optional filters, which adds meaning beyond the bare property names.

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 a specific verb ('Get'), resource ('asset-level performance labels'), and scope ('for PMax'). It also names the output labels (BEST, GOOD, LOW), which distinguishes it from sibling performance tools that operate at campaign, ad group, keyword, or placement 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 makes the use case clear: retrieving PMax asset-level performance labels, with optional filtering by campaign and asset group. It does not explicitly name alternatives or state when not to use the tool, but the asset-level and PMax context is enough to guide selection.

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

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

Annotations already declare readOnlyHint=true, and the description does not contradict that. It adds some behavioral context by noting per-campaign utilization and the optional campaign filter, but it does not describe aggregation, response shape, or any open-world output behavior despite openWorldHint=true.

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 purpose is front-loaded and the Args block is scannable. The second sentence is slightly redundant with the first, but the overall length is appropriate and the description stays focused.

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

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

For a read-only reporting tool with only three parameters, the description covers the invocation essentials: customer_id, date range, and optional campaign filter. It lacks an explicit return-value description, but 'shows how much of each campaign's budget has been utilized' gives a serviceable picture of the output.

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 must carry the documentation burden. It does define all three parameters, gives the date_range format with an example, and marks campaign_id as optional. It could be stronger by listing the possible predefined date range values.

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

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

The description opens with a specific verb and resource: 'Get budget vs actual spend for campaigns.' The second sentence clarifies the outcome, showing per-campaign budget utilization. This clearly distinguishes the tool from budget-definition tools like list_budgets and from general performance-report 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 does not explicitly state when to use this tool instead of siblings such as list_budgets or get_campaign_performance, nor does it name any alternatives. The use case is implied by 'budget vs actual spend,' but an agent must infer the appropriate context from the meaning alone.

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

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

The readOnlyHint and openWorldHint annotations already communicate the safe read-only nature, and the description does not contradict them. It adds only the single-campaign scoping, but does not describe return shape, error behavior, or any special operational quirks, so it provides modest value beyond the annotations.

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

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

The description is short and front-loaded with the purpose statement, followed by a compact Args section. There is no filler or redundant prose, though the content is so minimal that it borders on under-specification rather than being a model of concise completeness.

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 two-parameter read-only getter, the description is minimally viable, but gaps remain. It does not describe what fields 'details' includes, returns no output schema, and gives no information about failure modes or how this differs from performance-reporting campaign tools. The annotations cover safety, but the description alone is only barely adequate.

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 must compensate. It provides only minimal restatements—'Google Ads customer ID' and 'the campaign ID'—which mostly echo the property names and do not explain ID formats, validity rules, or how to obtain the values. Some domain context is added, but it is not enough to fully support 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?

The description uses a specific verb and resource: 'Get details for a single campaign.' It clearly indicates the tool returns information about one campaign, which distinguishes it from list-style tools, though it does not explicitly call out or contrast with sibling tools like get_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?

There is no guidance about when to use this tool versus alternatives such as list_campaigns or get_campaign_performance. The only implied context is that it targets a single campaign, but no exclusions, prerequisites, or alternative routing are provided.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds useful context like configurable date ranges and a row limit, but it does not disclose the return format, metric fields, aggregation, or any potential quirks for a metrics-reporting 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 front-loaded with a clear one-sentence purpose, followed by a compact and structured Args list. Every line adds necessary semantic information that the schema does not provide, with no filler or repetition.

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?

All required parameters are explained in enough detail for a knowledgeable agent to invoke the tool. However, with no output schema, the description does not state which campaign performance metrics are returned or what the response rows look like, leaving a meaningful gap for interpreting results.

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

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

Schema description coverage is 0%, so the description carries the full burden for parameter meaning. It documents all five parameters clearly, including predefined and custom date-range formats, acceptable status filter values, and the default limit.

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

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

The description opens with a specific verb and resource: 'Get campaign performance metrics over a date range.' This clearly identifies the operation and distinguishes it from sibling tools like get_campaign, get_ad_group_performance, or get_account_performance_summary.

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 tool's intended use is implied by the name and description—campaign-level performance reporting—but there is no explicit guidance about when to choose it over alternatives such as get_campaign or get_keyword_performance. No exclusions or selection conditions are stated.

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

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

Annotations already mark the tool read-only and open-world, and the description adds concrete behavioral context by specifying that the output is selectable, filterable, and sortable field metadata. It also discloses that customer_id falls back to a default when omitted. There is no contradiction with the annotations.

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

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

The description is a single purpose sentence plus a compact Args block, with no filler or redundant restatement of the input schema. The primary purpose is front-loaded, and every line contributes meaningful information.

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

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

For a simple read-only two-parameter metadata tool, the description adequately covers purpose, parameter semantics, and default behavior. The absence of an output schema means the exact return shape is implied rather than explicit, but the description names the three field categories expected, which is sufficient for most usage.

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

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

Schema description coverage is 0%, so the description carries the full burden for explaining parameters. It explains resource_type with three concrete GAQL examples ('campaign', 'ad_group', 'ad_group_ad') and notes customer_id's default behavior. However, customer_id is still only described as 'Customer ID' without any format, prefix, or validation details.

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

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

The description opens with 'Get selectable, filterable, and sortable fields for a GAQL resource' – a specific verb with a clear resource and result type. It distinguishes this tool from data-returning siblings like execute_gaql and list_gaql_resources by focusing on field metadata rather than query execution or resource enumeration.

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 used when preparing or understanding GAQL queries by exposing the resource's queryable fields. However, it never explicitly says when to prefer this tool over siblings such as list_gaql_resources or execute_gaql, nor does it provide any exclusions or decision rules.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the description does not need to restate safety. But the description adds no behavioral context beyond that: no response shape, no ordering, no pagination behavior, no rate-limit or error characteristics. Since there is no output schema, this gap is significant.

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

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

The description is compact and front-loaded with the purpose sentence, followed by a scannable parameter list. Every line adds value and there is no filler or repetition of schema information beyond the necessary semantic clarifications.

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?

Inputs are fully documented and the tool's purpose is clear, which makes it minimally viable for invoking. However, with no output schema and a nearly identical sibling named get_keyword_performance_report, the description should clarify what performance metrics are returned or how this tool differs, so an agent can confidently select and interpret the result.

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%, and the description compensates well by explaining all four parameters with meaningful context: customer_id, ad_group_id, date_range format including a custom pattern, and limit with its default. This fully bridges the schema gap.

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

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

The first sentence clearly states the action ('Get'), the resource ('keyword performance metrics'), and the scope ('for an ad group'). However, it does not differentiate from the sibling tool get_keyword_performance_report, which appears to serve a nearly identical 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?

There is no guidance about when to choose this tool instead of get_keyword_performance_report, get_ad_group_performance, or other performance-report siblings. The only usage signal is the ad-group scoping, but that is too weak to route an agent reliably to this specific tool.

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

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

The annotations already declare readOnlyHint=true and openWorldHint=true, and the description's 'Get' wording is consistent with those annotations. However, the description adds little behavioral context beyond that, such as pagination behavior, data freshness, or what the returned report contains.

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

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

The description is compact and well-structured: a one-line purpose followed by a clear parameter list. Every sentence adds useful information and there is no redundant or marketing-style filler.

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

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

For a read-only report tool, the description plus schema and annotations is mostly complete: all parameters are documented and the intent is clear. The main gap is that the exact metrics returned are not specified and the relationship to the similarly named get_keyword_performance tool is not clarified.

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 carries the full burden of explaining parameters. It does this well by describing all five parameters, including optionality, the date range format, and the limit default, which is essential for 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?

The description states a clear action ('Get') and a specific resource ('keyword-level performance metrics'), so an agent can identify it as a read-only reporting tool. However, it does not distinguish this tool from the sibling get_keyword_performance, which sounds nearly identical and could easily be confused with it.

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

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

The description provides no guidance on when to choose this tool over alternatives such as get_keyword_performance, get_campaign_performance, or get_search_terms_report. It only lists parameters and filters, leaving the selection decision entirely to the agent.

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

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

Annotations already mark this as readOnlyHint=true and openWorldHint=true, so the safety profile is clear. The description adds useful behavioral context by specifying the breakdown dimensions and confirming the acceptable date_range format, which goes beyond the structured annotations.

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

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

The description is compact and front-loaded with the tool's purpose, followed by a minimal parameter list. Every sentence earns its place, and there is no redundant filler or repetition of schema defaults.

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

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

For a simple read-only report tool with three string parameters and no output schema, the description covers the core invocation requirements: required IDs and the date range format. It could go further by naming the returned metrics, but the listed placement breakdown gives sufficient operational context.

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 must explain the parameters, and it does: customer_id, campaign_id, and date_range are each given a brief semantic definition. It also clarifies that date_range accepts either predefined values or a comma-separated explicit range, compensating well for the schema's missing 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 begins with a specific verb and resource: 'Get PMax placement performance breakdown' and enumerates the placement channels (Search, YouTube, Display, Discover, Gmail). This clearly distinguishes it from sibling performance tools like get_campaign_performance or get_asset_performance by naming the unique PMax placement dimension.

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 PMax placement breakdowns but does not explicitly state when to choose it over related siblings such as get_campaign_performance or get_ad_group_performance. There is enough context for an agent to infer the intended use, but no explicit exclusions or alternative routing.

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

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

Annotations already mark the operation as readOnlyHint=true, so the safety profile is covered. The description adds no behavioral context beyond that—no mention of return shape, pagination, timezone, data availability, or rate limits—so it contributes little beyond the annotations.

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

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

The description is one clear sentence plus a compact Args block. Every line adds parameter information not present in the schema, with no filler or repetition.

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

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

For a read-only reporting tool with 5 parameters and no output schema, the description covers all invocation inputs and clarifies the date-range format. It does not describe the returned fields/metrics, which is a minor gap given no output schema, but the description is otherwise sufficient to select and call the tool.

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

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

Schema description coverage is 0%, and the description fully compensates by explaining every parameter: customer_id, optional filters, date_range accepted formats ('predefined or YYYY-MM-DD,YYYY-MM-DD'), and limit default. This adds meaning well beyond the bare 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 uses a specific verb and resource, 'Get search terms that triggered your ads,' making the tool's function immediately clear. It does not explicitly differentiate itself from sibling reporting tools like get_keyword_performance_report, so it lacks the sibling-distinction element required for a 5.

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

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

No guidance is given on when to choose this tool over sibling reporting tools such as get_keyword_performance_report or get_campaign_performance. The intended context is only implied by the tool name and first sentence; there are no exclusions, prerequisites, or alternative references.

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

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

Annotations already declare readOnlyHint and openWorldHint, and the description adds useful auth-related context: results depend on the authenticated MCC or direct account. This goes beyond the structured annotations without contradicting them.

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

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

The description is two short sentences with the action and scope front-loaded, followed by a clarifying statement about authentication context. There is no filler or redundant repetition of schema information.

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

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

For a simple zero-parameter, read-only listing tool with no output schema, the description tells the agent exactly what it returns and under which credential context. Nothing essential is missing given the low complexity.

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

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

The tool has zero parameters and the schema coverage is 100% with an empty properties object. The description appropriately avoids parameter discussion, and the baseline for a zero-parameter tool is satisfied.

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

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

The description uses a specific verb ('List') and a clear resource ('all Google Ads accounts accessible via current credentials'). It distinguishes itself from sibling tools like get_account_hierarchy and get_account_info by focusing on enumeration of accessible accounts rather than hierarchy structure or single-account details.

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 clearly indicates when to use the tool: to enumerate accounts available through the current authenticated credentials, whether via an MCC or direct account. It does not explicitly name alternatives or exclusions, but the context is unambiguous for a zero-parameter listing tool.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds useful behavior like status filtering and the default limit, but does not disclose pagination, sorting, or required permissions. No contradiction with annotations.

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

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

The description is compact and well-structured: one clear purpose sentence followed by a concise argument list. Every line adds meaning with no filler or redundant restatement.

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

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

For a simple read-only list operation, the description covers the essential call inputs and constraints. It does not describe the response shape or pagination behavior, but the absence of an output schema and the simplicity of the operation make this a minor gap.

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

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

Schema description coverage is 0%, and the description fully compensates by explaining all four parameters: customer_id, campaign_id, optional status_filter with allowed values, and limit's default. This gives an agent exactly what it needs to build a valid call.

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

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

The description opens with a specific verb, 'List', names the resource, 'ad groups', and scopes it to 'a campaign'. This clearly distinguishes it from siblings like get_ad_group (single ad group) and list_ads (ads within 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 context — list ad groups within a campaign — but it does not explicitly state when to use this tool versus get_ad_group or list_ads, nor does it mention any exclusions. Guidance is left to inference.

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

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

Annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds useful context that results include approval status, but it does not describe pagination, filtering behavior beyond the parameter, or other response characteristics. This is adequate given the annotation coverage.

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

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

The description is two focused parts: a one-sentence purpose and a compact Args block. Every line earns its place, and the main purpose is front-loaded before parameter details.

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

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

For a read-only list operation with annotations covering safety and open-world semantics, the description supplies enough information to invoke the tool correctly: purpose, required ids, optional filter, and limit. No output schema exists, but the phrase 'with approval status' gives the main expected return context.

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%, and the description fully compensates by explaining every parameter: customer_id, ad_group_id, status_filter with allowed example values, and limit with default and meaning. It adds value well 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 states a specific operation: 'List ads in an ad group with approval status.' This clearly distinguishes it from siblings like list_ad_groups (lists groups) and get_ad_details (single ad detail), and the resource and plural scope are 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?

It clearly implies the tool is for retrieving ads within a specific ad group, and it defines the optional status_filter. It does not explicitly name alternatives or exclusion criteria, but the context is sufficiently clear for selecting it over the read/ad-group siblings.

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

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

The readOnlyHint and openWorldHint annotations already establish that this is a safe read operation. The description adds the Performance Max scoping constraint but does not disclose return format, pagination, or other behavioral traits, so the added value over annotations is modest.

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 short and front-loaded with the core purpose, followed by a compact two-item argument list. Every sentence earns its place with no redundancy or fluff.

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

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

The tool is simple with two string parameters and annotations cover the read-only safety profile. However, there is no output schema and the description does not describe what the returned asset groups contain or whether pagination applies, which is a notable gap for an agent consuming the result.

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 must carry parameter meaning. The Args section defines customer_id as 'Google Ads customer ID' and campaign_id as 'PMax campaign ID', adding important semantic context absent from the raw schema. It lacks format examples, but the core meaning is clearly conveyed.

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 'List asset groups in a Performance Max campaign' uses a specific verb and resource and clearly scopes the operation to PMax campaigns. This distinguishes it from sibling tools like list_ad_groups (ad groups) and get_asset_group_details (single asset group).

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

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

The description implies usage context by restricting to Performance Max campaigns, telling an agent this tool applies to PMax campaign asset groups. However, it offers no explicit guidance on when not to use it or which alternative sibling (e.g., list_ad_groups) to choose, so the agent must infer the 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?

The annotations already provide readOnlyHint=true and openWorldHint=true, so the description does not need to restate read-only intent. It adds no additional behavioral context such as pagination, ordering, default scope, or whether results may be partial.

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

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

The description is compact and front-loaded: one clear purpose sentence followed by a small Args block that earns its place by adding parameter context. There is no fluff or redundancy.

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

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

For a simple two-parameter list tool, the description covers the essential calling contract: what is being listed, at what scope, and the optional limit. It is slightly thin on return shape or pagination behavior, but the annotations and simple operation make this adequate.

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 description compensates by explaining both parameters: customer_id is the Google Ads customer/account ID, and limit caps the number of budgets returned with a default of 100. This is meaningful beyond the bare 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 states a specific verb ('List') and resource ('campaign budgets') with account scope, making the tool's purpose unambiguous. It does not explicitly contrast with sibling budget tools like create_budget or update_budget, but the read-only list action is clear enough.

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

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

Usage is implied: use this tool when you want to list campaign budgets in a specified account. However, there is no explicit guidance about when to prefer it over related budget tools such as create_budget, update_budget, or get_budget_utilization.

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 burden. It does make the read-only nature clear via 'List' and states the default limit behavior, but it does not disclose pagination, ordering, return shape, or what a null status_filter means. Adequate but incomplete.

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?

Core sentence is front-loaded and the Args list is compact. It loses a point only because the Args section partially duplicates schema defaults rather than adding entirely new structure.

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 list tool with no output schema, the description covers invocation parameters and default behavior, but it omits return value shape, pagination/ordering, and the exact customer_id format. It is sufficient for basic use, not fully 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?

The Args block adds meaning absent from the schema: status_filter allowed values ('ENABLED'/'PAUSED'/'REMOVED'), limit's max-return behavior and default, and customer_id's purpose. The customer_id explanation is thin, which keeps this from a 5.

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

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

States a specific verb ('List') and resource ('campaigns in a Google Ads account'), and the plural 'campaigns' plus 'list' separates it from get_campaign. It does not explicitly contrast with sibling tools, so it stops short of 5.

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

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

The intended use is implied by 'List campaigns' and the optional status_filter/limit arguments, but there is no when-to-use guidance, no exclusions, and no mention of get_campaign or get_campaign_performance as alternatives. Context must be inferred from tool name and sibling list.

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

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

Annotations already establish readOnlyHint=true. The description adds useful behavioral nuance by saying it returns 'commonly used resource names', which signals the list may not be exhaustive and is scoped to practical usage. This goes beyond the annotation without contradicting it.

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

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

Two short sentences with no filler. The purpose is front-loaded in the first sentence, and the second sentence clarifies the return value. Every word contributes useful information.

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

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

For a zero-parameter, read-only list tool, the description is complete: it states what is listed, why it is useful, and what the caller gets back ('resource names'). No additional schema or output schema is needed to make the tool safely callable.

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

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

The tool has zero parameters and the schema has no properties, so the description does not need to explain parameter meaning. The baseline for zero-parameter tools is 4, and the description correctly avoids adding irrelevant parameter details.

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

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

The description states a specific verb and resource: 'List available GAQL FROM-clause resources' and explicitly ties it to execute_gaql. It is clearly differentiated from siblings like execute_gaql and get_field_metadata, which do different things.

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

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

The phrase 'for use with execute_gaql' gives clear contextual usage: call this when you need to know which FROM-clause resources are available before running a GAQL query. It does not explicitly list exclusions or alternatives, but the context is strong enough for an agent to select it appropriately.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds the ad-group scoping and the optional status/limit behavior, but it does not disclose return format, ordering, pagination, or error behavior. This is acceptable given the annotations but not rich.

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

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

One crisp purpose sentence followed by a compact argument list. Every line adds value, and the most important scoping phrase 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?

All required inputs and the optional parameters are covered, and the read-only/open-world behavior is already in annotations. The only gap is the lack of an output schema or return-value description, so an agent cannot predict the exact shape of the keyword 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%, yet the description explains all four parameters in natural language. It provides the exact allowed values for status_filter and clarifies limit's default and meaning, which is essential because the schema has no enum or per-parameter descriptions.

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

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

The description opens with a specific verb and resource: 'List keywords in an ad group.' This clearly scopes the operation and distinguishes it from sibling tools like list_ad_groups and list_ads, which target different resources.

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 first sentence implies the intended use case: retrieve keywords that belong to a specific ad group. However, it does not explicitly mention alternatives such as add_keywords, remove_keyword, or get_keyword_performance, nor does it state when not to use this tool.

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

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

Annotations already mark the operation as destructive and non-read-only. The description adds useful behavioral context by stating confirm_removal 'Must be True to proceed,' which signals a required confirmation guard beyond what the schema alone indicates. The use of 'unlink' also clarifies the semantic effect of the removal.

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

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

The description is compact and well-structured: a one-sentence summary followed by a clear parameter list. Every sentence adds value, and the most important behavioral guard (confirm_removal must be True) is explicitly stated without extraneous detail.

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

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

For a destructive operation with five parameters and no output schema, the description covers the key invocation requirements: action, target asset, group, field type, and confirmation. It does not describe post-conditions or error cases, but the annotations and parameter explanations cover most of what an agent needs to call it correctly.

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

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

With 0% schema description coverage, the description compensates well by explaining all five parameters. It adds meaningful detail such as 'full resource name' for asset_resource_name, examples for field_type, and the mandatory nature of confirm_removal. Some parameter explanations remain minimal, but all are addressed.

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

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

The description opens with a specific verb and resource: 'Remove an asset from an asset group.' It also clarifies the operation as 'unlink' in the parameter list, making the intent unambiguous and distinguishing it from the sibling add_assets_to_group.

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

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

The intended use is implied by the action itself: use when unlinking an asset from an asset group. However, the description provides no explicit guidance about when not to use it or which sibling alternatives exist, so the agent must infer context from the tool name and sibling list.

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

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

Beyond the annotations, the description discloses that this is a soft-delete, that the campaign status becomes REMOVED, and that confirm_removal must be True. This adds meaningful behavioral context beyond the structured destructiveHint and readOnlyHint annotations.

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

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

The description is compact and front-loaded, with the core action stated first, followed by a warning and a concise parameter list. Every sentence contributes essential operational information without redundancy.

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

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

For a simple three-parameter destructive operation with annotations already covering safety and idempotency, the description is nearly complete. It does not mention return values or side effects on child entities, but the lack of an output schema makes that less critical.

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 Args section compensates by explaining customer_id as the Google Ads customer ID, campaign_id as the campaign to remove, and confirm_removal as a required safety flag. It does not add format details, but it provides enough semantic meaning to use the tool correctly.

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

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

The description opens with 'Soft-delete (remove) a campaign,' which names a specific verb, resource, and mode. It further clarifies the behavior by stating the campaign will be set to REMOVED status, clearly distinguishing this from update_campaign and set_campaign_status.

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

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

The description clearly labels the operation as destructive and explains the confirm_removal safety gate, providing strong guidance on when the tool should be invoked. It does not explicitly compare against alternatives like set_campaign_status, but the purpose is unambiguous enough that an agent can infer correct usage.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the destructive nature is known. The description adds valuable behavioral context with 'confirm_removal: Must be True to proceed. Safety check,' disclosing a confirmation gate that the agent must pass to actually delete — critical because the schema default is false. It stops short of stating irreversibility or failure behavior, but the annotations carry the safety profile.

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 purpose statement is front-loaded, followed by exactly one line per argument. Roughly six lines total with zero filler; every sentence earns its place, and the safety-check note is the last item, appropriately placed with its parameter.

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 4-parameter destructive operation whose safety profile is already covered by annotations, the description is essentially complete: clear action, all params explained, and the confirmation gate disclosed. The only gaps are return-value expectations and an explicit irreversibility statement, both minor given no output schema exists and the destructive hint is already set.

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 bears the full burden of documenting parameters, and it fully compensates: all four params receive meaningful one-line semantics (customer scope, which ad group contains the keyword, what criterion_id represents, and that confirm_removal is a mandatory safety flag). Without this text, the agent would see bare titles with no way to know the role of each ID or that confirm_removal defaults to false.

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 first sentence, 'Remove a keyword from an ad group,' is a specific verb+resource statement that immediately distinguishes this tool from siblings like list_keywords, add_keywords, and update_keyword_bid, and it is clearly scope-differentiated from remove_campaign. An agent can determine what this tool does without inspecting the schema.

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

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

The description offers no when-to-use guidance versus alternatives, no prerequisites, and no exclusions. The criterion_id arg implies a prior list_keywords lookup, but the description never states that flow or contrasts removal with pausing via set_ad_status.

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

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

Annotations already provide readOnlyHint=false, destructiveHint=true, and idempotentHint=true, so the description does not need to restate those. The description adds the valid statuses and highlights that 'REMOVED' is a possible state, which aligns with the destructive hint. It does not explain what removal means operationally, such as whether it is reversible, but the annotation coverage lowers the burden here.

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

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

The description is compact and well-structured: a single purpose sentence followed by a clean Args list. Every line adds useful information, and there is no redundant prose or repetition of the schema's structural details.

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

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

For a simple three-parameter mutation tool, the description is largely complete: all required parameters are explained, allowed values are enumerated, and annotations cover destructive and idempotent behavior. There is no mention of return values, but the absence of an output schema makes that a minor gap. Nothing needed to actually invoke the tool 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%, so the description must carry the semantic weight, and it does. Each parameter gets a meaningful one-line explanation, and status explicitly lists the three valid values. It could add ID formatting details, but the identifiers are clearly named in a Google Ads context, making this sufficient.

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

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

The description opens with a clear verb and resource: 'Set an ad group's status,' then enumerates the allowed status values. This makes the tool's purpose unambiguous and distinguishes it from siblings like set_campaign_status and set_ad_status by resource. It does not explicitly differentiate it from the more general update_ad_group, but the core purpose is clear.

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

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

The phrase 'Set an ad group's status' implies this is the dedicated tool for status changes, and the parameter descriptions make the intended input clear. However, there is no explicit guidance about when to use this tool instead of update_ad_group or the sibling status-setting tools. With multiple similar sibling tools, explicit routing would improve the definition.

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

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

Annotations already convey that this is a destructive, non-read-only mutation. The description adds useful context by clarifying that 'remove' is implemented as a REMOVED status rather than a separate deletion action. However, it does not explain consequences such as reversibility, effect on delivery, or response behavior.

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

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

The description is compact and front-loaded: the main purpose appears in the first sentence, followed by a clean Args block. Every line contributes necessary information with no filler.

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

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

For a low-complexity status-setting tool, the description gives all required parameter semantics and the allowed operational states. It does not describe return values or side effects, and there is no output schema, but the operation is simple enough that an agent can invoke it correctly with the provided information.

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 for parameter meaning. It explains all four parameters in plain language and explicitly lists the allowed status values ('ENABLED', 'PAUSED', 'REMOVED'), which the schema does not provide.

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

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

The description opens with a specific verb and resource: 'Set an ad's status', and enumerates the three possible states (enable, pause, remove). This clearly distinguishes it from sibling tools that operate on ad groups, campaigns, or other ad fields.

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

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

The description makes it clear this tool is for ad-level status changes, so usage context is implied by the resource and action. However, it does not explicitly state when to prefer this over alternatives like set_ad_group_status or update_ad_group, nor does it mention any exclusions or prerequisites.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety profile is known. The description adds the specific REMOVED status but does not explain whether removal is permanent, what side effects occur, or any permission requirements.

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

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

The description is compact and front-loaded: a one-sentence purpose followed by a terse argument list. There is no filler or repetition of schema data.

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

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

For a simple three-parameter status mutation with annotations covering destructiveness, the description covers purpose and all arguments. It is slightly incomplete only in not clarifying the overlap with remove_campaign or the permanence of REMOVED.

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 descriptions cover 0% of parameters, so the description carries the burden. It assigns a meaning to every parameter and gives the exact allowed values for status, compensating for the schema's bare string properties.

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 first sentence names the verb ('Set'), resource ('campaign'), and scope ('status'), and enumerates the three allowed statuses. This clearly distinguishes it from sibling status setters on ad groups and ads.

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

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

The description gives no guidance on when to choose this over alternatives. Sibling tools include update_campaign, remove_campaign, set_ad_group_status, and set_ad_status, but the description never contrasts them or states exclusions.

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

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

Annotations already signal mutation, idempotency, and non-destructiveness, and the description adds the crucial partial-update behavior: unspecified fields are left untouched. It does not discuss response or error semantics, but this is acceptable given annotation coverage and no output schema.

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

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

The summary line, partial-update note, and Args section are compact and well ordered, with no redundant prose. Every sentence contributes to correct invocation.

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?

All six parameters are documented, and partial-update behavior makes invocation requirements clear. It could be more complete by noting what the API returns and by naming sibling tools for status-only or campaign-level updates, but nothing essential for making the call 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 descriptions are absent (0% coverage), so the Args block carries the full burden. It defines each parameter's domain, units for monetary bids ('in currency'), and explicit allowed status values, adding real meaning beyond property 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?

The description opens with a specific action and resource ('Update an existing ad group') and enumerates the precise mutable fields, making it immediately distinct from create_ad_group, set_ad_group_status, and update_campaign. The 'only provided fields will be updated' line further clarifies the 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?

The use case is implied by the name and summary: modify an existing ad group's optional fields. However, it never explicitly says when to prefer set_ad_group_status for status-only changes or update_campaign for campaign-level edits, leaving routing to the agent's inference.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false, covering the core behavioral safety profile. The description adds that it updates an existing budget, but it does not disclose update semantics such as whether omitted optional fields preserve their current values, what the return value is, or how failures are reported.

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

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

The description is a single clear purpose line followed by a tight argument list. There is no fluff, every parameter gets exactly one explanatory line, and the structure is easy to scan. The form is appropriate for a tool with five parameters.

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 adequately supports a basic invocation by explaining all parameters, but it leaves gaps: it does not state whether updating one field preserves others (partial update semantics), what the tool returns, or what happens if the budget doesn't exist. Since there is no output schema, the description would need to mention the response for full 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 description coverage is 0%, so the description carries the full burden of explaining parameters. It does this well by describing every parameter: customer_id as a Google Ads customer ID, budget_id as the budget to update, amount as a daily budget amount 'in currency', and delivery_method with its allowed values 'STANDARD' or 'ACCELERATED'. It could be more precise about units (e.g., micros vs major units) and the effect of omitting optional fields, but the parameter documentation is substantially better than the empty schema.

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

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

The description uses a specific verb 'Update' and a specific resource 'existing campaign budget', which clearly distinguishes it from siblings like create_budget, list_budgets, and get_budget_utilization. The word 'existing' further clarifies that this tool operates on an already-created budget rather than creating a new one.

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 clearly establishes the context: use this tool when you need to modify an existing campaign budget. This is enough to route an agent away from create_budget and list_budgets, but it does not explicitly name alternatives or state when not to use the tool, so it falls just short of full 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?

Annotations already mark this as non-read-only, non-destructive, and idempotent. The description adds meaningful behavior beyond the annotations: only provided fields are updated, status is constrained to ENABLED/PAUSED, target_cpa and target_roas are tied to specific bidding strategies, and dates follow YYYY-MM-DD. No contradiction with annotations.

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

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

The description is compact and well-organized: a one-line purpose, one clarifying partial-update rule, then a tidy Args list. Every sentence earns its place, and the most important behavioral note 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?

With 8 parameters and no schema descriptions, the description covers every parameter, the partial-update behavior, status constraints, bidding-strategy associations, and date formatting. No output schema exists, so return-value detail is not required. The only minor absence is explicit comparison to set_campaign_status, but this is not enough to penalize given the overall 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 description coverage is 0%, so the description carries the full parameter burden. The Args list documents all 8 parameters with useful details beyond the schema: status values, target strategy context, and date format. This fully compensates for the schema gap.

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

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

The description opens with 'Update an existing campaign's properties,' naming the specific verb, resource, and scope. The next sentence clarifies partial-update semantics, which distinguishes it from create/remove campaign and from set_campaign_status.

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

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

The phrase 'existing campaign' clearly implies this is for modifying an already-created campaign rather than creating or removing one. However, it does not explicitly mention sibling alternatives like set_campaign_status for status-only changes, so it stops short of full exclusion 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?

Annotations already indicate this is non-read-only, non-destructive, and idempotent, so the description does not need to restate those facts. The phrase "New max CPC bid" adds some behavioral clarity by showing the update is a direct set operation. It does not disclose additional details such as validation, confirmation behavior, or downstream effects, but it does not contradict the annotations.

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

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

The description is short, front-loaded with the purpose, and follows with a compact, well-organized argument list. Every line adds value: it defines parameters, clarifies the update target, and provides an example. There is no redundancy or filler.

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

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

For a tool with four required parameters and no output schema, the description provides essential call information: the action, the target entity, and all parameter meanings. It does not describe return values or potential errors, but those are not required by the rubric when output schema is absent. Minor gaps remain around validation and side-effect expectations, but the definition is sufficient for an agent to invoke it confidently.

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 carries the full burden of explaining parameters. It provides meaningful definitions for all four parameters, including the relationship of ad_group_id and criterion_id to the keyword, and gives a clear currency example for cpc_bid. 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 states a specific action and target: "Update the CPC bid for a keyword." This clearly identifies the tool's resource and verb, and it is distinct from sibling tools such as update_ad_group or update_budget. The resource is unambiguous enough for an agent to select it correctly.

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

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

The intended use is implied by the purpose statement: use this when changing a keyword's max CPC bid. However, there is no explicit guidance about when not to use it or how it compares to related tools like update_ad_group or remove_keyword. The usage context is understandable but not fully articulated.

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