mureo

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

With no annotations provided, the description carries the full burden and largely succeeds: it discloses return ordering (severity-ordered), specific anomaly types (zero spend, CPA spike, CTR drop), gating thresholds, and the null-baseline condition. It stops short of describing every edge case (e.g., read-only behavior) but provides strong transparency.

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

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

Three dense, non-redundant sentences. The first front-loads purpose, the second lists concrete outputs and thresholds, and the third explains an edge-case condition. Every sentence earns its place; no fluff.

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

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

For a moderately complex detection tool with no output schema, the description covers core inputs, thresholds, null-baseline behavior, and return ordering. It does not specify the exact anomaly object structure, but given no output schema that is a minor, not critical, gap.

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

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

Input schema covers all four parameters with descriptions (100% coverage), so baseline is 3. The description adds valuable interpretive context: median-based baseline source, severity gating thresholds, and the default min_baseline_entries=7 behavior, which deepens understanding beyond the raw schema.

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

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

The description clearly states 'Detect anomalies for one campaign by comparing its current metrics against a median-based baseline built from STATE.json's action_log history.' This specifies a concrete verb, resource, and method, distinguishing it from general analysis siblings.

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

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

The description implies usage for single-campaign anomaly detection and mentions internal threshold conditions (e.g., 30+ conversions, 1000+ impressions), but does not explicitly instruct when to choose this tool over alternatives like google_ads_cpc_detect_trend or meta_ads_analysis_cost. No exclusions or alternative references are given.

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

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

With no annotations provided, the description carries the full transparency burden and delivers: it declares 'Read-only', explains the same-weekday median baseline to prevent weekend false positives, states the current partial day is always excluded, notes it never reads action_log, and cites STRATEGY.md guardrail thresholds with defaults. This goes well beyond a typical one-line tool description.

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

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

The description is long but information-dense and front-loaded with the core action. Every clause earns its place (baseline weekday logic, action_log independence, current-day exclusion, threshold defaults, read-only), and the final 'Read-only' is a clear safety capstone.

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 algorithm's complexity and the absence of an output schema, the description thoroughly covers input requirements, interpretation rules, and configuration sources. The one gap is the return shape — it does not describe what a result/signal looks like — but the detection semantics, platform-agnostic intent, and edge-case handling are complete enough for correct invocation.

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

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

Schema coverage is 100% with rich per-field descriptions, so the baseline is 3. The tool description adds beyond-schema value by explaining the ~30+ day row requirement, baseline algorithm, threshold parameter names/defaults, and that the current day is excluded — all helpful context for choosing and populating rows/as_of. It does not duplicate the schema's per-field semantics.

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

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

The opening 'Detect delivery collapse: campaigns whose impressions fell off a cliff while their status still says they should be serving' gives a specific verb, resource, and precise definition. It explicitly separates itself from google_ads_cost_increase_investigate ('inverse of'), making its 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 states when to use it ('scheduled detector /daily-check runs'), what input to feed ('day-grain delivery report... for ANY platform'), and names a related tool it contrasts with. It does not explicitly exclude alternative analyze/diagnose siblings or state when NOT to use it, so usage direction is strong but not 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?

With no annotations, the description carries the full burden. It transparently discloses that the tool is read-only, may return most_likely_cause=null when no cause is implicated, always reports open questions and limitations, and shares a concrete incident where every check passed yet the cause was never found. This is unusually honest and complete for 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?

The description is longer than two sentences but every sentence adds value: purpose, method, outputs, behavioral caveats, and next steps. It is front-loaded with the main action. A slightly tighter structure could be imagined, but the density is warranted for a complex diagnosis tool.

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

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

Given no output schema, the description adequately explains return values (timeline, changes, checks, cause with evidence, open questions, limitations). It also situates the tool across platforms and explains how to use follow-up evidence tools. This is complete for the tool's complexity.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds workflow context by explaining how the evidence parameter maps to elimination-ladder checks, how changes overlays delivery, and how timeline_days/change_lookback_days control the analysis window. This goes beyond pure schema definitions, justifying a 4.

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: 'Diagnose one collapsed campaign.' It clearly defines the method (overlay change feed on delivery, fold in elimination-ladder evidence) and distinguishes itself from siblings like analysis_delivery_collapse_check by focusing on diagnosis of a single campaign with a causal analysis approach.

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 after gathering elimination-ladder evidence, and calls for read-only diagnosis. It explicitly instructs to 'gather evidence with the per-platform tools it names in next_checks and call it again.' However, it does not explicitly mention when not to use it or contrast with sibling diagnostic tools like analysis_delivery_collapse_check, so it stops short of a 5.

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

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

No annotations are provided, so the description must disclose behavioral traits itself. It explains return semantics ('unknown is an honest answer and never means no impact'), the guardrail consistency of 'would_block', and the existence of 'unevaluated_rules' to surface. It also notes that the delivery_records form reaches no platform API, effectively describing side-effect profile.

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

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

The description is long but front-loaded with the core purpose in the first sentence. Each subsequent sentence earns its place by covering invocation modes, return semantics, and guardrail behavior. It is dense but not padded, though it could be slightly more concise without losing important nuance.

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

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

Despite having no output schema, the description describes key return fields ('measured', 'partial', 'unknown', 'would_block', 'unevaluated_rules') and edge cases. It covers both platform-specific and generic usage, cumulative impact, and the distinction between inert and satisfied guardrails. For a complex tool with nested objects and six parameters, this is highly 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 descriptions cover all six parameters (100% coverage), but the description adds meaning beyond the schema by explaining the two mutually exclusive parameter groups ('tool'+'arguments' vs 'excluded_entities'+'delivery_records') and clarifying the nuanced meaning of omitting 'standing_exclusions' versus passing an empty list. The mode distinction is not fully evident from the schema 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 clear, specific purpose: 'Before applying a batch of exclusions / blocks / negative keywords, report how much of the account's OWN recent delivery... it removes'. The verb 'report' plus the resource (delivery impact) and the context (before applying exclusions) distinguish it from analytic sibling tools like analysis_anomalies_check or analysis_delivery_collapse_check.

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

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

Usage context is explicit: 'Before applying a batch of exclusions...' and it contrasts the two invocation modes: with 'tool'+'arguments' for platform APIs, or with 'excluded_entities'+'delivery_records' for any other platform, noting the latter 'reaches no platform API'. It also advises to omit 'standing_exclusions' when unknown, providing clear when-to-use and when-not-to-use guidance.

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

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

With no annotations provided, the description carries the full burden and does it well. It explicitly discloses read-only behavior ('Read-only; reaches no platform API'), the shape of findings (severity, delivery_state, ad ids, evidence), the types of violations detected, the pre-flight mode behavior, default recognition of utm_* parameters, and the ads_without_readable_url fallback. No contradictions.

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 four sentences, each carrying distinct information: purpose+outputs, violation categories, read-only+API note, pre-flight usage, and parameter/edge-case behavior. It's appropriately sized for a complex tool but not as minimal as the calibrating example.

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 rich input schema descriptions and no output schema, the description still explains the return fields and covers edge cases. It could mention that comparisons never cross platforms and that ads are grouped by campaign_id, but those are already in the schema. Overall it's sufficient for an agent to decide to use it and understand what it will get.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaning by explaining that planned_ads toggles pre-flight reporting and that utm_* parameters are recognized unless the convention declares more — details not in the schema. However, most parameter behavior is already well-documented in the schema, so it doesn't need to compensate much.

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 ('Audit') and resource ('final-URL tracking parameters across ad records you pass in') plus platform scope, and enumerates what findings it returns. It clearly distinguishes itself from platform-specific list/update siblings and other analysis_* tools by focusing on tracking-parameter consistency.

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 a concrete when-to-use trigger: 'Pass planned_ads to pre-flight ads before creating them — then only the new ads are reported.' It also states the tool is read-only and reaches no platform API, implying it can be used without side effects. However, it doesn't name specific alternatives or explicitly say when NOT to use it, so it stops short of a full 5.

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

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

With no annotations provided, the description carries the full burden of disclosing behavior. It goes beyond a simple return statement by revealing the source path (./BRAND_KIT/kit.yml) and the fallback behavior (tasteful neutral defaults with 'defaults_used' set to true). This is important context that wouldn't be obvious from the schema or tool name alone.

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

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

The description is only two sentences, but every part earns its place: the first sentence states the primary purpose and contents, the second addresses the default behavior and usage context. It is front-loaded and free of any filler or redundancy.

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

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

For a zero-parameter, no-output-schema, no-annotation tool, this description is fully sufficient. It explains what is returned (the kit contents), the source, the edge case of no kit, and when to use it. There are no unresolved gaps that would leave an agent confused about how to invoke or interpret the result.

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

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

The tool has zero parameters, so the baseline is 4. The description does not need to explain parameters because there are none, and it appropriately focuses on the return value. No additional parameter-related meaning is needed.

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

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

The description clearly states the tool returns the brand kit (colours, fonts, logo path, clear-space) from a specific file, which immediately distinguishes it from sibling creative tools like compose, generate_visual, and edit_visual. The verb 'return' and resource 'brand kit' are precise, and there's no ambiguity about what is retrieved.

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 includes an explicit usage directive: 'Use this to judge brand fit before composing banners.' This gives clear context for when to invoke the tool. However, it does not mention when not to use it or suggest any alternative tools, so it falls 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?

No annotations are provided, so the description carries the burden. It reveals that the tool creates a new run directory and provenance manifest, uses headless Chromium, requires the 'creative' extra, and handles Japanese text rendering. This is meaningful side-effect and prerequisite context beyond what the schema or name provides.

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, front-loaded with the primary purpose, then key technical detail and prerequisite. No filler; each sentence adds useful context.

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 input (visual/copy/template/formats), output (PNGs in new run directory with manifest), tech behavior, and install requirement. It doesn't detail return values, but no output schema exists and the run-directory statement is sufficient for an agent to understand the result. Minor ambiguity about where the brand kit/logo comes from (no parameter) prevents 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 descriptions cover 100% of parameters, so the baseline is 3. The description reiterates the template/formats/copy parameters in prose and mentions the typography layer containing badge/logo, but adds little syntax or value beyond the schema. The badge's template-specific behavior is already noted in the schema.

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

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

The description clearly states a specific verb ('composite') and the resource transformation: ad copy + brand kit + key visual → per-format banner PNGs. It distinguishes itself from sibling tools like creative_studio_generate_visual and creative_studio_edit_visual by describing the composition/final render workflow.

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

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

The description tells the agent to pick a template and formats and pass copy, implying usage for rendering banner ads from an existing visual. However, it does not explicitly state when to prefer this over sibling tools or mention exclusions/alternatives, so guidance is mostly implied rather than explicit.

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

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

With no annotations, the description carries the full burden. It discloses important behaviors: no text is rendered, output file naming convention, validation, and return values (path, SHA-256, provider). This goes beyond minimal expectations, though it could add details about permissions or error cases.

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 dense sentences front-load the purpose and pack in essentia output details without fluff. Every phrase earns its place, from 'art-direction loop' to the file naming pattern and return values.

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 complete for a tool with 3 params and no output schema: it explains purpose, input semantics, output behavior, and return values. Missing minor aspects like error handling or prerequistites, but overall sufficient for an agent to use it correctly.

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

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

Schema covers all three parameters with descriptions, so baseline is 3. The description adds value by clarifying that the instruction describes imagery change ONLY and no text is rendered, which is not fully captured in the schema's 'What to change about the imagery'.

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

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

Clearly states the tool refines an existing key visual via an image provider's edit path, with a specific verb ('Refine') and resource. It distinguishes from sibling 'creative_studio_generate_visual' by emphasizing editing an existing visual and mentions the art-direction loop.

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

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

Provides clear context: use for fixing weak visuals in an art-direction loop, implying it's for editing after generation. However, it does not explicitly name alternative tools (like generate) or state when not to use it, so it falls short of full guidance.

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

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

With no annotations provided, the description fully carries the burden. It discloses the automatic no-text constraint, writes to a new run directory with a provenance manifest.json, and specifies return values including run id, directory, file paths with SHA-256, and manifest path. This exceeds basic expectations.

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 dense sentences convey purpose, constraints, file output, return payload, and provider behavior without any filler. The structure is front-loaded with the core action and progresses logically through output and usage details.

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

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

For a 5-parameter tool with no output schema, the description covers return values, side effects (file writing), provider behavior, and template-specific prompt modifications. It also acknowledges the typography pipeline context, making it complete for an agent to invoke correctly.

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

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

Schema coverage is 100%, with every parameter (n, aspect, prompt, provider, template) documented. The description adds emphasis on the prompt being visual-only and the template's negative-space behavior, but these are largely redundant with the schema descriptions. Baseline 3 is appropriate.

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

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

The description opens with a specific verb+resource: 'Generate text-free key-visual PNGs for an ad creative.' It clearly differentiates from siblings like creative_studio_edit_visual by noting text is added later by the typography layer, and it explains the tool's role in the pipeline.

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 (creating text-free key visuals) and describes provider selection, including the 'all' fan-out option. It does not explicitly name alternatives like creative_studio_edit_visual or creative_studio_compose, but the usage context is well-defined.

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?

Since no annotations are provided, the description fully carries the behavioral disclosure burden. It explains what each entry reports (name, configured status, capabilities, model ids), the configuration criteria (API key or codex login), and the nuanced semantics of 'edit', 'max_size', and 'supported_sizes', including the clamping behavior. This goes well beyond a simple list.

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

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

The description is dense but well-organized. It front-loads the core purpose, then details entry components, then clarifies capability field semantics, and ends with an explicit usage call. Every sentence contributes valuable information without redundancy or fluff.

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

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

Given there is no output schema and no annotations, the description provides comprehensive context: what the tool returns, how to interpret the fields, configuration requirements, and when to call it. It equips the agent to use the tool effectively and understand results without additional guessing.

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 schema provides no parameter information. The description doesn't add parameter-specific meaning (there are none), but it thoroughly explains the output structure and field semantics. Baseline for 0 params is 4, and the description meets that without exceeding into parameter territory.

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 'List the image-generation providers available to Creative Studio', a specific verb+resource statement. It clearly distinguishes this tool from sibling tools like creative_studio_generate_visual or creative_studio_edit_visual by framing it as a discovery/list operation.

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

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

Explicitly instructs 'Call this before creative_studio_generate_visual to see which providers can be selected', giving a clear when-to-use directive. It also conveys the purpose of checking provider configuration and capabilities, which helps the agent decide to invoke it appropriately.

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

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

The description explicitly states 'Read-only' and describes the output structure ('one row per accessible customer with id (10-digit), descriptive_name, currency_code, time_zone, and manager flag'). With no annotations available, this provides important behavioral insight, though it does not mention pagination, rate limits, or error cases.

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 long, front-loaded with the core purpose, followed by output details and usage guidance. Every sentence adds value with no wasted words.

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

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

For a simple read-only list tool with one optional parameter and no output schema, the description is complete: it explains what is listed, the fields returned, and how to use it in the broader session. No critical information 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 input schema already provides full coverage (100%) with a clear description of the optional customer_id parameter, including format and fallback behavior. The tool description adds no additional parameter semantics beyond reinforcing the usage context, so the baseline score of 3 is appropriate.

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

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

The description begins with a specific action and resource: 'Lists all Google Ads accounts accessible under the configured manager (MCC) account or directly under the authenticated user.' It clearly differentiates this tool from sibling tools that list campaigns, ad groups, or ads by focusing on accounts/customers and mentioning the returned fields.

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

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

It provides explicit guidance on when to use this tool: 'Use this at the start of a session to choose which customer_id to pass into subsequent calls.' It also explains the fallback behavior of other tools, helping the agent understand when this tool is needed and how it relates to the broader 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?

With no annotations, the description carries the full burden. It discloses that the operation is mutating, not automatically reversible, suggests rollback via mureo_state_action_log_append, and states the campaign status precondition. This is exemplary 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?

Three sentences, front-loaded with the main action, then returns, mutation warning, precondition, and next steps. Every sentence carries essential information with no redundancy.

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

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

For a create tool with no output schema and no annotations, the description covers creation, return values, mutation risk, rollback guidance, preconditions, and subsequent workflow. It is remarkably complete for the tool's complexity.

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

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

Schema description coverage is 100%, so parameters are already well-documented. The description does not add new parameter-level details beyond reinforcing that the parent campaign must be active, which is already implied by the campaign_id schema description. Baseline 3 is appropriate.

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

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

The description clearly states 'Creates a new ad group inside an existing campaign' with a specific verb and resource, distinguishing it from update/list siblings. It also mentions the return values, further clarifying its 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?

Provides clear context for usage: parent campaign must be ENABLED or PAUSED, and it recommends follow-up actions (add ads, keywords). However, it does not explicitly contrast with alternatives like google_ads_ad_groups_update, so a perfect score is not warranted.

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?

Declares 'Read-only' which is critical since no annotations exist. Lists exact return fields (id, name, campaign_id, status, type, cpc_bid_micros, ad_rotation_mode). Does not mention pagination or auth fallback but sufficient for basic list 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?

Three sentences with clear front-loading: main action, scoping/filter options, return fields, and usage guidance. 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?

Complete for a simple list tool: explains purpose, usage, and return schema. Lacks pagination/result limit details but that's a minor gap given no output schema and simple optional filters.

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 100% coverage with descriptions for all three optional params, so description adds little beyond restating optional scoping and status filtering. Baseline 3 is appropriate; no meaningful new param context.

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

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

Clearly states it lists ad groups with optional scoping/filtering. Differentiates from related tools by explicitly pointing to ads.list for direct fetch and create/update for needing an ID.

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 says when to use: to locate ad_group_id before create/update calls. Also says when not to: if you already have the id, fetch directly via ads.list filtered by ad_group_id.

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

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

With no annotations, the description fully discloses the tool's behavioral traits: mutating, not automatically reversible, returns updated ad group, and does not cascade. It also provides a mitigation for rollback via mureo_state_action_log_append. This goes well beyond basic expectations for an update 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?

Three sentences, each with clear purpose: action+partial update, return value+rollback advice, non-cascade guidance. No redundancy or filler. The information is front-loaded with the primary purpose then important caveats.

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

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

Given no output schema, the description notes 'Returns the updated ad group,' covering the return value. It also addresses related tools and rollback. It does not mention permission requirements or error conditions, but for an update tool with these details, it is largely complete.

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

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

Schema coverage is 100%, so each parameter already has detailed descriptions. The tool description adds semantic context about how parameters are applied (partial update, only provided fields changed), which clarifies parameter behavior globally. It could add more per-parameter details, but the schema handles the heavy lifting.

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

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

The description clearly states the tool's action: 'Updates one or more settings on an existing ad group.' It specifies the resource (ad group) and the verb (updates), and differentiates from create/list by focusing on existing ad groups and partial updates. It also distinguishes from related tools by noting it does not cascade to ads or 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?

Provides explicit usage guidance: 'Partial update — only provided fields are changed' clarifies when to use this tool for targeted modifications. It also gives clear exclusions and alternatives: 'Does not cascade to ads or keywords... use google_ads_ads_update / update_status and google_ads.keywords.* for those.' This directly tells the agent when to select a different tool.

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

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

With no annotations provided, the description carries the full burden, and it delivers: it states the tool is read-only and does not pause or rotate ads, discloses the scoring formula (ctr*cvr, or ctr when conversions=0), defines the INSUFFICIENT_DATA threshold (impressions < 100), and explains tie handling. It even spells out the return shape in detail.

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

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

The description is front-loaded with the core action, then the return shape, then verdict rules, then read-only disclosure, then sibling routing. Every sentence earns its place; the inline return-structure listing is justified because no output schema is provided.

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 analysis tool with no annotations and no output schema, the description is remarkably complete: it explains the output fields, verdict criteria, edge-case handling, side-effect absence, and alternative tools. No critical decision-relevant information is left to inference.

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

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

Schema description coverage is 100%, so the baseline is 3 and the schema already richly documents period, ad_group_id, and customer_id, including timezone caveats. The tool description adds contextual meaning about single-ad-group scoping but does not materially expand on parameter formats or defaults beyond what the schema provides.

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

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

The description opens with a specific verb and resource: 'Rank ENABLED ads within a single Google Ads ad group' and states the exact verdict vocabulary (WINNER / LOSER / INSUFFICIENT_DATA). It also names the sibling tools it is not — google_ads_ad_performance_report and google_ads_rsa_assets_analyze — which fully distinguishes it from nearby alternatives.

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?

Explicit guidance is provided: use this tool for single-ad-group ad comparison, use google_ads_ad_performance_report for cross-ad-group per-ad reporting, and use google_ads_rsa_assets_analyze for RSA asset-level splits. The scope restriction ('always scoped to one ad group') is also clearly stated.

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

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

With no annotations, the description carries behavioral disclosure burden; it states 'Read-only; no mutation', gives the exact row shape and metric names, and discloses the LAST_90_DAYS server-date timzone asymmetry. This is detailed and goes well beyond a generic statement.

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

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

The description is front-loaded with purpose and return shape, then filters and alternatives. The long period explanation is dense but every sentence earns its place; there is no fluff 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?

With no output schema and no annotations, the description provides return shape, metrics list, filter semantics, read-only guarantee, and alternative routing. An agent has enough information to select and invoke this tool correctly.

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

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

Even though schema coverage is 100%, the description adds meaning beyond the schema: the default period, gaql range syntax, timezone edge-case, filter scoping semantics with 'Omit to include every...' phrases, and customer_id fallback behavior. This adds substantial value.

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

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

States a specific verb and resource: 'Report per-ad performance across Google Ads ad_group_ad rows' and specifies the exact return shape. It also distinguishes itself from siblings by naming google_ads_ad_performance_compare for A/B comparison and google_ads_performance_report for campaign-level aggregates.

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 tells when to use this tool versus alternatives: 'For ENABLED-only A/B comparison within a single ad group with WINNER/LOSER verdicts use google_ads_ad_performance_compare; for campaign-level aggregates use google_ads_performance_report.' It also advises period selection, e.g. shorter windows for recent changes and LAST_90_DAYS for trend baselines.

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

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

With no annotations provided, the description carries the full burden for behavioral disclosure. It explicitly states 'Mutating — not automatically reversible' and mentions return values (resource_name, id, initial approval_status) along with the typical approval timeline. It stops short of detailing error scenarios or prerequisites, but the critical mutation risk is clearly disclosed.

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

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

Four sentences, each serving a distinct purpose: purpose, return info, mutation warning + rollback, and format requirements + alternative. The description is front-loaded with the primary action and contains no filler.

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

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

Given the absence of an output schema, the description compensates by naming return fields and approval status. It also covers the rollback context and differentiates from the display ad tool. It relies on the fully covered schema for parameter details, which is acceptable, though it leaves out error behavior and authentication prerequisites.

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

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

The input schema already describes 100% of parameters with rich detail, so the baseline is 3. The description repeats headline/description counts but does not add new parameter semantics beyond what the schema provides. It mentions return values, which are not parameter-related, so it does not raise the 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?

The description opens with 'Creates a Responsive Search Ad (RSA) in the specified ad group', providing a specific verb, resource, and container. It explicitly names the sibling alternative 'google_ads_ads_create_display' for display/banner ads, making the purpose 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 gives clear when-to-use guidance: it states the RSA format requirements (3–15 headlines, 2–4 descriptions), points to 'google_ads_ads_create_display' as the alternative for display ads, and advises using 'mureo_state_action_log_append' for rollback. This covers both selection and pre-call steps.

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

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

With no annotations provided, the description fully carries the burden of disclosure. It clearly states the tool is mutating and not automatically reversible, advises recording before-state for rollback, explains the automatic image upload to ImageAssets, and discloses the failure mode on channel mismatch. This gives the agent a complete safety and behavior picture.

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 five sentences, each with a distinct and necessary role: purpose, image handling, return values, mutation/rollback warning, and alternative usage. It is entirely front-loaded with the core purpose and avoids redundant filler.

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

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

Given no output schema, the description explains return values (resource_name, id, generated asset IDs). It also covers the mutation warning, rollback path, and channel requirement. For an 11-parameter create tool, this is sufficient to invoke correctly even without output schema details.

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

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

Schema description coverage is 100%, so the baseline is 3. The description does not add meaning beyond the schema for parameters; it only restates that image paths are local and uploaded automatically, which the schema already details per-field. No additional semantic value for parameters is provided.

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: 'Creates a Responsive Display Ad (RDA) in a DISPLAY campaign's ad group.' It clearly distinguishes itself from sibling google_ads_ads_create for Search campaigns, so an agent can correctly match intent.

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 tells when to use an alternative: 'For Search campaigns use google_ads_ads_create.' Also gives a hard precondition: the ad_group must belong to a DISPLAY campaign or the call fails with a channel-mismatch error, which is crucial for avoiding failed invocations.

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 explicitly states 'Read-only' and lists the returned fields (id, ad_group_id, status, type, final_urls, approval_status, creative summary), providing transparency about its behavior and output. It lacks deeper details on edge cases or pagination, but with no annotations provided, it carries the transparency burden well and does not contradict any annotations.

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

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

The description is compact and well-structured: the first sentence states the main action and optional filters, the second details the return fields, and the third provides usage context and related tools. Every sentence adds value with no redundancy or fluff.

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

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

A list tool with no output schema, but the description compensates by enumerating the returned fields and including a creative summary. It also provides usage context, relationship to sibling tools (update, policy_details), and clarifies the read-only nature. This makes it complete for an agent to select and invoke the tool correctly.

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

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

The input schema already has 100% coverage with clear descriptions for all three parameters (ad_group_id, customer_id, status_filter). The description mentions 'scoped to one ad group and/or filtered by status', which summarizes the parameters but does not add new semantic meaning beyond what the schema provides. Baseline of 3 is appropriate given full schema coverage.

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

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

The description clearly states the tool's function: 'Lists ads in a Google Ads account' with optional scoping and filtering. It distinguishes itself from siblings by explicitly referencing ads.update/update_status for ad_id lookup and pointing to policy_details for disapproval details, making it distinct from update and policy 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?

Explicit usage guidance is provided: 'Use this to find an ad_id before calling ads.update / update_status or to audit creative inventory. For disapproval details, follow up with google_ads_ads_policy_details.' This clearly indicates when to use this tool and which alternatives to choose for related tasks.

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

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

No annotations are provided, so the description carries the burden. It clearly declares 'Read-only', which is critical for side-effect awareness, and details the returned statuses and topics. However, it does not disclose error behavior (e.g., ad not found), rate limits, or required permissions. Still, the safety profile is sufficiently transparent for a read 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 are used, each earning its place. The first sentence communicates the action and output, the second provides usage guidance. No redundancy or fluff.

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

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

Given no output schema, the description compensates by listing the key return fields (approval_status, policy_topic_entries, evidence, appeal eligibility). It also provides the integration context with google_ads_ads_list. The tool is simple and the description is complete for an agent to select and invoke it correctly.

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

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

The input schema already covers 100% of parameters with clear descriptions (ad_id, ad_group_id, customer_id with fallback behavior). The description does not add any additional parameter semantics, making the schema the primary source. Baseline 3 applies because the description does not need to compensate.

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 ('Fetches') and resource ('Google Ads policy review result for a single ad'), and enumerates key return fields (approval_status, policy_topic_entries, appeal eligibility flag). It clearly distinguishes from sibling tools like google_ads_ads_list by focusing on a single ad's policy review.

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 states when to use: 'Call this after google_ads_ads_list surfaces a non-APPROVED ad'. Provides the exact trigger condition and purpose, effectively guiding the agent to the appropriate context without needing to infer.

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

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

With no annotations, the description carries full burden. It discloses major behaviors: wholesale replacement, no per-asset patch, omitted side preserved, ad replaced under same ID, learning reset, re-review, non-reversibility, and rollback suggestion. Exceptionally transparent.

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

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

Description is somewhat long but every sentence adds essential information: purpose, replacement semantics, preservation behavior, return value, side effects, rollback advice, and alternative tool. No redundancy or filler.

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

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

For a mutation tool with no annotations and no output schema, the description is exceptionally complete. It covers what the tool does, how it behaves, side effects, reversibility, and when to use alternatives. The only missing pieces are already covered by schema 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 coverage is 100%, so baseline is 3. The description adds key semantic value by explaining that supplied side is fully replaced and omitted side preserved, which is critical for correct use of headlines/descriptions parameters. It also clarifies fallback behavior for customer_id via schema, but description reinforces it.

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

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

The description clearly states it updates creative copy of an RSA by replacing headlines/descriptions. It explicitly distinguishes from google_ads_ads_update_status for status-only changes, avoiding confusion with sibling tools.

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

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

Provides explicit when-to-use guidance: creative copy updates, with full side replacement semantics. Names the alternative google_ads_ads_update_status for pause/resume and recommends mureo_state_action_log_append for rollback, covering both usage and exclusions.

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

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

With no annotations provided, the description carries the full burden of disclosing side effects and behavior. It says 'Lightweight — writes only the status field and does not reset learning signals,' 'Returns the ad ID and new status,' and 'Reversible via rollback_apply.' These details go beyond the schema and give critical context about the tool's impact and reversibility.

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 concise sentences, front-loaded with the core purpose and followed by key behavioral notes and usage guidance. Every sentence serves a purpose with no redundancy or filler. Ideal length for this tool.

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

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

The tool is a simple status update with four well-documented parameters and no output schema. The description covers purpose, side effects, return value, and alternative tool usage, making it complete for an agent to select and invoke correctly. No gaps are apparent.

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

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

Schema description coverage is 100%, so parameters are fully described in the input schema. The description adds no extra parameter information beyond what the schema provides (e.g., it doesn't elaborate on customer_id or ad_group_id). Baseline of 3 is appropriate since the schema does the heavy lifting.

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

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

The description opens with a specific verb and resource: 'Sets the delivery status of a single ad to ENABLED, PAUSED, or REMOVED.' This clearly states the tool's function and enumerates valid values, making it distinct from siblings like google_ads_ads_update, which is explicitly differentiated later.

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

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

The description provides direct usage guidance: 'Use this for pause/resume; use google_ads_ads_update to change the creative copy itself.' This explicitly tells when to choose this tool over an alternative, satisfying the dimension fully.

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

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

With no annotations provided, the description fully carries behavioral disclosure. It clearly states read-only behavior, per-link entry semantics, lack of deduplication, API ordering, which field types are omitted, and the meaning of link status values. This is exemplary transparency for a list tool.

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

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

The description is long but densely informative; every sentence provides distinct value including return fields, conditional payloads, deduplication behavior, exclusions, and sibling tool references. It is front-loaded with the core purpose and then systematically adds necessary detail.

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

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

For a tool with no output schema, the description compensates by fully enumerating returned fields, conditional fields based on field_type, screenshot URL semantics, ordering, deduplication, omissions, and related write tools. The parameter guidance and alternative tool comparisons make it contextually complete.

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

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

Schema coverage is 100%, so parameters are already fully documented in the input schema. The description adds filter-related context (restrict by campaign or asset group) but does not need to repeat the schema details. Baseline 3 is appropriate.

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

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

The description opens with a precise verb and resource: "Lists the text AND the images attached to Performance Max asset groups." It further distinguishes itself from sibling tools by explaining that google_ads_ads_list returns no rows for P-MAX and that this tool uniquely identifies which asset group serves a given image.

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

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

Usage context is explicitly stated: it is the tool for P-MAX creative, with direct exclusions for google_ads_ads_list and google_ads_image_assets_list. It also gives forward guidance, telling users to pass asset_id to the replacement tools for modifications.

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

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

With no annotations, the description takes full responsibility for behavioral disclosure. It details that the operation is atomic (all three steps in one mutate), creates a new asset, removes the old link without deleting the asset, is not reversible, and returns a specific structure. It also mentions the duplicate-link rejection behavior, providing comprehensive transparency about side effects and constraints.

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?

Although the description is longer than typical, every sentence delivers critical information: atomicity, the NOT_ENOUGH_* error context, old asset non-deletion, return format, irreversibility, and the prerequisite list call. No fluff or redundancy; it is efficiently front-loaded with the core action.

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

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

For a complex mutating tool with no annotations and no output schema, the description covers all necessary context: the atomic multi-step operation, the reason for atomicity (minimum asset count), the return structure, the irreversibility and rollback guidance, and the required precursor step. It is fully sufficient for an agent to understand and execute the tool correctly.

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

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

Schema coverage is 100% and every parameter has a description, but the tool description adds extra meaning beyond the schema: new_text's display-width limits and duplicate-text rejection, field_type's note that the same asset can be linked under multiple field types, and old_asset_id's validation rule. This enhances understanding beyond the basic schema definitions.

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

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

The description states a specific verb+resource: 'Swaps one headline, long headline or description of a Performance Max asset group for new text. Mutating.' It clearly identifies the operation and distinguishes it from sibling tools like google_ads_asset_group_images_replace (images vs. text) and google_ads_asset_group_assets_list (read vs. write).

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 instructs calling google_ads_asset_group_assets_list first to obtain old_asset_id, and explains that removing an asset on its own fails with NOT_ENOUGH_* errors, implying this replace tool is the correct approach to maintain minimum asset counts. It also advises recording before-state with mureo_state_action_log_append for rollback, giving clear context for when and how to use this tool.

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

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

With no annotations provided, the description carries the full burden and excels. It discloses that the operation is mutating, atomic ('in ONE atomic GoogleAdsService.mutate'), does not delete assets, enforces shape constraints with specific dimensions, and is not automatically reversible. It even explains the error case with NOT_ENOUGH_MARKETING_IMAGE_ASSET and notes it never crops or resizes.

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

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

The description is long but every sentence adds value: it fronts the purpose, then logically flows through usage, atomicity, asset shape rules, return value, rollback caveat, and alternatives. There is no filler or repetition; it is densely informative without being bloated.

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

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

Given the tool's complexity (7 parameters, no output schema, mutating behavior), the description is exceptionally complete. It details return structure, error behavior, prerequisites, shape enforcement, and rollback recommendations. It covers all aspects an agent needs to invoke the tool correctly and interpret results.

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

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

Although schema coverage is 100%, the description adds significant semantics beyond the schema: it clarifies the mutual exclusivity of new_asset_id and new_image_path, explains rejection conditions ('Rejected if it is not an image asset, if its dimensions do not fit this field_type, or if it is already linked'), and specifies dimension checks before upload. This goes well beyond the schema's raw definitions.

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

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

The description opens with a clear, specific verb-resource pairing: 'Swaps one image or logo of a Performance Max asset group for another.' It distinguishes itself from the sibling tool google_ads_asset_group_assets_replace by explicitly stating 'For headlines and descriptions use google_ads_asset_group_assets_replace instead.' This fully differentiates the 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 provides explicit when-to-use guidance: 'Use this whichever situation you are in: pass new_asset_id when the account already holds the image... or new_image_path to upload a local file first' and mandates a prerequisite: 'Call google_ads_asset_group_assets_list first to get old_asset_id.' It also states when not to use (for headlines/descriptions) and references rollback via mureo_state_action_log_append.

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

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

With no annotations present, the description fully carries the behavioral transparency burden. It discloses the mutating nature ('creates a new Asset row'), the lack of a delete tool, validation limits (5 MB, file extensions), the side effect of reading from local filesystem and POSTing bytes, and the exact return shape. This is comprehensive and goes well beyond minimal expectations.

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

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

The description is well-structured and front-loaded with the core purpose. Each sentence adds distinct value: return values, mutation caveat, validation, side effects, and follow-up tool. Despite being somewhat long, there is no wasted or redundant content.

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

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

The tool has moderate complexity (file upload, validation, mutation, no deletion, local filesystem read) and no output schema. The description covers return values, side effects, constraints, and the next step to take. This is a complete picture for an agent to select and invoke the tool correctly.

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

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

The input schema already provides descriptive text for all three parameters (100% coverage), so the baseline is 3. The description adds meaningful context beyond the schema by explaining the return format, default behavior for `name` (basename), and the credential fallback for `customer_id`. This elevation to 4 is warranted.

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 ('Upload') with a clear resource ('local image file to Google Ads as an image Asset') and states its intended use ('for use in Responsive Display Ads or image extensions'). It is easily distinguished from sibling tools like google_ads_image_assets_list (listing) or meta_ads_creatives_upload_image (Meta platform).

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

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

The description provides clear contextual guidance: it notes the asset is for RDA/image extensions and directs the user to google_ads_ads_create_display for the next step. It doesn't explicitly state when not to use this tool versus other upload tools, but the mention of the no-delete limitation and the recommended follow-up gives practical usage direction.

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

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

With no annotations provided, the description carries the full burden and does so thoroughly. It explicitly states the tool is read-only, describes the exact return structure including nullable values, lists the insight thresholds, and discloses the Google Ads API v23 limitation regarding competitor-level auction insight data.

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

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

The description is front-loaded with the tool's core purpose and return shape, then adds thresholds, read-only status, an API limitation note, and the alternative tool. Every sentence adds distinct value; 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 tool has no output schema, yet the description fully defines the returned object, its fields, types, thresholds, and the note about missing competitor data. Combined with the rich parameter descriptions in the schema, an agent has everything needed to select and invoke this tool correctly.

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

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

The schema already documents all three parameters with 100% coverage, including detailed guidance on period constants and explicit ranges. The description adds little parameter-specific meaning beyond that, but it does not need to because the schema carries the load.

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 ('Interpret') and a clear resource ('a campaign's impression-share metrics'), then states it surfaces human-readable insights about competitive position. It also distinguishes itself from the sibling google_ads_auction_insights_get by explicitly saying that tool returns raw metrics without insights.

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 routing guidance: use google_ads_auction_insights_get for raw metrics without insights, and notes full competitor data is only available in the Google Ads UI. It also names the exact conditions under which insights fire, so an agent knows when this tool is appropriate.

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

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

No annotations are provided, so the description carries the full burden — and it delivers: exact return shape (single-entry list, field names, 0-100 float percentages rounded to 1 decimal or None), an error contract with enumerated codes ('auction_insights_unavailable'|'no_data', reason, hint), an explicit 'Read-only' declaration, and the v23 API caveat that competitor-level auction_insight is no longer returned. This prevents an agent from expecting competitor fields that no longer exist.

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 the opening sentence, and every subsequent clause earns its place: return contract, error contract, read-only flag, API-version limitation, and sibling routing. Despite covering substantial ground, 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?

With no output schema and no annotations, the description carries the full burden of explaining return values and safety — and it does: field types, error variants, read-only behavior, and the version limitation are all stated, while the schema fully documents parameters. Nothing an agent needs to call or parse the tool 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 100% and the schema itself is exceptionally rich (period window guidance, GAQL range syntax, the LAST_90_DAYS timezone-asymmetry warning, campaign_id source, customer_id fallback). The description adds no parameter detail beyond 'one Google Ads campaign,' which is fine — at 100% coverage the schema does the heavy lifting and the baseline of 3 applies.

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+scope: 'Fetch raw impression-share metrics for one Google Ads campaign.' The word 'raw' plus the final sentence routing to google_ads_auction_insights_analyze differentiates it from the human-readable sibling, and the enumerated return fields make the tool's purpose 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?

Explicitly names the alternative google_ads_auction_insights_analyze and the condition that selects it ('a version with human-readable insights layered on top'). It also frames this tool as the raw-data, single-campaign counterpart, so an agent can reliably choose between the two siblings without opening either schema.

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

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

With no annotations provided, the description carries the full burden and explicitly states 'Read-only,' which is a key behavioral trait. It also discloses the output shape (one entry per criterion, including fields and type enum values) and the 1000-criteria cap. It could add more about auth requirements or pagination behavior, but the current disclosure is strong for a list tool.

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

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

The description is dense but every sentence earns its place: it defines the resource, enumerates audience types, gives the return shape with an example, states read-only status, provides a concrete use case, and explains scoping. It is front-loaded with the action and remains information-rich without fluff.

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

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

There is no output schema, so the description compensates well by including the exact returned fields and value format (e.g., 'customers/1/userLists/42'). It covers the read-only nature, scoping, and cap. Minor omissions like pagination details or error behavior prevent a perfect score, but given the tool's list-only purpose, this is quite complete.

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

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

Schema coverage is 100% with per-parameter descriptions, so the baseline is 3. The description adds valuable semantics by explaining the optionality and behavior of omitting both ad_group_id and campaign_id: 'omit both for the whole account (capped at 1000 criteria).' This enriches the parameter guidance beyond the schema.

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

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

The description opens with a specific verb and resource: 'Lists audience-type criteria attached to ad groups,' and enumerates the exact types of audiences covered (user interests, remarketing, custom audiences, etc.). This clearly differentiates it from sibling targeting-list tools like google_ads_location_targeting_list or google_ads_demographic_targeting_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 provides explicit usage guidance: 'Use this to audit which audience segments an ad group targets or excludes before proposing targeting changes.' It also explains how to scope results (by ad_group_id and/or campaign_id, or omit for whole account). It does not explicitly name alternative tools for non-audience targeting, so it stops short of a 5.

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

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

Annotations are absent, so the description carries full burden. It states 'Read-only' and details the return structure, including the exact shape and quirks like device_type being 'UNKNOWN(<n>)' for non-DEVICE rows. This goes beyond basic safety to explain behavior.

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

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

The description is front-loaded with the core action, followed by a compact return type specification and two short alternative pointers. Every sentence contributes useful information without redundancy.

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

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

With no output schema, the description fully explains the returned objects, including enum values and edge cases. It covers alternatives, read-only nature, and scope, making it complete for an agent to select and invoke the tool correctly.

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

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

Schema coverage is 100%, with both parameters having detailed descriptions (e.g., campaign_id format and fallback behavior for customer_id). The tool description adds no extra parameter-level insight, so the baseline of 3 applies.

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 starts with a specific verb and resource: 'List every campaign_criterion row that has a non-null bid_modifier on a Google Ads campaign.' It clearly distinguishes from siblings by naming alternatives for device-summary and location-only views.

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?

Explicit 'when to use' guidance is provided: 'For the device-summary view... use google_ads_device_targeting_get. For location-only use google_ads_location_targeting_list.' This gives clear exclusions and alternatives.

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

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

No annotations are provided, so the description carries the full burden. It discloses the mutating nature, FieldMask-based partial update (only bid_modifier), preservation of other fields, reversibility, ValueError on out-of-range values, and the return value.

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

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

The description is four sentences, each carrying essential information: action, return value, mutating behavior, constraints, and sibling distinction. It is front-loaded and avoids unnecessary filler.

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

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

Despite lacking annotations and output schema, the description fully covers what the tool does, its side effects, validation constraints, error behavior, and the key sibling alternative. This is enough for an agent to invoke it correctly.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds useful context about the bid_modifier range and 0.0 rejection, but this mostly mirrors the schema's own parameter descriptions rather than adding new semantics.

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

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

The description opens with 'Update the bid_modifier of a single campaign_criterion,' giving a specific verb and resource. It also distinguishes this tool from google_ads_device_targeting_set by explicitly rejecting bid_modifier 0.0 and directing users to that sibling tool.

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

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

It explicitly names an alternative for device toggling: 'To toggle a device on/off with bid_modifier 0.0 use google_ads_device_targeting_set instead (this tool rejects 0.0).' This provides clear when-to-use and when-not-to-use guidance.

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

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

With no annotations provided, the description carries the full transparency burden. It fully discharges it by declaring the tool read-only, detailing every trigger threshold (e.g., Mobile CPA > Desktop CPA * 1.3, informational patterns > 20%), and specifying the exact output structure. This is far beyond what the input schema alone would 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 densely packed but every sentence earns its place: purpose, return contract, trigger logic, read-only status, and routing to the alternative. It is front-loaded with the core action and avoids filler or repetition of schema content.

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

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

Because there is no output schema, the description fully specifies the return value, including nested suggestion fields, categories, and priorities. The threshold logic for all three checks is also included, so an agent can invoke the tool and interpret its results without additional lookups. Nothing material 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 100%, so the schema already thoroughly documents campaign_id, customer_id, and the period parameter. The description itself does not add parameter-level semantics beyond referencing campaign_id in the return shape. Baseline 3 is appropriate because the schema does the heavy lifting.

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

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

The description uses a specific verb ('Run'), names the resource ('Google Ads campaign'), and enumerates exactly three checks: ad schedule, device CPA disparity, and informational-query ratio. It also states the return shape and explicitly names google_ads_performance_analyze as the general alternative, so it is clearly distinguishable from 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?

It gives an explicit condition for use: 'Use this when the advertiser self-identifies as B2B.' It also names the alternative for other cases: 'For general campaign diagnosis use google_ads_performance_analyze.' This is direct, actionable routing guidance with no ambiguity.

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

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

With no annotations, the description carries the full burden. It discloses that the operation is mutating and not automatically reversible, advises using mureo_state_action_log_append for rollback, and reveals the immutability of the period field. This goes beyond the schema and provides critical behavioral context.

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

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

The description is detailed and well-structured, covering purpose, return values, mutation warning, usage flow, and constraints. While it is longer than minimal, every sentence provides necessary information. The logical progression from purpose to alternatives to parameter usage is clear.

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

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

Given the tool's complexity (6 parameters, no output schema, no annotations), the description is remarkably complete. It covers all key aspects: purpose, return values, mutation side effects, best practices, alternative tools, and parameter selection. The absence of an output schema is compensated by explicitly stating what is returned.

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?

Since schema coverage is 100%, the baseline is 3. The description adds semantic value by explaining the relationship between period, amount, total_amount, and total_amount_micros, and clarifying when to use CUSTOM_PERIOD vs daily amounts. It does not introduce new parameter syntax but enhances practical understanding.

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

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

The description clearly states the tool's function with a specific verb and resource: 'Creates a new campaign budget that can be attached to one or more campaigns.' It also explicitly differentiates from sibling tools by naming google_ads_budget_update as the alternative for editing existing budgets, and mentions the return of id and resource_name.

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

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

The description provides explicit usage guidance: when to use this tool (creating new budgets), when not to (editing existing budgets, directing to google_ads_budget_update), and a typical flow (budget.create → campaigns.create). It also explains the specific use case for CUSTOM_PERIOD with total amount vs daily amount.

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

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

No annotations are present, so the description carries the full burden. It discloses that the operation is read-only, that per-campaign data comes from get_performance_report, and that individual failures are silently treated as zero — a critical failure-mode detail. It also documents verdict thresholds and the special cost==0 case, giving the agent accurate expectations for the tool's behavior.

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

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

The description is dense but every sentence earns its place: scope, return structure, thresholds, data source, failure behavior, read-only status, and sibling routing. The output contract is packed into a compact structured form rather than padded prose, keeping the description informative without waste.

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

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

Despite having no output schema, the description fully documents the return shape: top-level totals, per-campaign fields, efficiency ratio formula, verdict thresholds, recommendations, and insights. It also covers failure handling and reference to the source report, leaving no critical ambiguity for an agent deciding whether and how to invoke the tool.

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

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

Schema description coverage is 100%, so the baseline is 3. Both parameters are thoroughly documented in the schema: period has enum values, default, guidance on window selection, custom range syntax, and timezone caveats; customer_id explains the fallback behavior. The tool description itself adds no additional parameter semantics beyond the response shape, which is acceptable given the schema's completeness.

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

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

The description opens with a specific verb and resource: 'Score budget allocation efficiency across every ENABLED Google Ads campaign,' which clearly states what the tool computes and over what scope. It distinguishes this from sibling tools by naming the alternatives for reallocation plans and single-budget updates.

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 it versus alternatives: 'For a concrete DECREASE/INCREASE reallocation plan use google_ads_budget_reallocation; to change a single budget use google_ads_budget_update.' It also frames the tool as read-only, giving the agent clear selection guidance. This is exemplary usage routing.

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

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

Even though annotations are absent, the description explicitly says 'Read-only' and discloses important nuances like shared budgets and that total_budget is null unless CUSTOM_PERIOD. This fully offsets the lack of annotations.

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

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

The description is two sentences but packed with value: first defines the action and lists return fields, second gives a safety warning. No fluff, front-loaded with the core purpose.

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

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

With no output schema, the description fully enumerates return fields and edge cases (null total_budget, shared budgets). It also supplies the read-only safety context and a pointer to the update tool, making it self-sufficient for a get operation.

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

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

Schema description coverage is 100%, with both parameters already explained (including customer_id fallback). The description adds no further parameter-level detail, so the baseline of 3 is appropriate.

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

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

The description opens with a specific verb and resource: 'Fetches the campaign-budget record attached to a campaign.' It clearly distinguishes from sibling tools like google_ads_budget_update and google_ads_budget_create by focusing on retrieval.

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

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

The description provides a clear usage context by advising to check reference_count before calling google_ads_budget_update, implying this tool is for pre-update verification. It doesn't explicitly state when not to use it or name alternatives, but the context is sufficient.

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

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

With no annotations provided, the description carries the full burden — and it excels. It discloses read-only behavior, short-circuit response when no spend, omitted total_freed key, the 100-unit minimum reduction rule, and fallback to 0 when get_budget fails. These are exactly the behavioral quirks an agent needs to know.

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

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

The description is dense but every sentence earns its place: core behavior, return shape, edge-case short-circuit, skip rule, data-source fallback, read-only status, and sibling routing. Nothing is redundant, and the most important information is front-loaded.

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

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

For a tool with no annotations and no output schema, this description is remarkably complete. It covers return structure, omitted keys, failure fallbacks, minimum thresholds, and sibling distinctions. An agent has enough context to invoke it safely and parse its response defensively.

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

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

Schema coverage is 100%, so the schema already fully documents both parameters with detailed descriptions. The tool description adds no additional parameter-level meaning beyond what the schema provides, so the baseline of 3 applies.

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 ('Propose'), a specific resource ('budget reallocation plan'), and the exact algorithm (cut up to 20% from inefficient campaigns, distribute equally across efficient ones). It clearly differentiates itself from siblings by naming google_ads_budget_update and google_ads_budget_efficiency.

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 not to use it: 'To actually apply a change use google_ads_budget_update; for the efficiency scoring alone use google_ads_budget_efficiency.' This gives an agent clear routing guidance and distinguishes the planning-only behavior from execution and scoring tools.

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

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

With no annotations provided, the description fully carries the behavioral disclosure burden. It explicitly warns that the operation is mutating and not automatically reversible, explains that shared budgets affect all campaigns, reveals the currency-unit (not micros) gotcha, and notes the immutable period constraint. This goes well beyond a bare 'update' statement.

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?

Although the description is longer than average, every sentence conveys essential operational detail: the action, mutability warning, return value, shared-budget side effect, unit clarification, and API period limitation. There is no filler or redundant explanation beyond critical safety-relevant facts.

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 lack of annotations and output schema, the description is remarkably complete. It explains the return value, side effects, required pre-checks, and API constraints. For a mutating tool with six parameters and multiple edge cases (shared budgets, period types, micros vs. currency), this description leaves little ambiguity for an 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?

The input schema already provides 100% parameter coverage, including currency units, mutual exclusivity, and CUSTOM_PERIOD restrictions. The description adds no new parameter-specific meaning beyond echoing key points (e.g., amount not in micros), so the baseline of 3 applies.

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: 'Sets the daily and/or total amount on an existing campaign budget.' This clearly distinguishes it from budget creation (google_ads_budget_create) and retrieval (google_ads_budget_get) by emphasizing 'existing' and enumerating the exact update targets.

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 when-to-use and preconditions: checking reference_count with google_ads_budget_get before modifying shared budgets, and recording prior state with mureo_state_action_log_append if rollback may be needed. It also states a hard constraint—total amounts only apply to CUSTOM_PERIOD budgets—providing a clear when-not.

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

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

With no annotations provided, the description carries full responsibility and excels: it discloses the two-step mutate, return value/error structure, reversibility, duplicate asset creation on identical text, and the campaign limit. This is comprehensive behavioral disclosure beyond any structured data.

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, stating the core action first, then return behavior, error case, reversibility, duplicate caveat, and alternative tool. Every sentence is informative and earns its place, with no redundancy.

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

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

Given no output schema, the description adequately explains return values (resource_name, error object) and covers all necessary operational details: mutation, limits, duplicates, and alternatives. It is fully complete for an agent to invoke the tool correctly.

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

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

Schema coverage is 100%, with all parameters fully described in the input schema. The description adds no additional parameter-level meaning, so the baseline of 3 is appropriate. It does enrich context about duplicates/limits, but that is behavioral, not parameter semantics.

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

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

The description clearly states the tool's action ('Create a callout Asset and link it to a Google Ads campaign') with a specific verb and resource. It also distinguishes itself from sitelink creation by naming the alternative tool, making the purpose 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 provides explicit guidance on when to use this tool versus alternatives ('For sitelink variants use google_ads_sitelinks_create'), notes reversibility via google_ads_callouts_remove, and highlights the 20-callout limit as a constraint. This gives the agent clear decision-making 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?

With no annotations provided, the description carries the full disclosure burden. It states the tool is 'Read-only,' notes that it only scans campaign_asset rows (no account-level merge), and reveals a hardcoded limit of 20 callouts per campaign. These are meaningful behavioral traits beyond basic read/write classification.

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 succinct sentences with no filler. It front-loads the core action and return format, then adds differentiation and usage guidance efficiently. 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?

Despite no output schema, the description specifies the exact return format ([{id, resource_name, callout_text}]). It also includes operational context (read-only, audit before create/remove, hardcoded limit) and sibling differentiation. This is complete for a straightforward list tool.

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

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

Schema description coverage is 100%: campaign_id is described as a numeric string without dashes and obtainable via google_ads_campaigns_list, and customer_id includes fallback behavior. The description adds no extra parameter meaning beyond the schema, so the baseline of 3 is appropriate.

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

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

The description opens with a specific verb+resource: 'List callout extension assets linked to a Google Ads campaign.' It also distinguishes itself from the sibling tool google_ads_sitelinks_list by clarifying that it only scans campaign_asset rows without account-level merge, making its scope 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 states when to use this tool: 'Use this to audit coverage before calling google_ads_callouts_create or google_ads_callouts_remove.' It also contrasts with google_ads_sitelinks_list, giving clear guidance on when this tool is appropriate versus 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?

With no annotations provided, the description carries full burden. It explicitly states the destructive nature: 'Destructive — the callout stops serving on the campaign but the Asset row itself is not deleted.' It also mentions the return value and the re-enabling path, providing substantial 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?

Four sentences, each earning its place: action, return value, destruction semantics, and sibling guidance. Front-loaded with the action verb, no fluff or redundancy.

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

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

For a removal tool with no output schema and moderate parameter count, the description covers the action, effect, re-enabling, and sibling alternative. The return format is disclosed. It is complete for an agent to select and invoke correctly.

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

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

Schema description coverage is 100%, with each parameter already described (source, format, fallback). The description itself adds no parameter-specific detail beyond the notion of a CampaignAsset link, so the baseline of 3 is appropriate.

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

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

The description opens with a specific verb and resource: 'Detach a callout asset from a Google Ads campaign by removing the CampaignAsset link.' This clearly distinguishes it from sibling tools like google_ads_callouts_list and google_ads_callouts_create. The return value ({resource_name}) is also stated.

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 points to the sibling list operation ('For the sibling list operation use google_ads_callouts_list') and notes re-enabling requires the create tool. It implies when to use this tool (when detaching a callout) but does not give an explicit when-not-to-use beyond the list 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?

With no annotations, the description carries the full transparency burden. It discloses that the tool is mutating, counts against daily write quota, is not automatically reversible, and returns resource_name and id. This goes well beyond a bare 'creates campaign' statement.

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

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

Every sentence earns its place: action and return, mutation warning, quota, non-reversibility, rollback pointer, prerequisite, and follow-up alternatives. The description is front-loaded with the core purpose and contains no filler or redundancy.

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

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

For a create tool with a rich schema and no output schema, the description fully covers return shape, preconditions, side effects, and subsequent actions. It addresses the key operational concerns (quota, reversibility, budget creation, later edits) and leaves no significant gaps.

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

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

Input schema coverage is 100% with detailed descriptions and enums, so the baseline is 3. The description adds the prerequisite relationship for budget_id and mentions channel types, but otherwise duplicates the schema's parameter documentation. No significant extra parameter semantics are added.

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 'Creates a new Search or Display campaign' – a specific verb, resource, and scope. It clearly distinguishes itself from update/status siblings and from ad group creation tools, and even names the update tools for later edits.

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 states the budget_id prerequisite and directs users to google_ads_budget_create if missing. It also gives explicit alternatives for later edits (google_ads_campaigns_update or google_ads_campaigns_update_status) and advises recording before-state via mureo_state_action_log_append for rollback, which is clear when-to/not-to guidance.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states 'Read-only — does not change anything,' which is a clear safety guarantee. It further describes the return behavior: an ordered list of issues drawn from specific status fields, with examples of issue types and the format of each item (plain-language description and remediation hint). This provides meaningful transparency about both side effects and output semantics, though it does not discuss error handling or rate limits. Given the absence of annotations, this is a solid 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?

The description is three sentences long and each sentence earns its place: the first states the purpose and output, the second guarantees read-only behavior, and the third gives usage guidance. It is front-loaded with the core purpose, includes concrete examples, and contains zero filler or redundancy. This is a model of concise yet informative writing.

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 this is a diagnostic tool with no output schema, the description provides a remarkably complete picture: what it does, what it returns (ordered issues with descriptions and hints), the data sources (serving_status, primary_status, primary_status_reasons), safety (read-only), and usage context (before raw reports). It does not mention error conditions or ordering criteria explicitly, but for a single-campaign diagnostic with no output schema, the description is nearly sufficient. The only minor gap is the lack of explicit alternative tool references, but this is covered under usage guidelines.

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

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

Schema description coverage is 100%, with both campaign_id and customer_id having explicit descriptions in the schema. The description itself does not add any parameter-specific details beyond the schema—it refers to 'a campaign' but does not elaborate on the customer_id fallback behavior, which is already covered by the schema. Since the schema handles the parameter semantics, this is a baseline 3 for a high-coverage scenario.

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

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

The description clearly states the tool's function: 'Explains why a campaign is not serving or is under-delivering.' It goes beyond a vague verb by specifying the resource type (campaign) and the specific diagnostic angle (serving/under-delivery), and it distinguishes itself from raw reporting tools by framing its output as an ordered list of actionable issues. This is a specific verb+resource+scope, strongly differentiated from siblings like google_ads_campaigns_get or google_ads_performance_report.

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 when-to-use guidance: 'Use this before pulling raw performance reports; it narrows the problem space.' This establishes a clear context and prioritization relative to performance reporting. It does not explicitly name alternative diagnostic tools (e.g., google_ads_health_check_all) or give when-not-to-use scenarios, but the provided context is sufficiently actionable. This fits 'clear context, no exclusions' rather than a full alternative analysis.

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?

Even though no annotations are provided, the description explicitly states 'Read-only' and explains the return field set relative to campaigns.list. It doesn't detail error behavior or rate limits, but for a read-only get operation, this is adequate 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?

The description is three sentences with no wasted words. It front-loads the main purpose, adds return field details, and closes with usage guidance. Every sentence earns its place.

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

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

For a simple get tool with no output schema, the description is fairly complete. It specifies the additional fields over campaigns.list, notes read-only behavior, and gives usage context. Minor gap: it doesn't list all fields from campaigns.list, but leveraging sibling knowledge 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?

Schema coverage is 100%, with both parameters already fully described. The description repeats some of that information (e.g., campaign_id from campaigns.list, customer_id fallback) but doesn't add significant new meaning beyond what the schema provides. Baseline 3 is appropriate.

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

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

The description clearly states the tool's function with a specific verb and resource: 'Fetches the full detail record for a single campaign by ID.' It also distinguishes itself from sibling tools by listing additional fields returned and explicitly contrasting with google_ads_campaigns_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 provides explicit usage guidance: 'Use this when you already have a campaign_id; for discovery use google_ads_campaigns_list.' This clearly indicates when to use this tool vs the 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?

No annotations are provided, so the description must disclose behavior. It explicitly states 'Read-only' and describes the row-per-campaign return format including the specific fields returned. While it doesn't mention pagination or rate limits, the read-only nature and return shape are well covered.

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

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

Three sentences: first states the action, second describes output and read-only nature, third provides usage and alternative tool. Every sentence adds value, and the structure is front-loaded with the core purpose.

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

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

For a simple list tool, the description is complete: it covers what it returns, when to use it, the read-only aspect, and the alternative for single-campaign details. The schema provides parameter details, and no output schema is needed since the return fields are enumerated 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 input schema fully documents both parameters with descriptions and enums (100% coverage). The description adds no extra parameter information beyond referencing 'optional status filtering', so a baseline score of 3 is appropriate since the schema does the heavy lifting.

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

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

The description clearly states the tool lists campaigns in a Google Ads account with optional status filtering, distinguishing it from the sibling google_ads_campaigns_get which returns full details for a single campaign. It also specifies the exact output shape (id, name, status, etc.), making the purpose 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?

Explicitly says to use this tool to audit account structure or find a campaign_id before calling campaigns.get/update/update_status, and directs users to google_ads_campaigns_get for single-campaign details. This provides clear when-to-use and alternative guidance.

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

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

With no annotations, the description carries the burden and discloses that the operation is mutating and not automatically reversible, and suggests recording before-state for rollback. However, it does not detail required permissions or other side effects, so not 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?

Three sentences with no fluff. Each sentence adds unique value: action, partial update behavior, mutability warning, and alternative tool recommendation. 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?

Given 4 parameters, no output schema, and no annotations, the description sufficiently covers return value, partial update behavior, rollback guidance, and alternative usage. It is complete enough for an agent to select and invoke correctly.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds valuable partial-update semantics—only fields provided are changed, omitted fields are preserved—which clarifies how all parameters behave beyond schema descriptions.

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

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

The description clearly states 'Updates one or more settings on an existing campaign' with a specific verb and resource. It also differentiates from the sibling tool by explicitly noting that status-only changes should use google_ads_campaigns_update_status instead.

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 usage guidance: for status-only changes, prefer the lighter-weight google_ads_campaigns_update_status. Also explains partial update semantics, giving the agent context on when to use this tool versus alternatives.

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

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

No annotations are provided, so the description carries the full disclosure burden. It fully covers behavioral traits: writes only the status field, returns the campaign ID and new status, supports rollback for ENABLED ↔ PAUSED, and explains that REMOVED is a soft delete reversible within 30 days. This gives an agent clear expectations of side effects and reversibility.

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 four sentences, each earning its place: function, scope/return, reversibility, and usage guidance. It is well-structured and free of redundant information.

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

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

Given the tool's simplicity, no output schema, and no annotations, the description provides all necessary context: what it does, what it returns, how it can be reversed, and when to use it. It is complete for an agent to select and invoke the tool correctly.

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

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

Schema description coverage is 100%, so the structured parameter descriptions already handle parameter semantics. The description adds context that only the status field is written, but it does not elaborate on campaign_id or customer_id beyond what the schema provides. Baseline 3 is appropriate since the schema does the heavy lifting.

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

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

The description explicitly states the tool's function: 'Sets the delivery status of a single campaign to ENABLED, PAUSED, or REMOVED.' It clearly identifies the resource (campaign status) and the allowed actions, and it distinguishes this tool from siblings by contrasting it with google_ads_campaigns_update, which handles other settings.

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 includes direct usage guidance: 'Use this for pause/resume; use google_ads_campaigns_update to change name, bidding, or other settings.' It also mentions the lightweight scope ('writes only the status field') and reversibility considerations, making it easy for an agent to decide when to choose this tool over alternatives.

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

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

No annotations are provided, so the description carries the burden of disclosing behavior. It does disclose the output format (PNG) and intended use, but it does not mention the return mechanism, potential errors, rate limits, or any side effects. This is minimal but not misleading.

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, concise sentence that clearly states the action, format, and purpose without any unnecessary words. It is front-loaded with the key verb and resource, making it easy to scan.

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

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

With no output schema, the description must clarify what the tool returns, but it only states the format (PNG) without explaining whether the output is a base64 string, a file path, or a URL. The purpose clause adds context, but the missing return mechanism leaves a gap for an agent deciding how to use the result.

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

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

The input schema already fully documents the single 'url' parameter with a description, so the description adds no extra semantic detail. It does not clarify URL format requirements, accessibility constraints, or query parameters. Baseline 3 is appropriate given 100% schema coverage.

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 ('Capture') with a clear resource ('URL screenshot') and format ('PNG'). It distinguishes itself from sibling tools by being the only screenshot-capturing tool among them. The purpose is immediately understandable.

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

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

The description provides clear context ('for message match evaluation'), implying when it should be used. However, it does not explicitly state when not to use it or mention any alternative tools, though none of the siblings directly compete with this function.

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

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

With no annotations provided, the description carries the full burden. It discloses read-only status, sorting order, the 100-row cap, timestamp format caveats with defensive parsing advice, and the API's rejection of open-ended ranges with mureo's compensating behavior. It also documents the exact return shape, including field names and example enum values.

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 dense single paragraph but every sentence adds necessary information. The return-format explanation, though verbose, is essential since there is no output schema. It is front-loaded with the primary action and includes a clear alternative at the end, balancing detail and brevity.

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

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

Given the absence of an output schema and annotations, the description fully compensates by specifying return fields, types, and formatting caveats. It covers date behavior, read-only nature, and usage context, while also pointing to a sibling for narrower queries. No critical gaps are apparent.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds value beyond the schema by explaining why omitted dates default to 14 days and that the API rejects open-ended ranges, which mureo automatically fills. This clarifies the behavior of start_date and end_date parameters in a practical way not captured in 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: 'List the most recent change_event rows on a Google Ads account', and adds sorting and capping details. It distinguishes from sibling tools by stating 'Use this for audit-trail diagnosis' and explicitly naming an alternative, google_ads_cost_increase_investigate, for narrower filtering.

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

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

The description provides clear when-to-use guidance: 'Use this for audit-trail diagnosis' and explicitly points to an alternative for bid/budget-only filtering. It also explains date default behavior ('Defaults to the last 14 days when dates are omitted') and the mureo filling of open-ended ranges, which helps the agent decide when to call this tool.

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

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

With no annotations, the description carries full burden. It discloses that the tool is 'Mutating', persists the action with 'status ENABLED by default', returns a resource_name, and is reversible via specific methods. Also reveals constraints like name length and default category, showing substantial transparency.

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

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

Four dense sentences, each earning its place: purpose, return value, mutating/persistence, reversibility, constraints, and alternative tool. Front-loaded with the primary action, no fluff.

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

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

For an 8-parameter create tool with no output schema, the description fully covers what the tool does, what it returns, its side effects, defaults, and pointer to update. Combined with rich schema descriptions, this is complete for an agent to invoke correctly.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds a couple of defaults (status, category) but those are already in the schema. It does not meaningfully enhance parameter semantics beyond what the schema already states, so no higher 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?

The description opens with 'Create a new Google Ads conversion action' — a specific verb and resource. It clearly distinguishes from siblings by explicitly mentioning google_ads_conversions_update for updates and noting reversibility via remove, making the purpose 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?

Provides explicit when-to-use guidance: use for creating new conversion actions, and for updating existing ones 'use google_ads_conversions_update'. Also states lifecycle/reversibility options (update with REMOVED or remove), giving clear 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?

No annotations are provided, so the description carries the full burden. It discloses read-only nature, return shape (id, name, type, status, category), null-when-no-match behavior, and limitations (excludes value settings/lookback-window). This is highly transparent.

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

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

The description is compact yet information-dense, front-loaded with the primary purpose, followed by return details, limitations, and alternatives. Every sentence contributes 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 a simple get-by-ID tool, the description covers return values, null case, exclusions, and sibling alternatives. Without an output schema, it sufficiently explains expected results.

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

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

Schema coverage is 100%; both parameters have detailed descriptions in the schema. The description adds only minor reinforcement ('by numeric ID'), so it doesn't exceed the baseline for well-documented schemas.

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

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

The description opens with a specific verb+resource+scope: 'Fetch one conversion action's configuration from Google Ads by numeric ID.' It clearly distinguishes from siblings by naming google_ads_conversions_list for full listings and google_ads_conversions_tag for tag snippets.

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

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

Explicitly states when to use alternatives: 'use google_ads_conversions_tag' for embed snippets, 'use google_ads_conversions_list' for full listings, and 'use the Google Ads UI' for value settings/lookback-window values. This provides clear when-not guidance.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states 'Read-only', details the exact return shape with fields and enum values, and notes ordering by numeric id. This gives the agent a clear picture of side effects and output without needing to invoke.

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

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

The description uses three sentences, each with distinct purpose: action/scope, return structure, and usage guidance. No filler or redundancy exists; every sentence contributes 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?

Even though there is no output schema, the description specifies the return array fields, types, and example enum strings, covering the output contract. It also addresses ordering, read-only behavior, and usage context, making it fully self-contained 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?

The only parameter, customer_id, is fully described in the schema with type, format, and fallback behavior (100% coverage). The tool description adds no additional parameter-specific meaning, so it remains at the baseline score of 3.

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 'List every conversion action configured on the Google Ads customer, ordered by numeric id', specifying a concrete verb, resource, and scope. It distinguishes itself from sibling tools by being the list variant for conversions, as opposed to .get, .create, .update, .remove, or .tag.

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 says 'Use this to discover conversion_action_id values before calling .get, .update, .remove, or .tag' and 'For CV performance metrics use google_ads_conversions_performance', giving both when-to-use and a clear alternative. This directly guides tool selection among conversion-related tools.

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

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

With no annotations provided, the description carries the full burden and does a strong job: it declares 'Read-only,' explains the zero-conversion row filter, and discloses the GAQL limitation that forces a separate query for cost_per_conversion. It does not mention rate limits or data freshness, but the core behavioral traits an agent needs to anticipate are 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 front-loaded with a one-sentence summary, then the return shape, then behavioral notes and the sibling pointer. It is longer than average but every section adds value, especially because there is no output schema to rely on. The GAQL-background sentence is slightly technical but explains an important behavior.

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

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

There is no output schema and no annotations, so the detailed return structure in the description is essential and well provided. It covers what data is returned, the ordering of actions, the conversion-only filter, read-only status, and the campaign-level alternative. Minor gaps like pagination and error behavior are acceptable for a read-only report tool with zero required 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 100%, so the baseline is 3; the schema already documents period, campaign_id, and customer_id in detail. The main description adds no new parameter-level meaning beyond 'optional campaign filter,' which the schema already states. It does not compensate further, but it does not need to.

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: 'Report Google Ads conversions broken down by conversion_action and date, with optional campaign filter.' It clearly distinguishes itself from the nearest sibling by closing with 'For campaign-level metrics use google_ads_performance_report,' so an agent can tell exactly when this tool applies.

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

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

It explicitly names an alternative tool and the condition that selects it: 'For campaign-level metrics use google_ads_performance_report.' It also states the inclusion rule ('Only rows with conversions > 0 are included'), which informs interpretation of results. This is direct, actionable guidance.

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

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

With no annotations, the description fully discloses destructive nature, that historical data persists, that conversions stop counting, and that re-enabling is possible via an update. It also states the return value. This is thorough 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?

Four sentences with every sentence carrying essential information: operation, return value, destructive effect, and alternative. No redundancy or fluff.

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

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

For a destructive operation with simple parameters, the description covers purpose, effects, return, recovery path, and alternative. No critical gaps remain even without an output schema or 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 coverage is 100% for both parameters, with clear descriptions in the schema. The tool description doesn't add new parameter-level details, so baseline 3 applies.

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 'Archive (status=REMOVED) a Google Ads conversion action', which clearly identifies the verb and resource. It also distinguishes itself from sibling update tool by contrasting status=REMOVED with status=HIDDEN.

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 names the alternative: 'For soft-hide that keeps the row visible use google_ads_conversions_update with status=HIDDEN.' It also explains re-enabling via google_ads_conversions_update, giving clear when-to-use context.

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