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

With no annotations provided, the description carries the full behavioral disclosure burden. It adds valuable behavior context: the operation is atomic, it is a dry run unless confirm=true, and it targets an existing campaign. It does not mention return values, error cases, or rate limits, but the presence of an output schema lessens that need.

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

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

The description is three tight sentences with no filler. It front-loads the primary action, packs the key input components into one clause, and adds two critical clarifications: the shape reference and the dry-run behavior. Every sentence earns its place.

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

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

Given a 13-parameter tool with 0% schema coverage, the description is reasonably complete: it states the atomic create behavior, the dry-run safeguard, the existing-campaign constraint, and the relationship to create_search_campaign. It could be more explicit about what the dry-run response contains or what happens after confirm=true, but the output schema likely covers return details.

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

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

Schema description coverage is 0%, so the description must compensate for parameter meaning. It identifies categories such as keywords, optional ad-group negatives, optional final URL suffix, and one responsive search ad, and points to create_search_campaign for exact argument shapes. However, individual parameters like status, path1, path2, and confirm are only partially explained, and several fields rely on self-explanatory names rather than explicit semantics.

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

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

The description opens with a specific verb and resource: 'Add one ad group' with its keywords, optional negatives, optional final URL suffix, and one responsive search ad. It explicitly targets an EXISTING campaign, which distinguishes this tool from create_search_campaign and other sibling tools. The action and 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?

The description clearly limits usage to existing campaigns ('to an EXISTING campaign') and references create_search_campaign's ad_groups shape, implicitly routing the agent to that sibling for whole-campaign creation. It also gives an important execution guideline: 'Dry run unless confirm=true.' However, it does not explicitly state when to prefer this tool over add_keywords or create_responsive_search_ad for partial updates.

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 provided, the description carries the full burden and does so admirably. It discloses that business_name becomes a TEXT asset, logo_path uploads a new asset while logo_asset_resource_name re-links an existing one, at least one input is required, and the operation is a dry run unless confirm=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 description is compact yet information-dense, with the purpose front-loaded. Every sentence contributes distinct value: purpose, business name behavior, logo options and constraints, input requirement, and dry-run semantics. There is no filler or redundancy.

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

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

For a tool with 6 parameters and no annotations, the description provides all essential behavioral details needed to call it correctly: options, constraints, required input condition, and confirmation behavior. An output schema exists, so return values do not need to be explained in the description.

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

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

Schema description coverage is 0%, so the description must add meaning beyond parameter names. It thoroughly explains business_name, logo_path, logo_asset_resource_name, and confirm, including constraints and interplay. customer_id and campaign_id are not elaborated, but their roles are reasonably self-evident from their names and 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: 'Attach a business name and/or business logo to a Search campaign.' It clearly distinguishes this from siblings like add_keywords or add_image_assets by focusing on the two business asset types and their Google Ads linkage roles.

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

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

The description provides clear context: this tool is for adding business name and/or logo specifically to a Search campaign. It does not explicitly name alternative tools or state when-not-to-use, but the scope is concrete enough for an agent to select it appropriately among the sibling tools.

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

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

With no annotations, the description carries the full behavioral burden. It excellently discloses the safety-critical dry-run behavior ('Dry run unless confirm=true') and the character limit. It does not describe edge cases or side effects beyond creation, but the core mutation behavior is clear.

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

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

Two short sentences with no filler. The core action is front-loaded, the key constraint is embedded parenthetically, and the safety-critical dry-run caveat is stated directly. Excellent conciseness.

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 an output schema and a relatively simple parameter set, the description covers the essential behavior: what it creates, the constraint, the target, and the confirmation gate. It is slightly incomplete because customer_id's role is not explained and sibling-tool routing is absent, but it remains sufficient for correct invocation in most cases.

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 clarifies 'callouts' (<=25 chars) and 'confirm' (controls dry-run vs actual creation), but it does not explain 'customer_id' or add meaningful detail about 'campaign_id' beyond the obvious campaign attachment 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 clearly states a specific action and resource: create callout assets and attach them to a campaign. It also adds the constraint of <=25 chars per callout, which helps distinguish it from generic asset creation. Although sibling tools are not explicitly named, the resource type 'callouts' 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 implies the tool is used when callout assets need to be created and attached to a campaign, giving clear context. However, it does not mention when to avoid this tool or choose an alternative sibling like add_sitelinks or add_structured_snippet.

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

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

With no annotations, the description carries the behavioral burden and handles it well. It discloses the dry-run behavior unless confirm=true, local validation based on field_type, size and aspect-ratio constraints, and Google's DUPLICATE_ASSET rejection 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 long but information-dense, with every sentence earning its place. It front-loads the core purpose, then provides precise format examples, validation requirements, duplicate handling, and the confirmation flag without 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 no annotations and no schema-level descriptions, this definition is complete: it covers input shapes, accepted file types and dimensions, field_type semantics, duplicate-asset handling, and dry-run behavior. An output schema exists, so return-value details are not required from the description.

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

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

Schema coverage is 0%, and the description substantially compensates by documenting the exact images array structure, valid field_type values, optional name, and the asset_resource_name alternative. It also explains confirm as dry-run unless true; customer_id and campaign_id are left to their self-explanatory names and the surrounding campaign 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 opening sentence states a specific verb and resource: 'Upload image files as image assets and attach them to a Search campaign as AD_IMAGE.' It also distinguishes Search's AD_IMAGE link type from Performance Max and Display field types, which helps separate this tool from sibling asset 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 clearly establishes the Search-campaign context and explains when to use an existing asset_resource_name versus uploading a file, including the duplicate-asset case. It does not explicitly name sibling tools as alternatives, but it gives enough contextual guidance to route 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?

With no annotations provided, the description carries the full burden of behavioral disclosure, and it delivers the key safety trait: 'Dry run unless confirm=true.' This makes the default non-destructive behavior explicit, which is critical for a mutation tool. Less-critical details like permission requirements or duplicate handling are omitted, but the most important behavior is disclosed.

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

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

Three short sentences, each earning its place: purpose first, then the keyword payload format, then the safety warning. There is zero filler, and the most important information is front-loaded.

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

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

For a mutation tool with no annotations and 0% schema coverage, the description covers the essential ground: what it does, the keyword payload format, and the dry-run safety valve. Return values are handled by the output schema, and the remaining parameters are self-evident from their names, leaving only minor gaps such as batch limits or deduplication behavior.

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

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

Schema description coverage is 0%, and the description compensates for the most complex parameter by showing the keyword payload shape, including the required text field and the match_type enum values ('PHRASE|EXACT|BROAD'). It also clarifies the effect of confirm, though customer_id, ad_group_id, and status are left to inference from their 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+resource: 'Add positive keywords to an ad group.' The word 'positive' clearly distinguishes this tool from its sibling add_negative_keywords, so an agent can tell them apart without inspecting 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?

Usage context is implied by the phrasing 'positive keywords' — an agent can infer when to choose this over add_negative_keywords — but there is no explicit statement of when to use it versus alternatives, nor any exclusions or prerequisites. The guidance is present only by implication, not 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?

With no annotations, the description carries the behavioral burden and does disclose the most important trait: 'Dry run unless confirm=true.' It also reveals the default match type. It does not cover permissions, idempotency, or error conditions, but it gives the safety-critical behavior upfront.

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

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

Two compact sentences with no filler. The purpose and placement are first, then match type, then the critical dry-run behavior; every clause earns its place.

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

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

The description is mostly complete for a moderately complex tool: it identifies placement, match type, and default dry-run mode. The main gap is that it never explicitly states that one of campaign_id/ad_group_id should be supplied or what happens if both/neither are set, though 'or' implies the intended exclusivity.

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

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

Schema coverage is 0%, but the description compensates by explaining match_type values/default, tying campaign_id and ad_group_id to placement levels, and defining confirm's dry-run semantics. customer_id and the exact format/syntax of keywords are not described, but the main disambiguating parameter details are present.

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 NEGATIVE keywords') on a defined resource with placement levels (campaign_id / ad_group_id). The capitalized 'NEGATIVE' distinguishes it from the sibling add_keywords tool.

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

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

It clearly scopes when to use this tool: adding negative keywords at campaign or ad-group level, with match-type control and dry-run by default. It does not explicitly call out alternatives or exclusions, but the negative-keyword framing and sibling list make the choice clear.

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

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

With no annotations, the description carries the full burden and does it well: it discloses the safety-critical dry-run behavior ('Dry run unless confirm=true'), the ad-group override behavior, and Google's constraint about serving sitelinks with duplicate URLs. It could add more detail about what the dry run returns or auth requirements, but the most important behavioral traits are surfaced.

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 purpose, then adds the parameter example, constraints, and safety behavior. Every sentence contributes meaningful information, though the dry-run and uniqueness rules could arguably be placed earlier for maximum emphasis.

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 sufficiently covers the main operations, parameter semantics, important constraints, and the confirm/dry-run safety mechanism. An output schema is present, so return-value documentation is not expected here. Minor gaps such as error conditions and broader account-level requirements prevent a perfect score.

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 explains the sitelinks array item structure with field-level limits (link_text <=25, final_url, description1/2 <=35), clarifies confirm semantics and the optional ad_group_id behavior. customer_id and campaign_id are not elaborated, but their names and required status make them self-explanatory.

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

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

The description begins with a specific verb and resource: 'Create sitelink assets and attach them to a campaign, or to one ad group.' It clearly distinguishes the two target attachment modes and the ad-group override behavior, making the tool's function unambiguous and distinguishable from sibling asset tools like add_callouts or add_image_assets.

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

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

The description gives clear contextual usage for campaign-level versus ad-group-level attachment ('when ad_group_id is given') and explains the dry-run/confirm workflow. However, it does not explicitly state when to prefer this tool over sibling tools or when not to use it, so the guidance is implied rather than explicit.

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 provided, the description carries the burden of behavioral disclosure. It prominently reveals the dry-run behavior ('Dry run unless confirm=true') and includes validation constraints (3-10 values, each <=25 chars). This goes well beyond the schema, though it does not cover permissions or post-creation effects.

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

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

A single sentence conveys the core action, validation rules, examples, and the confirmation behavior. Every element earns its place and the critical dry-run note comes at the end, keeping the main purpose front-loaded.

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

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

For a parameter-rich creation tool with no annotations, the description covers the essential operational details: what is created, where it is attached, validation limits, and the confirmation requirement. It does not discuss alternative tools or error scenarios, but an output schema exists and the description is otherwise sufficient for correct invocation.

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

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

Schema description coverage is 0%, so the description must add meaning. It explains header with examples, constrains values by count and length, clarifies confirm as a dry-run gate, and indicates campaign_id via 'attach it to a campaign.' customer_id is left to inference, but overall it compensates well for the schema's lack of documentation.

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: 'Create one structured-snippet asset' and says it 'attach[es] it to a campaign.' This clearly distinguishes it from sibling tools like add_sitelinks and add_callouts, even without naming them.

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

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

Usage context is implied by the resource type: use this when you need a structured-snippet asset. However, it does not explicitly state when to prefer this over a sibling asset tool or mention any exclusions, so the guidance is only implicit.

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 provided, the description carries the full burden. It clearly implies a read-only operation ('Return') and identifies exactly what data is exposed (local audit log, dry runs, applied changes). It does not explicitly state that it makes no modifications, but the wording leaves little ambiguity for this kind of 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?

A single, front-loaded sentence carries all necessary information with no filler. It states the action, the object, the count parameter, and the log scope efficiently.

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 one-parameter tail operation, the description is complete: it states what is returned, from where, and in what quantity. An output schema exists to cover return-value structure, and the sibling tools are unrelated, so no additional routing context is needed.

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

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

The schema has 0% description coverage, so the description must compensate. It does so by defining 'n' as the number of entries returned ('last n entries'), giving the single parameter meaningful semantics despite the schema providing only a name and default.

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 ('Return') and resource ('last n entries of this server's local audit log'), and clarifies content scope with '(dry runs and applied changes)'. It is clearly distinguishable from all sibling tools, which concern campaign and ad management rather than server diagnostics.

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: it is for retrieving recent audit log entries, and it names the log scope. There are no similar sibling tools to contrast with, so explicit alternatives are unnecessary; however, it does not state situational when-to-use guidance or exclusions.

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

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

With no annotations provided, the description carries the full behavioral disclosure burden. It discloses the dry-run behavior ('Dry run unless confirm=true'), the mutation semantics, and that existing ads are unaffected. It does not cover authorization needs or post-confirm effects, but the core safety-relevant behavior is 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 description is compact and well-structured: a one-sentence purpose, then brief parameter constraints. Each line adds necessary information, with no filler or repetition of 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?

Given the output schema exists, return values need not be explained. The description covers the complex nested item formats, limits, status, and dry-run behavior. Minor gaps remain around path1/path2 semantics and explicit guidance on when to choose the update sibling, but the core invocation context is sufficiently 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 must compensate. It adds meaningful detail for headlines and descriptions: item counts, character limits, allowed string/object shapes, and pin values. It also clarifies status and confirm semantics. However, path1, path2, final_url, and ID fields are left to their names and schema 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 states a specific verb and resource: create a NEW responsive search ad in an ad group. It explicitly notes existing ads are untouched, which differentiates it from update_responsive_search_ad without needing to inspect sibling 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 clearly communicates this tool is for creating new ads, not modifying existing ones ('existing ads are untouched'). It does not explicitly name update_responsive_search_ad as the alternative for updates, but the creation-focused wording makes the intended use clear.

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 provided, the description carries the full burden and delivers: the operation is atomic, the campaign is created PAUSED, a managed label is attached for later removal, location targeting is presence-only, an empty language list means 'all languages', and critically 'Dry run unless confirm=true' discloses the safety default. Network scope ('Google Search only (no partners, no Display)') and bidding behavior are also disclosed.

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 long but earned: 0% schema coverage and 11 parameters require this density. It is front-loaded with a one-sentence summary of scope and atomicity, then organized topically (label/paused state, locations, languages, bidding, network, structures, follow-ups, dry-run). Every sentence adds value, and the ad_groups/negative_keywords format specifications are presented compactly as inline JSON shapes.

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

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

Given the tool's complexity - 11 parameters, 6 required, zero schema descriptions, and no annotations - this description is essentially complete. All parameter semantics, side effects (label, paused state), safety control (dry run), and follow-up tool routing are covered. An output schema exists, so the description's decision not to explain return values is appropriate per the rubric.

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 - and it does. It documents locations with concrete constant IDs (2840 = US), languages with IDs and empty-list semantics, bidding strategy combinations for target_cpa and cpc_bid_ceiling including currency and cap behavior, the complete ad_groups object structure, campaign-level negative_keywords structure, and the headline/description pin format. Nearly every schema parameter gains meaning beyond its bare name and type.

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 and resource: 'Create a complete Search campaign in ONE atomic mutate' and enumerates exactly what is included (budget, campaign, location/language criteria, negatives, ad groups, keywords, one RSA). It clearly distinguishes itself from piecemeal siblings like add_ad_group, add_keywords, and create_responsive_search_ad by positioning itself as the all-in-one atomic creation tool.

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

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

The description explicitly routes follow-up work: device bid adjustments go to set_device_bid_modifiers ('the device criteria only exist once the campaign does'), extensions are 'separate tools - call them with the returned campaign id', and activation goes to set_status ('It is created PAUSED; enable it with set_status'). It also ties the managed label to remove_entity, giving the agent clear when-to-use-this-vs-sibling 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?

With no annotations, the description carries the full behavioral burden. It discloses that the tool creates nothing, has no confirm flag, costs one API operation, is rate-limited, sorts results by avg_monthly_searches descending, rounds volumes, and aggregates close variants. This is rich, useful 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 front-loaded with the most important facts: purpose, read-only nature, and cost. Parameter details are grouped logically, and return-behavior notes come last. Every sentence earns its place and the line breaks improve scannability.

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

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

An output schema exists, so re-explaining return fields would be redundant. The description covers side effects, rate limiting, ordering, aggregation behavior, defaults, and network scope, which is complete for a 7-parameter tool with no annotations.

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

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

Despite 0% schema description coverage, the description explains seeds/url constraints, the 20-keyword cap, geo and language defaults, and the meaning of limit. It omits include_zero_volume behavior and does not define customer_id, but those are largely inferable from their titles and defaults, so this is a strong partial compensation.

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 clearly that it returns Keyword Planner ideas with monthly search volume and bid ranges, a specific read-only resource. The READ-ONLY framing actively distinguishes it from the mutating sibling tools like add_keywords and add_callouts.

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

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

Gives clear operational context: seeds and url can be used either or both, Google Search network only, no partners, one API operation per call, and a rate limit. It does not explicitly name an alternative tool, but the read-only scope and defaults make the intended use 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?

With no annotations provided, the description carries the full burden and does exceptionally well: it discloses permanence ('no restore'), the atomic-mutate behavior for lists, the managed-label guardrail, the dry-run default, and the subtle distinction between removing an asset link versus the asset itself. An agent can predict exactly what side effects will occur.

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?

Every sentence delivers critical operational information: scope, resource_name semantics, label requirement, permanence, and dry-run behavior. The most important warning ('PERMANENTLY remove') is front-loaded, and the length is justified for a destructive, irreversible operation.

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

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

The description covers all essential aspects: allowable entity types, resource name formats, batch behavior, mutation atomicity, the managed-label prerequisite, irreversibility, and confirmation/dry-run semantics. Because an output schema exists, not describing return values is acceptable. Nothing an agent needs to invoke this tool safely 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 compensate. It meaningfully explains that resource_name accepts one name or a list of names of the SAME kind, and that confirm gates the dry-run. It does not explain customer_id, but its purpose is self-evident from the name and Google Ads context. This is strong compensation 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 opens with 'PERMANENTLY remove' and explicitly enumerates the exact entity types (campaign, ad group, ad, keyword, campaign criterion, asset LINK). It clearly distinguishes the destructive remove operation from the mutation and creation siblings, and clarifies that asset links are removed while the asset itself remains in the library.

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

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

The description provides strong usage context: removal is atomic for a list of the same kind, requires the managed label, and is irreversible. It also states the dry-run behavior unless confirm=true. It does not name an alternative for non-destructive changes, but given the sibling set contains no other remove tool, the intended use is clear enough.

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

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

With no annotations provided, the description carries the behavioral burden. It discloses that the operation is a dry run unless confirm=true, which is a critical safety behavior, and explains the effect of passing 0. It could add permission requirements or reversibility notes, but the dry-run and removal semantics are well covered.

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

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

Three concise sentences deliver the core action, parameter nuance, and confirmation requirement with no filler. The most important behavioral note (dry run unless confirm=true) is placed at the end but is clearly readable and well separated.

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

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

The description covers the essential context: target campaign type, parameter semantics, and mutation safety via dry-run. An output schema exists, so return-value details are not required here. Minor gaps like expected value range or whether the ceiling persists across updates do not prevent correct invocation.

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

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

Schema description coverage is 0%, so the description must explain parameters. It meaningfully defines cpc_bid_ceiling with currency and zero-removal semantics, and confirm is explained by the dry-run sentence. customer_id and campaign_id are left implicit, but their purpose is self-evident from their 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 identifies the action (setting a max CPC bid ceiling), the resource (a campaign using Maximize Clicks / Campaign.target_spend), and the currency context with an example. This distinguishes it from sibling tools like set_campaign_target_cpa and set_campaign_daily_budget.

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

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

The description states the specific campaign type this applies to (Maximize Clicks), which is a clear usage condition. It also explains the special case of passing 0 to remove the ceiling. It does not explicitly name alternatives or state when not to use it, but the target_spend constraint is strong 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?

No annotations are provided, so the description carries the behavioral disclosure burden. It reveals two important non-obvious behaviors: the tool refuses when the budget is shared, and it runs as a dry run unless confirm=true. It does not detail error responses or permission requirements, but the core safety semantics are disclosed.

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

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

Two compact sentences with no filler. The primary action is stated first, followed by the two most decision-relevant caveats: shared-budget refusal and the confirm-required dry-run flow.

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

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

Given the presence of an output schema and no annotations, the description covers the essential behavioral context: operation, currency, refusal condition, and confirmation requirement. Minor gaps remain around explicit sibling differentiation and ID parameter meaning, but the tool is callable 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 description coverage is 0%, so the description must compensate. It clarifies daily_budget is in account currency and confirm controls dry-run vs. execution. However, customer_id and campaign_id are left unexplained beyond their names, which are self-evident but still undocumented.

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

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

The description uses a specific verb and resource: 'Set a campaign's daily budget', and adds 'account currency' for precision. This clearly distinguishes it from sibling tools like set_campaign_target_cpa and set_campaign_cpc_ceiling, which deal with bids rather than budgets.

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 operational context: this tool sets a daily budget, requires confirmation for execution, and refuses shared-budget scenarios. It does not explicitly name sibling alternatives or state when not to use it, but the scope is unambiguous enough for correct 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?

With no annotations, the description carries the full burden. It discloses the dry-run behavior ('Dry run unless confirm=true'), the side-effect scope ('Ads, their text and history are untouched'), and the precedence behavior with ad-group/ad suffixes. This goes well beyond what the schema alone would tell an agent.

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?

Every sentence adds distinct value: the action, the URL-appending behavior, the override precedence, the no-side-effects guarantee, and the dry-run condition. The description is front-loaded with the primary action and remains compact despite covering multiple behavioral aspects.

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 a single-purpose mutation with a simple schema. The description covers what the tool does, when to use it, parameter behavior, side effects, and the confirmation gate. An output schema exists, so return-value documentation is not required. No critical information for correctly invoking this 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 compensate. It explains the final_url_suffix value format with ValueTrack tokens and the empty-string clearing behavior, and it clarifies the confirm parameter's dry-run effect. Customer_id and campaign_id are not elaborated, but their purpose is unambiguous from the tool name and 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 action and resource: 'Set the CAMPAIGN-level final URL suffix, or clear it with ""'. It explicitly scopes the tool to campaign level, which distinguishes it from sibling set_final_urls and other campaign-level setters. The ValueTrack token example further clarifies what the suffix is for.

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 explaining when the suffix applies ('at click time'), how it interacts with ad-group/ad suffixes ('An ad-group or ad suffix overrides the campaign's'), and advises keeping the suffix at one level. However, it does not explicitly name alternative tools or state when-not-to-use, so it stops short of a full 5.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals a critical safety behavior: 'Dry run unless confirm=true.' This tells the agent that the operation is non-destructive by default and requires explicit confirmation to actually apply changes. It does not describe permissions or reversibility, but the dry-run warning is substantial.

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

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

Two tight sentences with no filler. The primary action is front-loaded, and the critical dry-run behavior is stated immediately after. Every sentence adds functional value.

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

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

The description covers the essential context: what is set, the unit, the required bidding strategy, and the safety default. An output schema exists, so return-value documentation is not the description's responsibility. It could mention that this modifies an existing campaign rather than creating one, but the tool name and parameters make that clear.

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 needs to compensate. It explains target_cpa's unit and format ('in account currency, e.g. 9.5') and clarifies the confirm parameter's effect via the dry-run statement. customer_id and campaign_id are not explicitly described, but their purpose is self-evident from the parameter names and the tool name.

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 ('Set the target CPA') on a specific resource ('a campaign'), with the exact unit (account currency) and an example value. It also scopes the tool to campaigns using Maximize Conversions, distinguishing it from sibling tools like set_campaign_cpc_ceiling.

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

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

The description explicitly identifies the applicable context: campaigns that use Maximize Conversions. It does not explicitly list when not to use it or point to alternatives, but the context is clear enough for an agent to select it appropriately among the 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?

With no annotations, the description carries the full behavioral burden, and it delivers: it discloses the allowed range, the exclusion semantics, Smart Bidding's limited honoring of values, the 'None keeps unchanged' behavior, and the dry-run default unless confirm=true. This is rich, non-obvious behavior that an agent needs before invoking the tool.

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

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

The description is compact, well-structured, and front-loaded with the core operation. Every sentence adds distinct value: range semantics, exclusion behavior, Smart Bidding nuance, None handling, and confirmation/dry-run behavior. There is no filler.

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

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

For a 6-parameter mutation tool with no annotations, the description covers the essential operational details: what can be set, valid values, how to leave fields unchanged, and how to actually execute instead of dry-run. The output schema exists, so return-value details are not required. No critical gap remains.

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 explains the meaning of device values (percent range, -100 exclusion), the None behavior, and the confirm flag's dry-run semantics. customer_id and campaign_id are not explicitly explained, but their names and required status make their roles self-evident.

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 campaign-level device bid adjustments in percent (-100 to +900).' It also clarifies the exclusions semantics and distinguishes device adjustments from the sibling location-based tool through the word 'device.' The purpose is unambiguous and immediately actionable.

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 for when the tool is appropriate: adjusting device bids, using -100 for exclusions, and understanding behavior under Smart Bidding. It does not explicitly name alternative tools or say 'use this instead of X,' but the context is clear enough for correct tool selection.

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

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

With no annotations, the description carries the full burden, and it delivers: it discloses atomicity, that ads keep text and history, that changes happen in place, and that the operation is a dry run unless confirm=true. This is exactly the safety-critical behavioral context an agent needs.

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

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

The description is compact yet information-dense, with the main purpose front-loaded, followed by a structured target example, a behavioral note, and the dry-run warning. Every sentence adds necessary value without repetition 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 mutation tool with three parameters and an output schema, the description covers the essential invocation details: target types, field applicability, atomicity, in-place preservation, typical use, and confirmation behavior. Nothing critical is missing for an agent 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?

Schema coverage is 0%, but the description thoroughly compensates by documenting the targets array structure, allowed resource_name values, which fields apply to which entity types, and how to clear final_url_suffix. It also explains the confirm parameter's dry-run behavior; customer_id is self-explanatory from the schema.

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

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

The description uses a specific verb ('Update') and resource ('final URLs and/or final URL suffixes') and clarifies the atomic, multi-entity scope by naming ads, ad groups, and assets. This clearly distinguishes it from sibling tools like set_campaign_final_url_suffix, which is narrower in 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 description gives explicit typical use cases: moving UTMs from an ad-group suffix into the final URL, or retagging a campaign. It does not explicitly state when not to use this tool versus alternatives, but the target scope and examples make the intended context clear.

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 provided, the description carries the full transparency burden and does so thoroughly. It discloses the allowed percent range, zero-removes semantics, bidding-strategy limitations, rejection of untargeted geos, atomic mutation, and the dry-run-before-confirm 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 dense but fully front-loaded: core action and constraints come first, followed by parameter format, behavioral caveats, and confirmation semantics. Every sentence adds necessary operational detail 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 complex mutation tool with no annotations, the description covers all critical decision factors: range, target constraints, bidding-strategy compatibility, atomicity, and dry-run behavior. An output schema exists, so return-value details are not required here.

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 parameters, and it does. It details the modifiers map format with concrete examples, accepts both raw IDs and geoTargetConstants/ prefixed IDs, explains that 0 removes an adjustment, and clarifies confirm's dry-run default.

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 campaign-level LOCATION bid adjustments'. It clearly distinguishes this from sibling tools like set_device_bid_modifiers by explicitly naming the campaign-level location 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?

It specifies when the tool is effective by stating location adjustments are honored by Manual CPC and Maximize clicks but ignored by Smart Bidding, giving clear guidance on when not to use it. It also clarifies that targeting is never changed and only already-targeted locations are accepted.

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

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

With no annotations, the description carries the full behavioral disclosure burden. It discloses a dry-run default unless confirm=true, which is critical safety-relevant behavior, and states that REMOVED is not supported. This gives the agent actionable knowledge about side effects and limitations.

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

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

Three compact sentences with no filler. The core action is front-loaded, and each sentence adds meaningful guidance: allowed values/resource types, resource_name requirement, and safety/constraint behavior.

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

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

For a mutation tool with no annotations and sparse schema, the description covers the most important operational details: valid statuses, supported resource types, resource_name format, dry-run behavior, and the unsupported REMOVED state. It does not describe customer_id, but that parameter is self-explanatory. The output schema exists, so return values need not be described.

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 explains resource_name format with an example, enumerates valid status values, and explains the confirm parameter's dry-run semantics. customer_id is not elaborated, but it is self-evident from the name and example.

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

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

States a specific verb ('Set'), exact allowed values ('ENABLED or PAUSED'), and a clear list of target resources (campaign, ad group, ad, keyword). It also distinguishes itself from other mutation tools by focusing on status transitions and explicitly excluding REMOVED.

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?

Explains the prerequisite that resource_name must be the full resource name from the read MCP, gives an example, and clarifies that REMOVED is intentionally not supported, implying the alternative is remove_entity. It does not explicitly name sibling alternatives, but the guidance is clear enough for selection.

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

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

With no annotations provided, the description carries the full behavioral burden and does so thoroughly. It discloses that the ad goes back through policy review, that asset performance labels and Ad Strength reset, that lists are replaced wholesale, that empty strings clear path fields, and that the operation is a dry run unless confirm=true. These are meaningful side effects beyond what the schema alone could communicate.

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 dense but every clause carries operational value. It front-loads the core purpose before diving into parameter-level rules. The single-paragraph format with long parentheticals is not as scannable as bulleted rules, but there is no filler, redundancy, or irrelevant 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 an 8-parameter mutation tool with no annotations, the description is unusually complete. It covers the in-place update behavior, resulting side effects, list constraints, item shapes, resource-name format, clearing behavior, and the dry-run confirmation gate. Since an output schema exists, not describing return values in prose is acceptable, and nothing essential is left to dangerous inference.

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

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

Schema description coverage is 0%, so the description must compensate. It adds valuable semantics for ad_id, headlines, descriptions, path1, path2, and confirm. final_url and customer_id are not elaborated in the description, but 'Every argument left None is unchanged' provides a useful default semantic for all optional parameters, and final_url/customer_id are reasonably self-explanatory from their 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 states a specific action ('Edit an EXISTING responsive search ad in place') on a concrete resource and distinguishes itself from create functionality by emphasizing that the ad keeps its id and reporting history. This is far from a tautology and makes the tool's scope 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 phrase 'EXISTING' plus the detail that the ad keeps its id and reporting history clearly implies this tool is for modifying an already-created ad rather than creating a new one. The dry-run/confirm behavior also tells the agent when a real change will be committed. It does not explicitly name create_responsive_search_ad as the alternative, but the context is clear enough.

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