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

Annotations already declare readOnlyHint=true, and the description adds meaningful behavioral context: it is scoped specifically to responsive search ads, returns Google's own performance_label, and exposes per-headline/per-description data rather than a single aggregate. It also explains the relationship between ad_strength and this underlying signal. This goes beyond what annotations alone convey.

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

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

The description is concise and front-loaded with the core purpose, followed by a clear explanation of why it matters relative to the aggregate ad_strength label. Both sentences earn their place, though the phrase 'Google's own' is slightly redundant and could be trimmed. Overall structure is strong and easy to parse.

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 explains the tool's conceptual purpose well and there is an output schema to clarify return structure. However, it gives no operational context for parameters such as campaign_id or date ranges, and does not mention the filtering behavior implied by the optional inputs. For a read-only reporting tool with defaults, this is adequate but 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?

Schema description coverage is 0%, and the description provides no guidance on any of the six parameters: customer_id, campaign_id, date fields, limit, or date_range. The agent must rely solely on parameter names and defaults, which is insufficient for correctly constructing calls. The description does not compensate for the total absence 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 exactly what the tool returns: per-asset performance for responsive search ads, broken out by individual headline and description with Google's performance_label values. It clearly distinguishes itself from the sibling-level ad_strength metric and explains why this tool is more useful than the aggregate label. The resource and granularity 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 explicitly frames when this tool is useful: when you need to know which specific line is dragging the ad down before replacing it with add_rsa, instead of guessing from the aggregate ad_strength label. It does not explicitly name sibling alternatives or state when not to use it, but the contextual contrast with ad_strength provides clear practical guidance.

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

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

The description adds meaningful behavior beyond the annotations: it is selective/autonomous, only adds approved terms, and reports rather than adds non-clearing terms. It does not contradict readOnlyHint=false or destructiveHint=false, though it could say more about dry_run 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?

Two short sentences front-load the purpose and then add the key autonomy condition. Every sentence earns its place and no filler is present.

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

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

The description is adequate for the core use case and the output schema covers return values, but it leaves gaps around dry_run, match_type semantics, and how 'reported' terms are returned. These gaps matter because the schema carries no field descriptions.

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, but it does not explain most parameters (dry_run, run_id, rationale, match_type). It only implies that terms are negative keywords and campaign_id is the campaign target, which is insufficient for a 7-parameter tool.

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

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

The first phrase 'Add campaign-level negative keywords' names a specific verb and resource and immediately distinguishes it from the sibling add_shared_negative_keywords. The rest of the description adds the policy-threshold condition without blurring the core 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?

It communicates when autonomous operation is appropriate: terms whose own search-term data clears the policy threshold with no conversions. It does not explicitly name alternatives or exclusion cases, so it stops short of a 5, but the context is clear and actionable.

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

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

The description discloses critical behavior beyond the annotations: the ad is created ENABLED, starts serving immediately, has no paused-on-create option, and targets a presumably live ad group. This is highly valuable risk information. It does not contradict the annotations, which correctly mark the operation as non-read-only.

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

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

The description is three focused sentences: what it does, the prerequisite, and the critical behavioral warning. Each sentence carries necessary information with no filler. The most important distinction from sibling tools is front-loaded.

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

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

Given the tool's side-effect profile, the description covers all essential context: prerequisite, live-serving behavior, user confirmation requirement, and the target ad group. The output schema and nested spec descriptions cover the remaining 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?

The schema has 0% description coverage at the top level, but the description compensates by clarifying that spec and confirm_token must come from a successful preview_rsa. This gives the confirm_token purpose and constrains the spec parameter. The nested schema already documents fields like final_url and ad_group_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 uses a specific verb and resource: 'Create the previewed responsive search ad for real, in the existing ad group.' It clearly distinguishes this from the sibling preview_rsa by emphasizing the actual creation step versus previewing.

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

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

The description explicitly states when to use this tool: only after a successful preview_rsa, with the exact spec and confirm_token. It also instructs to confirm with the user before calling. It does not explicitly name alternatives, but the prerequisite effectively disambiguates it from preview_rsa.

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 establish readOnly=false, openWorld=true, destructive=false; the description builds on them by specifying the autonomy trigger — 'measured search-term evidence... clears the policy threshold with no conversions' — the cross-campaign aggregation scope, and the hard prerequisite that the list 'must already exist and be attached to at least one campaign.' It does not address partial-failure behavior or the dry_run escape hatch, so it stops short of a 5.

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

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

Purpose is front-loaded in sentence one, behavior in sentence two, prerequisites/workflow in sentence three — a logical order where each sentence earns its place. The middle sentence is dense but carries unique information (autonomy rule, aggregation, sibling comparison); it could be tightened but is not padded.

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

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

Covers purpose, scope, autonomy criteria, prerequisite, creation workflow via mutate, and sibling routing; output schema exists so return values are covered. The notable gaps are match_type semantics and the dry_run parameter at 0% schema coverage — for an autonomous write tool those are meaningful omissions, so a 4 rather than a 5.

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

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

Schema has 0% description coverage, so the description must compensate. It adds real meaning for shared_set_id (must be an existing, attached list) and terms (each needs measured search-term evidence), but leaves match_type (default PHRASE), dry_run, run_id, and rationale undocumented in both schema and description. Partial compensation only.

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

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

States a specific verb+resource: 'Add negative keywords to a SHARED list' and immediately distinguishes the scope from the sibling — 'applies account-wide rather than to a single campaign.' It explicitly names add_negative_keywords as the single-campaign counterpart, 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?

Gives explicit when-to-use ('junk that applies account-wide'), names the alternative (add_negative_keywords) with the same evidence bar, and spells out prerequisites and ordering: 'create and attach it via mutate first (shared_set create, then campaign_shared_set create)' plus a pointer to list_shared_negative_lists for discovery. This is concrete routing guidance, not hand-waving.

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

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

The annotations only declare readOnlyHint=false and destructiveHint=false, but the description adds substantial behavioral disclosure: the tool is refused in unattended runs, it re-reads current field values before writing (same as mutate), and it executes the precise call a human approved rather than an agent reinterpretation. It also names the exact environment variable governing the refusal. This goes well beyond the 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?

Three sentences, each carrying distinct value: purpose, refusal condition, and read-before-write behavior. It is front-loaded with the core action and contains zero filler or repetition of schema/annotation 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?

With an output schema present, return values need no explanation, and the description covers purpose, usage boundaries, a critical refusal path, and a concurrency-relevant behavior. The main gap is dry_run semantics and what happens on failure (e.g., already-applied or invalid proposal). For a two-parameter tool this is close to 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 carry the parameter meaning. It gives proposal_id meaningful context (a proposal previously recorded by mutate — the exact call being approved), but says nothing about dry_run, whose behavior and purpose are entirely unexplained. Partial compensation for a required parameter, but a complete gap for the optional one.

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

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

States a specific verb and resource: "Execute a previously recorded proposal from the generic mutate tool." It distinguishes itself from the generic mutate tool, list_proposals, and dismiss_proposal by framing apply_proposal as the exact human-approved action rather than an agent re-decision. The first sentence alone fully differentiates this tool from its 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?

Provides explicit when-to-use context: apply a proposal only when a human is explicitly approving it, not when the agent is autonomously deciding to act on a propose-only finding. It also gives a concrete when-not condition with an environment variable check (ADS_AGENT_UNATTENDED=1). It does not name sibling alternatives like dismiss_proposal for the rejection case, which keeps it just short of a 5.

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

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

Annotations already mark readOnlyHint=true, and the description stays consistent by emphasizing that the tool 'assigns and refines' and 'returns' a mapping rather than mutating ad groups. It adds useful behavioral context about using Google's own themeing, the dependency on already-created ad groups, and the distribution workflow.

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 sentences deliver the core action, the key constraint, and a practical workflow without filler. The most important distinguishing detail — existing ad groups and Google's themeing — is front-loaded, and every sentence adds value.

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

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

Given that an output schema exists and annotations cover the read-only nature, the description adequately explains what the tool returns, the prerequisites, and the intended use case. The only minor gap is lack of detail about how campaign_id and ad_group_ids relate or conflict when both are supplied, which is low-risk for a read-only mapping 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 input schema has 0% description coverage, so the description must compensate. It explains keywords as a list to map, implies campaign_id via 'pass a campaign', and references existing ad groups corresponding to ad_group_ids, but it never mentions the required customer_id parameter or clarifies the optional/null behavior of ad_group_ids. This is partial compensation, not full.

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 — mapping keywords across existing ad groups via Google's themeing — and distinguishes it from creating themes from scratch. It also specifies the output: which ad group each keyword belongs in plus a suggested match type, so the tool's purpose is unambiguous and distinct from siblings like suggest_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 gives clear preconditions and workflow: ad groups must already exist, pass a campaign with pre-created ad groups, and to split a big ad group first create themed ad groups then run this. It implies when to use this tool versus alternatives, though it does not name an alternative tool explicitly.

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 aligns with that by framing the operation as a review. It additionally discloses a non-obvious behavioral trait: no performance data is consulted, which is why the tool is safe for accounts without history. openWorldHint is not contradicted.

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

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

Two sentences, front-loaded with the purpose, followed by a compact checklist of review areas and a critical constraint. Every clause earns its place and there is 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?

The description covers the review scope, the key data-absence constraint, and the environments where it works, while an output schema exists to document returns. The only notable gap is the undocumented optional 'today' parameter, which is minor given its default and optionality.

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 provides no parameter-level guidance beyond the operation itself. customer_id and campaign_id are self-explanatory, but the optional 'today' parameter and any format requirements are left entirely to 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 opens with a specific verb and resource — 'Structural review of a campaign' — and enumerates concrete findings such as targeting gaps, Display expansion left on, thin RSAs, and budget-to-bid mismatch. It also differentiates itself from performance-focused siblings by explicitly stating it uses no 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?

It clearly states when the tool is appropriate: because it uses no performance data, it works on test accounts and brand-new campaigns. It does not explicitly name sibling alternatives or include a when-not-to-use clause, but the context is clear enough for an agent to choose it over performance-dependent tools like keyword_performance or geo_performance.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds meaningful behavioral context by noting that Google retains at most 30 days of change history, which sets expectations about data availability and the limit of the days parameter.

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 tight sentences that pack in the core data model, use cases, and a retention caveat without fluff. Every clause adds value.

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

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

While the description captures the purpose and the 30-day retention constraint, it fails to guide invocation: it omits parameter semantics, required fields, defaults, and filtering behavior. The presence of an output schema helps, but the input side remains under-specified for a tool with 5 parameters.

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 does not name or explain parameters such as customer_id, days, limit, campaign_id, or exclude_api. It only hints at the 30-day window and client types, giving limited indirect meaning but not enough to compensate for the lack of schema descriptions.

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

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

The description clearly explains what the tool does: it returns who changed what, when, from which client, and which fields changed. It also differentiates the tool by framing it as answering 'why did performance shift' and 'was this setting deliberate', which distinguishes it from performance and audit-related 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 gives practical usage context by tying the tool to diagnosing performance shifts and determining whether a setting was deliberately changed. It does not explicitly name alternatives or state when not to use it, but the use cases are clear enough for an 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?

The description goes beyond the readOnlyHint annotation by explicitly explaining that the one write probe uses validate_only and writes nothing, which removes any concern about mutation. It also aligns with openWorldHint by indicating the results depend on the actual installation, credentials, API version, and access level. No annotation contradiction exists.

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

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

The description is compact and well-structured: purpose first, usage trigger second, safety reassurance third. Every sentence adds value and there is no repetition of annotations or 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?

The tool has an output schema, so return-value details are not required. The description covers purpose, usage timing, and behavioral safety well. The only meaningful gap is the undocumented optional customer_id parameter, which is a minor omission for an otherwise well-specified diagnostic 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 only parameter, customer_id, has no schema description (0% coverage) and is never mentioned in the tool description. An agent is left guessing whether or how customer_id scopes the setup check; the title 'Customer Id' and default '' provide only minimal hints. With low schema coverage, the description needed to compensate but did not.

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 ('Check') and a clear resource ('what this installation can actually do'), enumerating credentials, API version, and permitted API methods. It distinguishes this diagnostic tool from the sibling tools by focusing on the developer token's access level and setup validation.

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 gives an explicit trigger: 'Run this first when something is refused, or right after setup.' This tells an agent when to use the tool with little ambiguity, though it doesn't name specific alternative tools or when not to use it.

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

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

Annotations already declare readOnlyHint=true, so no safety contradiction exists. The description reinforces this with 'Inspect' and adds useful scoping detail like 'every conversion action', but it does not disclose deeper behavioral risks or constraints such as account-wide effects or latency. It adds moderate context beyond the annotation, but not rich behavioral disclosure.

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

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

Two sentences, front-loaded with the core purpose and a concise list of returned fields, followed by a decision-oriented usage rationale. No filler or redundant restating of the schema.

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

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

Given the output schema exists, the description doesn't need to detail return structure. It covers the main decision context, the data fields, and the read-only nature. It falls slightly short only in explaining how date_range affects the conversion counts, but the schema provides the parameter default and the task context is otherwise 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 needed to compensate for the two parameters, especially date_range, which directly affects the conversion counts the tool reports. The description never mentions customer_id or date_range, leaving the agent to infer their meaning solely from the parameter names and default. This is a clear 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 a specific verb-resource pair, 'Inspect conversion tracking', and enumerates exactly what is returned: status, category, counting type, bidding participation, and conversion counts. This clearly differentiates it from sibling performance or keyword tools, which focus on different entities and metrics.

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

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

The description explicitly states when to use the tool: to diagnose whether low conversion counts stem from a weak funnel or broken tracking, framing it as central to the autonomy gate. It does not mention alternatives or when not to use it, but the decision context is clear 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?

Beyond the annotations, the description adds critical behavioral details: the operation is atomic, the campaign is always created PAUSED, it cannot spend until a human enables it in the Google Ads UI, and confirmation is required first. This gives the agent a strong sense of the real-world side effects and safety posture of the call.

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

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

The description is three short sentences with no filler. It front-loads the core purpose, then gives the prerequisite, the paused behavior, and the user-confirmation requirement. Every sentence adds necessary operational guidance.

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 high-stakes mutate call, the description covers the essential workflow: preview first, confirm with the user, then create atomically. It also discloses the most important consequence—the campaign starts paused and cannot spend until a human enables it—and because an output schema exists, return details are not needed in the description.

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

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

The top-level schema provides no description for the two parameters, so the description must compensate. It does by explaining that spec must be the exact spec from a successful preview_campaign and that confirm_token comes from that same preview, which is essential semantics the schema alone does not convey.

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 the campaign for real', and clarifies it is 'a single atomic mutate'. It also distinguishes the tool from preview_campaign by requiring a successful preview's spec and confirm_token, making the purpose 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 clearly specifies the precondition: the tool requires 'the exact spec and confirm_token from a successful preview_campaign', and instructs the agent to confirm with the user before calling. It does not explicitly name alternatives like create_campaign_draft or when not to use them, but the prerequisite and user-confirmation guidance provide a solid usage 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?

Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description reveals the key behavioral contract: the draft is inert, edit-safe, and 'Nothing about the base campaign changes until you call promote_campaign_draft'. It also explains how the draft can be manipulated via other tools using its own campaign ID, adding meaningful operational context.

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

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

Two focused sentences with no filler. The action is front-loaded, and the follow-up explains the important safety model and related tools. 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 strong on workflow and safety, and an output schema exists so return-value details are covered. The main gap is the complete absence of parameter semantics in both the schema and description, which prevents a higher 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%, and the description does not compensate. It never mentions customer_id, campaign_id, or draft_name explicitly. The phrase 'existing campaign' loosely implies campaign_id, but draft_name and customer_id semantics are left entirely to inference from 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 clearly states the action and resource: 'Create a draft copy of an existing campaign'. It also distinguishes itself from create_campaign and promote_campaign_draft by framing the result as an 'inert shadow campaign', leaving no ambiguity about what the tool does.

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

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

The description gives clear usage context: use this to get a safely editable copy of a live campaign before mutating it, and only call promote_campaign_draft when you actually want changes to go live. It implies the alternative of editing the live campaign directly and explains why the draft route is preferable, though it does not explicitly enumerate when-not-to-use scenarios.

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 readOnly=false and destructive=false, and the description adds the important instance-level behavior: dismissing is not a permanent ban and proposing the identical change later reopens it. This goes beyond the schema and annotations, though it does not detail reason handling.

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

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

Two sentences with no filler; the core action and effect are front-loaded, and the nuance about reopenability is delivered in a single compact follow-up sentence.

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, has an output schema, and annotations cover safety traits, so the description covers the key behavioral context of dismissing. It is slightly incomplete on what the reason parameter is for, but given the optional default and simple shape this remains minor.

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 never mentions proposal_id or reason, so it adds no meaning beyond the raw parameter names. The names are somewhat self-explanatory, but the description does not compensate for the absent 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 a specific verb and resource: 'Dismiss an open proposal without executing it,' and immediately distinguishes the operation from execution and from listing by stating the effect on list_proposals. This clearly differentiates it from siblings like apply_proposal.

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 conveys that this tool is for dismissing an open proposal rather than executing it, and that the proposal will no longer appear in list_proposals. It does not explicitly name a sibling such as apply_proposal as the alternative, but the intended use context is 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?

Annotations already indicate readOnlyHint=true, and the description reinforces this with 'Read-only.' It adds behavioral context beyond the annotations by describing what the explanation covers: the matching rule, the tier, and other considerations. No contradiction exists, though details about edge cases such as wildcard fields or invalid inputs are absent.

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 tight sentences: the first explains behavior and output, the second gives direct usage guidance. There is no filler or redundant restating of the tool name, 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?

The description covers the tool's purpose and relationship to mutate, and an output schema exists to handle return-value details. However, with five parameters, zero schema-level descriptions, and meaningful defaults like field='*' and direction='any', the absence of parameter guidance leaves notable gaps 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 carries the burden of explaining parameters, but it only minimally implies that 'field' is the field to change. It does not explain the required resource and operation parameters, nor the meaning of value, direction, or the '*' default. An agent would likely need external knowledge of the mutate tool's vocabulary to call this 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 clearly states a specific action ('Explain what would happen if the generic mutate tool were asked to change one field') and the expected output content ('which rule matches, at what tier, and what else was considered'). It also differentiates the tool from the sibling mutate tool by framing itself as a pre-check mechanism.

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 an explicit usage directive: 'Use this before mutate to find out whether a change is permitted.' This clearly identifies when to use the tool in relation to mutate, though it does not explicitly state when not to use it or mention an alternative like list_capabilities.

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 consistently reflects a non-mutating forecasting operation. It adds useful behavioral context beyond annotations by specifying the projected metrics and the validation purpose around budget and bid.

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 efficient sentences with no wasted words. The first sentence front-loads the action and outputs, and the second adds sequencing and purpose. 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?

With an output schema present and annotations covering side effects, the description adequately explains the core purpose, expected metrics, and its role relative to preview_campaign. The main gap is optional parameter semantics, but required parameters are identifiable from the schema and names.

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 only references keywords, daily_budget, and max_cpc, leaving customer_id, geo_target_ids, language_ids, match_type, bidding, start_date, and forecast_days semantically unexplained. With 10 parameters and no schema descriptions, this is insufficient.

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 ('Forecast') and resource ('a campaign'), enumerates concrete outputs (clicks, impressions, cost, CPC, conversions, CPA) and key inputs (keyword set, daily budget, max CPC). It also distinguishes itself from the sibling preview_campaign by explaining it is the step to run beforehand.

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

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

Explicitly instructs to 'Run this before preview_campaign' and provides the rationale ('to find out whether the budget and bid actually buy enough traffic to learn anything'). It names an alternative and the sequencing condition, though it does not discuss other alternatives or when not to use it.

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

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

With readOnlyHint=true and openWorldHint=true, the read-only nature is already covered by annotations. The description adds value by explaining the semantic distinction between actual and targeted location and why that matters for interpretation, without contradicting the annotations.

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

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

Two sentences with no filler, front-loaded with the core definition and followed by a meaningful illustrative contrast. Every phrase earns its place and the description is appropriately sized for the tool's complexity.

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

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

The core concept and differentiator are fully explained, and the presence of an output schema covers return value structure. However, the complete lack of parameter guidance leaves a practical gap for invocation, especially given 7 parameters and no enum constraints.

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

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

Schema description coverage is 0% and the description provides no information about parameters such as level, date_range, limit, or campaign_id. It offers only high-level conceptual context, leaving the agent to infer valid values and formats from parameter names and defaults alone.

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 defines what the tool reports: performance by the geographic location a user actually was in or searched from, contrasting it with targeted geography. It answers the specific question 'is this converting where I think it is', making the purpose unambiguous and distinguishing it from targeting-related concepts.

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: when actual user location matters rather than targeted location. It explicitly says targeting alone cannot answer the question, providing a strong selection signal, though it does not name a specific sibling tool as an alternative.

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

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

Annotations already mark readOnlyHint=true, and the description aligns by saying 'Read back a campaign in full.' Beyond annotations, it discloses exactly what will be returned and implies verification of persisted state, adding 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?

Two tight sentences; the first front-loads the operation and scope, the second gives the intended usage. Every clause earns its place, 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 simple read-only retrieval by two self-explanatory IDs, plus an output schema and read-only annotations, the description covers the operation, its timing after create_campaign, and its content scope. Nothing required to call it correctly is missing.

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

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

Schema description coverage is 0%, and the description does not explain customer_id or campaign_id beyond the tool's general reference to 'campaign.' The property names are self-explanatory, but the description adds no parameter-level semantics or constraints to compensate 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?

Description opens with a specific verb and resource, 'Read back a campaign in full,' and enumerates distinct content areas: settings, targeting, ad groups, keywords, and responsive search ad assets. This clearly distinguishes it from siblings like list_campaigns or preview_campaign without needing the schema.

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

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

Explicitly frames the primary use case: 'Use this after create_campaign to verify what actually landed.' It does not name alternatives or exclusions, but the context is clear enough for a sibling-rich toolset.

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

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

Annotations already declare readOnlyHint=true, so safety is covered. The description adds meaningful behavior beyond that: results are sorted by cost with biggest spenders first, and the QS components are included because the single quality-score number alone is ambiguous. This is genuinely useful 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?

Three sentences, each earning its place: output contents, sort order, and diagnostic use case. The most decision-relevant information is front-loaded, and there is no filler.

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

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

The output schema exists and annotations cover the read-only safety profile, so return-value and permission details are not required. However, with 8 parameters and zero schema descriptions, the tool description leaves parameter semantics to default titles, which is adequate for simple fields but incomplete for date and filtering 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%, so the description carries the burden of explaining the 8 parameters, but it names none of them. Parameter titles like zero_conversions_only and min_impressions are somewhat self-explanatory, but the description does not compensate for the missing schemas or clarify how parameters interact.

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

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

States a specific resource (per-keyword performance) and a diagnostic purpose (find keywords spending without converting), listing quality score, its three components, and effective bid. The scope is clear and distinct from broad siblings like performance, though it does not explicitly name an alternative 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?

Gives an explicit use case: 'Use this to find keywords spending without converting' and explains how to act on the output by inspecting AdRel/LPExp/ExpCTR to diagnose low quality score. It does not mention when to prefer related siblings such as search_terms or performance.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, reducing the burden on the description. The description adds a valuable behavioral guarantee: it reports exactly on the terms passed and does not expand or invent anything. This clarifies an important boundary beyond the read-only annotation, though it does not cover edge-case behavior such as handling of unmatched keywords.

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

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

Two sentences with no wasted words. The first sentence front-loads what the tool returns, and the second sentence names the sibling and the intended use case. 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 clear about the tool's core behavior and return type, and an output schema exists to document return values. However, with 0% schema description coverage, key input parameters like geo_target_ids and include_search_partners are left under-explained, which could cause incorrect calls despite the presence of sibling tools like suggest_geo_targets. The gap is moderate.

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 five parameters and zero descriptions, so the description must compensate. It only clarifies the keywords parameter with 'a list of keywords you already have'; geo_target_ids, customer_id, language_id, and include_search_partners receive no semantic explanation beyond their names and defaults. This is insufficient for a low-coverage 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 verb and resource: it reports average monthly search volume, competition, and bid range for a list of keywords the user already has. It also distinguishes itself from suggest_keywords, making its scope immediately clear to an agent scanning sibling tools.

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

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

The description explicitly names suggest_keywords as the alternative and explains the difference: this tool does not expand or invent terms, while suggest_keywords presumably does. It also gives a concrete use case—auditing an existing keyword list—so an agent knows when to choose 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 declare readOnlyHint=true and openWorldHint=true, so no destructive behavior needs flagging. The description adds useful behavioral context beyond the annotations: it explains the reachable-account scope, the data returned, and its role as a prerequisite step for other tools.

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 concise sentences with no redundant information. The first sentence states what the tool returns, and the second provides a direct, actionable usage instruction. Every word earns its place.

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

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

For a simple, zero-parameter, read-only list tool with an output schema, the description is complete. It explains the purpose, the output fields, the credential-bound scope, and the primary usage pattern (call first). Nothing critical 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?

The tool has zero parameters, so the baseline is 4 and the description has no parameter burden. It does not need to explain parameter meanings because there are none; the description even implies no input is required by saying to call it first to obtain the customer_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 states the action ('List the Google Ads accounts'), the scope ('these credentials can reach'), and the meaningful output attributes (currency, time zone, test account flag). It also sets this tool apart as the entry point for obtaining customer_id, distinguishing it from other list tools like list_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?

The description gives an explicit usage directive: 'Call this first to get the customer_id for other tools.' This provides clear context for when to use it, though it does not explicitly name alternatives or state when not to use it. For a zero-parameter discovery tool, this is still 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?

Annotations already carry readOnlyHint=true and openWorldHint=true, lowering the burden. The description adds value beyond them by disclosing the draft-to-parent-campaign mapping and the status field, plus the actionable nature of the returned ID. 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?

A single dense sentence with zero filler, front-loaded with verb + resource, and every clause earns its place — return fields, parent mapping, and downstream tool routing.

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 tool with an output schema and safety annotations, the description covers what is returned and how to use the results. The only notable gap is the semantics of the optional campaign_id parameter, which neither schema nor description documents.

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, but it never explains what the optional campaign_id does (filter by parent campaign? by draft ID?). customer_id is self-evident, but the ambiguous campaign_id with default '' is a real gap 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?

States a specific verb ('List') and resource ('campaign drafts') and enumerates the exact fields returned: status, the parent campaign each draft belongs to, and the draft's own campaign ID. The word 'drafts' cleanly separates it from siblings like list_campaigns and get_campaign 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?

Gives clear workflow context: the returned draft ID is the target for get_campaign / mutate / add_rsa while editing. This implies the tool is the discovery step before editing, but it doesn't give explicit exclusions (e.g., 'for live campaigns, use list_campaigns').

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds that returned campaigns include status, budget, and bidding strategy, but it does not mention include_removed behavior, pagination, or ordering. No contradiction with annotations exists.

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

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

The description is a single front-loaded sentence with no filler. Every word contributes meaning: the operation, the resource, the scope, and the returned fields.

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 an output schema, the description is minimally workable: an agent can understand it lists account campaigns and that customer_id is required. However, it leaves include_removed semantics and tool-selection guidance unexplained, which are real gaps 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%, and the description does not explain customer_id format or the semantics of include_removed beyond what the parameter name and default imply. The phrase 'in an account' loosely associates customer_id with an account, but that is minimal compensation for the missing parameter 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 names a specific verb and resource ('List campaigns'), the scope ('in an account'), and the included fields ('status, budget, and bidding strategy'). This distinguishes it from siblings like list_accounts and get_campaign by virtue of the plural resource, though it does not explicitly name any alternative 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 implies usage when a campaign list is needed and supplies the account scope, but it provides no explicit guidance about when not to use it or which sibling alternative to prefer, such as get_campaign for a single campaign or audit_campaign for deeper analysis. The usage context is clear but entirely 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?

The readOnlyHint annotation already declares safety, and the description reinforces it with 'Read-only.' Beyond annotations, it adds meaningful behavioral context: absent capabilities are refused, so the tool also enumerates what is NOT possible. This goes beyond the structured metadata and helps an agent understand the tool's authority boundary.

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, placing the primary action and scope in the first sentence. The second sentence adds a valuable consequence (refusal of absent capabilities). The final 'Read-only' is somewhat redundant with the annotation, but it is brief and not harmful.

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 listing tool with an output schema, the description covers the core behavior, scope, and refusal semantics. The main gap is the lack of parameter semantics, but since both parameters are optional and the output schema exists, the overall context is still 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%, and the description does not explain the 'tier' or 'resource' parameters, which appear to act as filters for the capability table. The phrase 'at which tier' hints at the notion of tiers but does not connect it to the input parameters. The description fails to compensate for the undocumented 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 ('Show') with a concrete resource ('the capability table') and defines its scope: every resource, operation, and field the mutate tool may touch, plus the tier. It clearly distinguishes itself from mutation tools like 'mutate' and from capability-explanation tools by framing itself as the authoritative allow-list.

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 evident: consult this tool to learn what is possible and what is refused. 'Anything absent from this table is refused' gives strong contextual guidance for when to call it. It does not explicitly name alternatives or state when not to use it, but the purpose is clear enough.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the description has a lighter burden. It adds meaningful context about the source and nature of proposals. 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?

One dense sentence with no filler. The core behavior is front-loaded, and the explanatory clause adds necessary context about the relationship to mutate and apply_proposal 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?

The description covers purpose and sibling relationships, and an output schema exists to describe return values. However, the optional customer_id parameter is entirely unexplained, which is a significant gap for correct invocation, and the concept of 'open' is only implicitly defined by sibling tools.

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

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

The single customer_id parameter has no schema description and is not mentioned in the tool description. With schema description coverage at 0%, the agent receives zero information about what this parameter does, whether it is needed, or how it affects results.

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

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

States a specific verb and resource: list open proposals. Explains what these proposals are (diffs from the mutate tool's propose-only findings) and how they relate to apply_proposal and mutate, making it clearly distinguishable from sibling tools.

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

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

Clearly implies when to use this tool: to retrieve executable proposals instead of re-deriving mutate calls manually. It references apply_proposal as the follow-up action, giving workflow context, though it does not explicitly state exclusions or when not to use it.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the description carries a lighter burden. It adds contextual detail about the shared-list behavior (applies to many campaigns at once) but does not disclose potential limitations like pagination, empty results, or the meaning of the open-world hint. 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?

Two sentences, zero filler. The first sentence front-loads the core action and return content; the second explains the shared-list concept and names the sibling it is not. Every clause earns its place.

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

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

For a simple read-only list tool with an output schema and one obvious parameter, the description covers the essential semantics. The only gap is that it does not mention the customer_id format or any caveats implied by openWorldHint, but these are minor against the provided schema and annotations.

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

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

Schema description coverage is 0%, and the description does not mention customer_id at all. However, the single parameter is self-explanatory by name ('customer_id') and the phrase 'in the account' implies its role. The description adds no format or usage detail, but the parameter's intuitive meaning prevents a lower score.

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 uses a specific verb ('List') and resource ('shared negative-keyword list'), and states exactly what is returned: term counts and attached campaigns. It also differentiates itself from sibling add_negative_keywords by explaining the shared-list concept, so an agent can distinguish the tool 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 on when to use this tool (to see shared lists and their scope) and explicitly contrasts it with per-campaign add_negative_keywords. However, it does not mention when to use the sibling add_shared_negative_lists, which is the natural alternative for creating such lists, so the guidance stops one step short of fully routing 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?

Beyond annotations (write-only, open-world, non-destructive), the description reveals critical behaviors: the dry-run diff with token confirmation, capability-table governance, refusal of unruled/forbidden operations, and that 'every update reads the current values first, so the journal can undo it.' This substantially exceeds what annotations alone communicate and does not contradict 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 compact and well-organized: purpose first, then workflow/behavior, then a clear routing preference. Every sentence contributes – there is no filler, and the most decision-relevant 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 general write path with 7 parameters, an output schema, and annotations, the description covers the essential operational context: capability-table governance, two-step confirmation, safety via undo journal, and the existence of more specific siblings. It provides enough for an agent to invoke correctly, and where specifics are lacking, it points to the governing mechanism (capability table).

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 burden. It effectively explains confirm_token ('Call it once with no confirm_token to see the exact diff... and a token') and dry_run implicitly through the two-step flow. It also gives meaning to resource and operation through the 'change any mutable resource' framing. However, fields_json and resource_name are not semantically described, leaving some parameters unexplained.

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 'Change any mutable Google Ads resource' – a specific verb and resource scope – and immediately positions it as 'the general write path' that 'reaches every resource the API exposes.' It explicitly contrasts itself with specific sibling tools like pause_keywords, making its role unmistakable. This is a clear, differentiated statement of purpose.

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

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

The description gives explicit guidance: 'Prefer the specific tools where they exist – pause_keywords and the rest measure evidence this path cannot.' It also explains the exact two-step invocation pattern ('Call it once with no confirm_token... Call it again with that token'). This tells an agent both when to use this tool and when to choose an alternative, with no inference required.

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 annotations already establishing readOnlyHint=false and destructiveHint=false, the description adds value beyond them through 'Pauses, never removes,' a firm reversibility/non-removal commitment, plus the threshold logic governing the decision. It does not contradict any annotation; pausing is consistent with a mutating yet non-destructive operation.

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

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

Two sentences deliver the action, the safety boundary, and the threshold rationale with zero filler. The core purpose is front-loaded and every clause earns its place.

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

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

An output schema covers return values and the core behavior and decision logic are well explained. However, for a mutating tool the most useful guardrail, dry_run, is never mentioned, and the connection between run_id and the revert_last_run sibling is left implicit — adequate overall, but with clear gaps around parameter 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%, so the description must compensate for undocumented parameters, but it only partially does. 'Whole ad groups' clarifies that ad_group_names expects full group names and 'spending without converting' hints at the rationale field, yet run_id, dry_run, customer_id, and campaign_id are left entirely unexplained.

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-resource pair — 'Pause whole ad groups that are spending without converting' — and adds the behavioral boundary 'Pauses, never removes.' The threshold remark referencing keywords differentiates it from the sibling pause_keywords tool without needing to open either schema.

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

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

It states the triggering condition ('spending without converting') and explains why thresholds are calibrated differently ('an ad group is a much bigger unit to switch off'), giving clear context for when to invoke it. The keyword-level counterpart is strongly implied by the threshold comparison, but the alternative is not explicitly named and no when-not-to-use exclusions 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 state readOnlyHint=false and destructiveHint=false, and the description adds meaningful behavioral context beyond that: the action is reversible because it pauses rather than removes, and keywords that fail the evidence threshold are kept and reported. This helps an agent understand side effects and outcomes 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 brief and front-loaded with the core action and condition. Each sentence adds useful information, though the phrase 'Evidence is measured here' is slightly vague and could be more direct without adding length.

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 core behavior and reversibility, and an output schema exists to explain return values. However, it leaves important operational details unaddressed, such as the purpose of dry_run, how evidence thresholds are computed, and how the tool differs from pause_ad_groups or add_negative_keywords. Given the parameter count and schema coverage, this is adequate but not complete.

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

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

Schema description coverage is 0%, and the description does not explain any of the six parameters. Parameters like dry_run and rationale are particularly important to understand but are left undocumented. The description provides some context for keyword_texts through the word 'keywords', but it fails to compensate for the lack of schema descriptions.

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

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

The description clearly identifies the verb (pause), the resource (keywords), and the specific selection criterion (spending without converting). It also distinguishes itself from removal or permanent actions by explicitly stating it never removes keywords, making its purpose distinct from sibling tools that delete or mutate.

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 clear context for when to use the tool: keywords that are spending but not converting, with evidence measured against a policy threshold. It does not explicitly name alternatives or say when not to use it, but the reversible pausing behavior implies a preferred use case over removal.

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 genuinely useful behavioral context beyond annotations: the test-account failure mode ('test accounts serve no ads and return no metrics') and level-specific metric composition (impression share / budget-vs-rank at campaign, ad strength at ad). 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?

Three sentences, each earning its place: the first states the core purpose and levels, the second adds differentiating metric details, the third states access requirements and the failure mode. The most important scoping information is front-loaded in the first sentence, with 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?

The output schema exists, so return values need no explanation. However, with 9 parameters at 0% schema coverage and closely related siblings (keyword_performance, ad_asset_performance, geo_performance), the description covers access prerequisites and level differences but never addresses how to construct a valid call for the remaining parameters (segment, limit, include_zero_impressions, campaign_id) or how to combine start_date with date_range.

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. It partially compensates by clarifying the 'level' parameter's valid values ('campaign, ad group, or ad level') and the date-range concept, but provides no guidance on limit, segment, customer_id, campaign_id, or include_zero_impressions. For a 9-parameter tool with zero schema descriptions, this is meaningful but incomplete 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?

The description states a clear resource ('Performance metrics') and scope ('at campaign, ad group, or ad level over a date range'), implying the retrieve/get verb. The mention of impression share at campaign level and ad strength at ad level provides specificity that helps distinguish it from sibling tools like keyword_performance or ad_asset_performance, though it doesn't name those siblings explicitly.

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

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

The description gives concrete when-to-use context: 'Needs Basic access and a live campaign — test accounts serve no ads and return no metrics.' This tells an agent the preconditions for a successful call and a clear failure mode. It doesn't explicitly name alternatives by sibling tool name, but the level scoping implicitly routes keyword/asset/geo level queries elsewhere.

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 that this is a safe, read-only query. The description adds useful context about what the policy covers and that it should be checked before mutations, but it does not disclose any behavioral traits beyond what annotations already provide.

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 first sentence states the core purpose and output content, and the second gives an action-oriented usage instruction. Every sentence earns its place 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?

The description covers the main purpose, output categories, and when to call the tool, while an output schema is present to handle return-value details. The only notable gap is the lack of explanation about the optional parameters, which prevents a perfect completeness 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%, and the description does not mention campaign_id or customer_id at all. While the parameter names are somewhat self-explanatory and both are optional with defaults, the description fails to explain whether these parameters scope the policy to a specific campaign/customer or how they affect the returned policy.

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 ('Show') and resource ('the active policy'), then enumerates exactly what the tool reports: allowed action modes, evidence thresholds, and remaining change budget. This clearly distinguishes it from sibling tools that operate on campaigns, keywords, or proposals.

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 usage guidance: 'Call this before attempting any change so you know what will be permitted.' It does not name alternatives or exclusions, but the tool is unique among siblings as a policy-status read, so the when-to-use guidance is sufficient for a strong score.

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

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

The description explains the validate_only mechanism, confirms nothing is written, and enumerates the return payload (rendered plan, errors, confirm_token). This adds meaningful context beyond the readOnlyHint and openWorldHint annotations. It doesn't cover token expiry or authentication details, but those are less critical for safe invocation.

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

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

The description is two sentences with no filler. The critical dry-run and side-effect-free facts are front-loaded, the return values are listed, and the user-facing instruction is included. Every phrase 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 one-parameter tool with an output schema and readOnlyHint annotation, the description covers what the tool does, what it returns, and the required relationship to create_campaign. The only shortcoming is the lack of explicit parameter-level guidance, but the rich input schema compensates for that. Overall it gives an agent enough to invoke it correctly and understand the expected flow.

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 single `spec` parameter has no description in the schema (0% coverage at the top level), and the tool description doesn't explain its structure. However, the nested CampaignSpec schema is extensively self-documented with descriptions for fields like customer_id, daily_budget, and final_url. The description adds the high-level 'campaign spec' framing but no field-level guidance, so the schema carries most of the burden.

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 ('Dry-run'), a specific resource ('campaign spec'), and the key outcome ('validate_only so nothing is written'). It also distinguishes itself from create_campaign by returning a confirm_token to pass to that tool. No ambiguity about what this tool does.

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

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

It gives an explicit, mandatory usage rule: 'Always call this before create_campaign; show the plan to the user.' This tells the agent exactly when to invoke this tool and names the relevant sibling as the follow-up. It also implies when not to use it (when ready to write a campaign).

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

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

Annotations already declare readOnlyHint=true, and the description reinforces and expands on this by explaining linting locally, submitting with validate_only so nothing is written, and returning a confirm_token. There is no contradiction; the behavior is transparent and well-matched to the annotation.

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

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

The description is three sentences, front-loaded with the core purpose, and every clause earns its place: dry-run, no-write guarantee, return contract, and workflow guidance. It is dense but not padded.

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 read-only annotations and the presence of an output schema, the description covers what the tool does, why it exists, when to use it, what it returns, and what the agent should do next. Nothing critical is missing for correct invocation.

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

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

The single spec parameter has low reported schema description coverage, and the description does not enumerate the required fields such as customer_id, ad_group_id, final_url, headlines, and descriptions. It does add useful context by emphasizing the ad group must already exist and that the call is a dry-run, but it leaves most parameter meaning to the nested 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 verb and resource: dry-run a responsive search ad for an EXISTING ad group. It also distinguishes this from add_rsa by mentioning validate_only and no write, and from preview_campaign by scoping to an existing ad group.

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

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

It explicitly says when to use this tool: after an audit_campaign finding, before add_rsa, and as the correct path because Google Ads ads are immutable. It also gives the follow-up action of pausing the old ad separately, which leaves no ambiguity about the intended workflow.

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

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

The description adds substantial behavioral context beyond the sparse annotations: promotion is asynchronous and returns immediately without waiting, it overwrites live campaign behavior, and it documents the full status progression PROPOSED -> PROMOTING -> PROMOTED (or PROMOTE_FAILED). It also discloses the two-phase preview/commit safety mechanism. This is consistent with annotations (readOnlyHint=false, destructiveHint=false); no contradiction.

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

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

Four dense sentences with the critical live-traffic warning front-loaded in the first sentence. Each subsequent sentence earns its place: the two-phase call in sentence two, asynchronous behavior in sentence three, and verification steps in sentence four. There is zero 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 moderately complex tool (async execution, two-phase confirmation, state transitions), everything an agent needs is present: what happens, what gets overwritten, how to preview safely, how to confirm, and where to verify the outcome with exact status transitions. Since an output schema exists, not documenting return values is acceptable.

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 burden, and it delivers the key semantic for confirm_token: absent means preview, present means execute — meaningfully expanding the schema's bare 'default: ""'. draft_resource_name's role is inferable from the overall description context, but customer_id is never mentioned and is only interpretable by convention shared across sibling tools.

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: 'Promote a campaign draft's edits back into the live base campaign.' It also differentiates this from its draft-workflow siblings by explicitly flagging it as the one action in that workflow that touches live traffic, so an agent can distinguish it from create_campaign_draft, list_campaign_drafts, and remove_campaign_draft.

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 call-sequence guidance: call without confirm_token to preview (showing which campaign it would overwrite), then call again with the token to execute. It also directs the agent to list_campaign_drafts afterward to observe the outcome. However, it never explicitly names alternative tools or states when not to use this one — the exclusion of siblings is implicit ('the one action in the draft workflow that touches live traffic').

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

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

Annotations only declare destructiveHint=true and readOnlyHint=false; the description goes far beyond that with rich behavioral context: Google Ads has no un-remove, a removed campaign can never be re-enabled, historical stats remain queryable, and execution requires a two-phase confirm_token flow. This meaningfully supplements the structured annotations rather than repeating them, and it is fully consistent with 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?

Five sentences, zero filler. Each sentence earns its place: purpose, irreversibility with a stats caveat, the two-step token flow, the PAUSED prerequisite, and the precautionary prefer-paused advice. The most critical warning (IRREVERSIBLE) is front-loaded right after the purpose statement, so an agent sees the risk before anything else.

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, two-phase mutation tool, the description covers nearly everything an agent needs: irreversibility, consequences for stats, the token workflow, the prerequisite state, and caution guidance. Since an output schema exists, documenting return values isn't required. The only notable omission is the role of acknowledge_irreversible and what happens if it is left false, which leaves a small but real gap in the call contract.

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. It substantially clarifies the most complex parameter (confirm_token) by explaining the preview-then-execute flow: calling without it returns what will be destroyed plus a token, and calling again with the token executes. customer_id and campaign_id are self-explanatory from their titles, but acknowledge_irreversible's role is never mentioned — a small gap given it is one of only four parameters.

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

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

The description opens with a specific verb and resource — "Permanently remove a campaign" — and sharply distinguishes the action from neighboring concepts: it contrasts with the campaign-draft tools (remove_campaign_draft) by targeting campaigns, and with pause-style tools by emphasizing permanence. The irreversibility warning and the "prefer leaving a campaign paused" guidance make the tool's boundary unmistakable, so an agent can select it correctly without inspecting 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 gives a clear when-to-use condition ("The campaign must already be PAUSED") and a strong when-not-to-use directive ("Prefer leaving a campaign paused unless there is a real reason to remove it"). It also explains the two-step invocation sequence. The only gap is that no alternative tool is explicitly named — the pause recommendation is stated as a state, not routed to a specific sibling — but the guidance is otherwise comprehensive.

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

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

The description says the tool 'deletes the shadow copy,' which contradicts the annotation destructiveHint=false. Deleting a draft is a destructive operation on that draft resource, so the description and annotation are in direct conflict.

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

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

Two sentences with no filler. The main action is front-loaded, and the following sentence adds important scoping and side-effect information 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?

The description conveys the core behavior well and an output schema exists, so return values are covered. However, the parameter semantics are undocumented and the contradiction with destructiveHint leaves the safety profile ambiguous for the agent.

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 provides no guidance on customer_id or draft_resource_name beyond their self-explanatory names. It does not explain the expected format, where the draft resource name comes from, or relationships between the parameters.

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

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

The description states a specific action, 'Discard a campaign draft,' and clarifies it deletes only the shadow copy while leaving the live campaign untouched. This clearly differentiates it from promote_campaign_draft and remove_campaign 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 makes the use case clear: use this when you want to discard a draft rather than promote it. It contrasts with the promotion path and reassures that the live campaign is unaffected, though it does not explicitly name alternative tools or exclusion conditions.

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 and destructiveHint=false, so the description need not restate those. It adds valuable behavioral context that the tool re-enables paused items and removes negatives the agent added, which goes beyond the schema and helps an agent predict side effects. No contradiction with annotations is present.

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 tight sentences with no filler. The core action is front-loaded in the first sentence, and the second provides essential context ('escape hatch') and concrete effects. 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?

Given the output schema exists, return-value details are not needed. However, the description does not fully compensate for the 0% schema coverage on parameters: customer_id and dry_run are left to inference. The core behavior and when-to-use guidance are solid, but the invocation details are incomplete for a tool with three parameters.

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 addresses run_id implicitly through 'Defaults to the most recent run,' but leaves customer_id and dry_run completely unexplained. An agent cannot know what customer_id scopes or what dry_run does from the description alone.

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 ('Undo') and resource ('a run's changes'), and explains the mechanism ('using the inverse operations stored in the journal'). It also clarifies the default behavior ('Defaults to the most recent run') and frames the tool as an escape hatch, which clearly differentiates it from the many campaign/keyword management 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 explicitly says when to use this tool: 'when the agent gets something wrong.' It also implies a conditional for run selection via 'Defaults to the most recent run,' suggesting the run_id parameter controls targeting another run. It does not name alternative tools, but no sibling appears to serve the same undo function, so the lack of explicit exclusions is acceptable.

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. The description reinforces this by stating 'read-only,' 'cannot write,' and 'Only SELECT is accepted,' adding GAQL-specific nuance beyond the annotations. It also discloses that the tool returns raw rows, which is 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?

Two short sentences with no filler. The core action, output, and constraining rule are all front-loaded, and every sentence adds unique value.

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

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

For an arbitrary query escape hatch, the description covers the essential behavior, the read-only guarantee, and the SELECT-only restriction. An output schema exists, so the return shape does not need description. The only notable gap is parameter documentation, but the tool's simplicity and escape-hatch framing keep it adequately complete.

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

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

Schema description coverage is 0%, so the description carries the burden for parameter meaning. It implicitly defines the 'query' parameter as a GAQL query, but it does not explain 'customer_id' or 'limit' at all. The description provides minimal help for the two required parameters and one optional parameter.

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

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

The description uses a specific verb-resource pair ('Run an arbitrary read-only GAQL query') and clearly states the output ('return the raw rows'). It also distinguishes the tool from siblings by calling it an 'escape hatch for anything the other tools do not cover,' making its role 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 explicitly frames this tool as a fallback for anything other tools do not cover, which is clear usage context. It also gives a hard constraint ('Only SELECT is accepted'). It stops short of naming specific alternative tools or saying when NOT to use it, so it is clear but not fully exhaustive.

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. The description adds value by revealing that results are real user search queries, include metrics, and indicate whether each term is already a keyword or a negative. This goes beyond the annotations and helps the agent understand the nature of the data returned.

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, tightly worded sentence. It front-loads the core definition ('real search queries that triggered your ads') and ends with the practical purpose. There is no filler or repetition, making it easy to scan and quickly understand.

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 effectively conveys the tool's role and the nature of its data, but it does not address parameter semantics or how to choose between filters like date_range, only_unadded, or min_impressions. Since an output schema exists, return values are covered, but the agent still lacks guidance on parameter selection and how to translate the results into negative keyword decisions.

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 does not explain any of the 8 parameters. Parameter names like only_unadded and min_impressions are somewhat intuitive, but the description never clarifies their behavior, filtering logic, or how they relate to the returned data. The tool description leaves parameter understanding entirely to the schema titles and defaults.

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 defines the resource as 'real search queries that triggered your ads,' which distinguishes it from keyword-performance or suggestion tools. It also states the data content (metrics, keyword/negative status) and the primary use case (negative keyword decisions), making it easy for an agent to know exactly what this tool provides.

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

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

The description gives a strong usage context by labeling this as 'the primary source for negative keyword decisions.' However, it does not explicitly name alternative tools or state when not to use it, so the guidance is clear but lacks explicit exclusions or comparisons to siblings like keyword_performance or suggest_keywords.

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

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

Beyond the annotations (not read-only, open world), the description discloses two critical behavioral traits: the tool refuses any request to enable a network, and it can act autonomously when spend clears the policy threshold with no conversions. These are non-obvious behaviors that an agent must know before calling 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?

Two sentences with no filler. The main action is front-loaded, followed by the one-way constraint and the autonomous trigger. Every clause adds distinct value, and the structure is easy to scan.

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

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

The output schema covers return values, and the description explains the core behavior and constraints. The only minor gap is the lack of explanation for generic parameters (run_id, dry_run, rationale), but their names and defaults make them interpretable. Overall, an agent can safely invoke the tool with the information provided.

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 burden of explaining parameters. It directly ties 'Display expansion' and 'search partners' to the boolean flags search_partners and display_expansion, and clarifies that true is not allowed (enable is refused). This is essential semantic meaning absent from the schema. Generic params like run_id, dry_run, and rationale are not described, but their names and defaults are 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 opens with a specific verb and resource: 'Turn Display expansion and/or search partners OFF for a search campaign.' It precisely identifies the action and target, distinguishing it from sibling tools like pause_keywords or remove_campaign. The one-way constraint further clarifies what the tool 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 explicitly states the when-not-to-use condition: 'Can only switch networks off, never on — a request to enable one is refused.' This is a clear usage boundary, though it does not name an alternative tool for enabling networks. The context is clear but lacks explicit routing to 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 readOnlyHint=true and openWorldHint=true, the annotations already establish safety and openness. The description adds that the tool returns matches with ID, canonical name, and target type, but it does not disclose behavior for no matches, ambiguous names, or how locale/country_code affect resolution.

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

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

The description is two concise sentences that front-load the core purpose, immediately show a usage example, and summarize the return fields. No words are wasted.

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

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

The description is adequate for a read-only lookup tool and mentions the key return fields, and an output schema exists to fill in detailed structure. However, the optional locale and country_code parameters are left unexplained, leaving some ambiguity for an agent deciding whether to set them.

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 explain location_names with a concrete example and clarifies the output. However, it does not describe the locale or country_code parameters, which remain opaque given the empty 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 uses a specific verb ('Resolve') with a clear resource ('location names to numeric geo target IDs') and explains why the output is needed ('that campaign specs need'). This clearly differentiates it from siblings like suggest_keywords and geo_performance.

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

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

The description gives clear context: use this tool when you need to convert human-readable location names into numeric geo target IDs for campaign specifications. It does not explicitly name alternatives or state when not to use it, but the use case is distinct 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, covering the safety profile. The description adds useful behavioral context beyond that: the tool returns specific metrics and requires geo/language targeting for volume relevance, helping the agent understand output expectations and input sensitivity.

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

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

The description is two sentences with no filler. The main action and output are front-loaded, and the second sentence adds a necessary input prerequisite. 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?

With an output schema present and readOnly/openWorld annotations, the description covers the core inputs, output metrics, and a key prerequisite. Minor gaps like the effect of limit and include_search_partners are optional and have defaults, so the description is sufficiently complete 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 does map 'seed terms and/or a URL' to seed_keywords and seed_url, and 'geo and language IDs' to geo_target_ids and language_id. However, it leaves limit, include_search_partners, and customer_id semantically unexplained, and slightly overstates language_id as required when it actually has a 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 and resource: 'Generate keyword ideas from seed terms and/or a URL,' and specifies the returned metrics (search volume, competition, bid range). This clearly differentiates the tool from siblings like keyword_performance and keyword_volumes, which focus on existing keywords rather than generating new ideas.

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 when to use the tool: when keyword ideas are needed from seed terms or a URL. It also provides a prerequisite (geo and language IDs for relevant volumes), but it does not explicitly state when not to use it or name alternatives such as keyword_volumes for known keywords.

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