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

The description goes beyond the annotations by explicitly stating that the operation returns a PREVIEW and that execution requires a separate confirm_and_apply call. This discloses the non-destructive, two-phase behavior, providing transparency about the tool's side effects.

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

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

The description is succinct and well-structured. It delivers the key action, the preview nature, and the next step in a compact, scannable format without any 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?

For a simple drafting tool, the description covers the necessary workflow: draft, preview, and confirm. It does not detail the output schema or error cases, but the availability of an output schema and the clear link to confirm_and_apply make it sufficiently complete for an agent to use correctly.

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

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

The schema has no parameter descriptions, and the description only explains match_type values ('EXACT', 'PHRASE', or 'BROAD'). The meanings of keywords and campaign_id are implied by context but not explicitly defined, so the description only partially compensates for the missing 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: drafting negative keyword additions and returning a preview. It also explains the purpose (preventing ads from showing for irrelevant searches) and identifies the resource (negative keywords), making the tool's intent 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 gives a clear follow-up instruction ('Call confirm_and_apply with the returned plan_id to execute') and implies this is a drafting step. However, it does not explicitly compare to sibling tools like propose_negative_keyword_list or add_negative_locations, leaving some ambiguity about 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?

The description clearly states the tool returns a preview and does not apply changes immediately, which aligns with the destructiveHint=false annotation. It mentions the returned plan_id and the need to call confirm_and_apply to execute, making the two-step behavior fully transparent. No contradictions exist between the description and annotations.

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

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

The description is brief and to the point, using only three sentences to convey the purpose, usage, and execution flow. It avoids unnecessary detail and is well-structured, making it easy for an agent to parse and act on quickly.

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

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

The description covers the core workflow, including the preview nature, the return of a plan_id, and the need for confirm_and_apply. It does not detail the output schema or error handling, but given the simple parameter set and the mention of a plan_id, it is sufficiently complete for the intended use. Minor gaps like assumed knowledge of campaign_id and customer_id prevent a perfect score.

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

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

The description explains the semantics of geo_target_ids (numeric Google geo target constant IDs) but does not elaborate on campaign_id or customer_id. Since the schema provides no descriptions (0% coverage), the description only partially compensates. The purpose of customer_id and campaign_id is assumed rather than explicitly clarified, which could lead to misuse.

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 drafts negative geo location additions and returns a preview, distinguishing it from direct modifications. It explicitly mentions the use case of excluding cities/regions while keeping broader targets, and references the separate confirm_and_apply tool for execution. This is a specific verb ('Draft') and resource ('negative locations'), making its purpose unambiguous even among sibling tools.

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

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

The description provides explicit guidance on when to use the tool: to exclude cities/regions from a campaign while retaining broader positive targets. It also specifies the required parameter format (numeric Google geo target constant IDs) and directs the user to call confirm_and_apply with the returned plan_id for execution. This leaves no ambiguity about the workflow or 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?

Description says tool returns a preview and requires confirm_and_apply to execute, implying it does not directly modify state. However, annotations declare readOnlyHint: false, which contradicts this by suggesting it does modify. This inconsistency undermines 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?

Well-organized with separate lines for purpose, usage, parameters, and next step. No redundant info; concise and scannable.

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

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

Covers purpose, usage, prerequisites, parameter details, and the workflow with confirm_and_apply. Also mentions related get_tools. Complete for effective use.

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

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

Explains shared_set_id, keywords, and match_type with values, but omits explanation for customer_id. However, most parameters are well described, adding context beyond 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?

Clearly states the verb 'Append', object 'keywords to an EXISTING shared negative keyword list', and distinguishes from creating a new list. Includes explicit use case.

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 this tool versus propose_negative_keyword_list, and instructs to first call get_negative_keyword_lists and get_negative_keyword_list_keywords to avoid duplication. Also mentions follow-up action confirm_and_apply.

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

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

Annotations indicate read-only and non-destructive behavior, and the description aligns perfectly by focusing on analysis and reporting without mentioning any side effects or data modifications. No contradiction exists.

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

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

The description is concise and well-structured, using a clear title and two short paragraphs. Every sentence adds value—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?

The description covers the core functionality, outputs, and even mentions the GDPR indicator and non-paid channel context. While it does not elaborate on the output schema, the description is sufficient for an agent to understand the tool's purpose and decide when to invoke it.

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

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

The description provides some parameter semantics by specifying the date format and default behavior for date_range_start/end, but it does not explain customer_id, property_id, or campaign_name. Since schema coverage is 0%, more explanation would be expected, but the provided details are helpful.

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: 'Campaign clicks → GA4 conversions mapping — the real cost-per-conversion.' It specifies the data sources (Google Ads and GA4) and the outputs (click-to-session ratios, conversion comparison, cost-per-GA4-conversion). This distinct purpose differentiates it from sibling tools like get_campaign_performance or run_ga4_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 outlines the intended use case, such as revealing GDPR indicators and comparing Ads vs GA4 conversions, but it does not explicitly name alternative tools or state when to use this over others. However, the specificity of the function makes the usage clear.

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

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

The description discloses the runtime (10-30s) and that it combines Lighthouse and real-user data, going beyond the readOnly annotation. It implies no side effects, consistent with the annotations, and provides useful operational context.

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

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

The description is concise and well-structured: what it does, what it returns, when to use, and runtime. It packs essential information without 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?

The description covers purpose, output summary, usage context, and runtime, making it complete for an agent to decide and call. It provides a clear summary of the output schema without needing to enumerate every field.

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

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

The description clarifies the strategy parameter with its default ('mobile') and explains the rationale ('most paid traffic'), adding meaning beyond the bare schema. The url parameter is self-explanatory and needs no further elaboration.

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 runs PageSpeed Insights for a landing page, returning performance scores, lab/field data, and opportunities. It explicitly ties usage to ad final URLs, making the purpose distinct and actionable.

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

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

It explicitly says to use on ad final URLs because slow landing pages depress Quality Score and waste paid clicks, giving clear when-to-use guidance. The mention of strategy default and runtime further supports proper usage.

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

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

The description transparently discloses non-obvious behavior: it returns a PREVIEW and requires a subsequent call to confirm_and_apply to actually execute. This goes beyond the annotations (readOnlyHint=false, destructiveHint=false) which do not capture the preview/confirm pattern. The agent is fully aware of the tool's side effects.

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

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

The description repeats the preview/confirm behavior in the first and last sentences, which is slightly redundant. However, the overall structure is logical: summary, detailed explanation, parameter notes. It is not overly long and the redundancy reinforces the critical workflow.

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

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

The description provides all necessary context for an agent to act: what the tool does, how it relates to other tools (get_negative_keyword_lists, confirm_and_apply), the fact that it returns a plan_id, and the need for confirmation. It is self-contained enough to guide the agent without needing additional references.

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

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

The description adds meaning for shared_set_id and campaign_ids (including numeric type and how to obtain them), but does not explain customer_id, which is a common but still important parameter. Coverage is good for 2 of 3 params, and the extra guidance on deriving shared_set_id from get_negative_keyword_lists is valuable.

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

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

The description clearly identifies the action (attach), the resource (shared set), and the target (campaigns), and distinguishes it from related tools like detach_shared_set_from_campaigns. It also explains the purpose (inheriting negative keywords) precisely.

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 states the common use case ('Most commonly used to attach a shared negative keyword list to newly-built campaigns') and provides the full workflow: fetch the shared_set_id, attach, then confirm with confirm_and_apply. This gives the agent clear guidance on when and how to use the tool.

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

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

The description aligns with the readOnlyHint annotation (no destructive actions implied) and adds useful behavioral context beyond the annotation by explaining what the tool diagnoses (consent gaps, attribution differences, missing configuration). It does not describe side effects, which is appropriate given the read-only nature, and there is no contradiction.

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

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

The structure is reasonably organized with a summary line and a detail line, but it contains redundancy: 'Compare Ads-reported conversions vs GA4 — find tracking discrepancies' essentially restates 'Checks whether conversions reported by Google Ads match what GA4 records'. This repetition could be trimmed without losing information, though the parameter notes are clear and well-placed.

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

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

Given that an output schema is present, it is not necessary to describe return values. The description covers the core behavior, parameter defaults, and date handling, which is sufficient for an agent to invoke the tool correctly. Minor gaps remain around the exact identifiers (customer_id/property_id) and any assumptions about required permissions, but these do not materially impede use.

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

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

The schema has zero parameter descriptions, but the description compensates for the non-obvious parameters: it explains conversion_events (optional list of GA4 events, null defaults to aggregate comparison) and the date range format with the 30-day fallback. However, customer_id and property_id are left undefined—their meaning (likely Google Ads customer ID and GA4 property ID) is only inferred from the tool name and context, so the compensation is incomplete.

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 specific function: comparing Ads-reported conversions against GA4 data and finding tracking discrepancies. It goes beyond generic verbs like 'check' to name concrete diagnostic outputs (GDPR consent gaps, attribution model differences, missing conversion event configuration), which distinguishes it from the many reporting tools in the sibling 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 some practical usage details, such as optional conversion_events filtering, date format expectations, and the default 30-day window when dates are empty. However, it does not explicitly state when to prefer this tool over closely related siblings like audit_event_coverage, validate_tracking, or analyze_campaign_conversions, nor does it mention what scenarios are out of scope.

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 declare readOnlyHint=true and destructiveHint=false, and the description is consistent with these. It adds substantial behavioral detail: the tool fetches the LIVE GTM container, joins GA4 counts, and returns a per-event matrix with enumerated statuses. It also transparently surfaces limitations by stating that dynamic-event tags and Custom HTML tags cannot be interpreted automatically. This goes well beyond the annotations and gives the agent a clear picture of what the tool will and won't do.

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 earns its place: the purpose is front-loaded, input preparation is clear, and the exhaustive status list is necessary to convey the output matrix. It is structured with line breaks and a bullet-like list, making it scannable. While it could be trimmed slightly (e.g., some statuses are self-explanatory), the detail is justified given the tool's complexity.

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

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

The tool is complex with multiple inputs, an output schema, and a detailed status taxonomy. The description covers the audit process, input preparation, output semantics (via statuses), and known limitations. It also mentions the date-range default. Given that an output schema exists, it does not need to describe return structures, and it omits nothing critical for an agent to invoke the tool correctly. The coverage is comprehensive for its 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?

With schema description coverage at 0%, the description carries the burden of explaining parameters. It thoroughly explains expected_events ('Pass that list as expected_events'), date range ('Date format: YYYY-MM-DD. Empty = last 30 days'), and GTM IDs ('GTM IDs come from Tag Manager UI → Admin → Container Settings'). The GA4 property_id is not explicitly named, but the description's mention of GA4 event counts implies its necessity. It adds meaning to most parameters but leaves property_id to inference, so it's strong but not perfect.

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 statement: 'Three-way audit: codebase events ↔ GTM tags ↔ GA4 actual fires.' It names the exact components and distinguishes itself from generic tracking tools by describing the cross-referencing behavior. The detailed status list further clarifies the tool's scope, making it unambiguous among siblings like validate_tracking.

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 on how to prepare inputs: how to extract expected_events from the codebase, where to find GTM IDs, and the date format. However, it does not explicitly state when to use this tool versus alternatives like validate_tracking or get_tracking_events, nor does it give exclusion conditions. It offers strong contextual guidance but no explicit when-not or alternative routing.

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

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

The description goes beyond the annotations (readOnlyHint=false, destructiveHint=true) by detailing the dry_run default, the config override that can force dry_run, the two-phase apply refusal behavior, and the exact response fields to surface. This full transparency helps the agent understand potential non-committal 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 somewhat verbose with repeated warnings, but each paragraph conveys necessary safety-critical information (default behavior, config override, two-phase apply). The structure is logical and every sentence earns its place, though a slightly more compact phrasing could improve readability.

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

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

The description is complete for a destructive tool: it covers the dry_run default, config overrides, two-phase apply behavior, response fields to surface, and the source of plan_id. Given the complexity and risk, nothing essential 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?

Even though the schema has 0% description coverage, the description fully explains both parameters: plan_id is described as coming from prior draft_* or pause/enable calls, and dry_run is explained in detail—its default value, how to override it, and the consequences. This completely compensates for the lack of schema-level descriptions.

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

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

The description clearly states the tool's purpose: 'Execute a previously previewed change.' It uses a specific verb and object, and distinguishes itself from sibling tools like draft_*, update_*, and pause/enable by focusing on applying an already-prepared plan.

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 explains when to use the tool: after a prior draft_* or pause/enable call (since 'The plan_id comes from a prior draft_* or pause/enable tool call'). It also provides critical usage guidance about the dry_run parameter, including the need to pass dry_run=false to make real changes.

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 transparently discloses that the operation only returns a preview and does not directly modify data, aligning with the annotations (readOnlyHint=false, destructiveHint=false). It also notes that the shared set itself remains unchanged, providing full visibility into side effects.

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

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

The description is concise and well-structured: it opens with the core action, then explains the preview nature, provides usage tips, parameter details, and execution instruction. No redundant or ambiguous phrasing; every sentence serves a purpose.

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

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

The description covers the full workflow: how to inspect before acting, what the operation returns (preview), and how to apply the changes (confirm_and_apply). Given the output schema and the presence of a confirm step, this is sufficient for an agent to use the tool correctly without additional context.

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

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

The description explains the two required parameters: 'shared_set_id' is identified as a numeric ID from 'get_negative_keyword_lists', and 'campaign_ids' is described as a list of numeric campaign IDs to detach from. This gives clear meaning beyond the raw schema, even though 'customer_id' is not explicitly defined (it is optional with default).

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

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

The description clearly states the action ('Detach a shared set from one or more campaigns') with a specific verb and resource. It distinguishes from sibling tools like 'attach_shared_set_to_campaigns' and other operations, 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: it instructs to use 'get_negative_keyword_list_campaigns' to inspect attachments before detaching, and explains the two-step process (returns a preview, then call 'confirm_and_apply' to execute). This clearly tells the agent when and how to use the tool relative to 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?

The readOnlyHint annotation already indicates the operation is read-only, and the description adds transparency by summarizing the output (keyword ideas sorted by avg monthly search volume, competition, bid range). It does not introduce any contradiction with the annotation.

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

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

The description is well-structured with bullets for input modes and a separate paragraph for include_monthly_volumes, followed by output details and parameter hints. It is somewhat repetitive but remains concise and 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?

It provides enough context for an agent to understand the tool's purpose, when to use the optional flag, and what to expect in response. It lacks an explicit statement about the output schema, but that is not required given that the output format is described in prose.

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

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

The description explains the purpose of seed_keywords, url, include_monthly_volumes, geo_target_id, language_id, and page_size with examples. It does not describe customer_id, which is a gap given that the schema itself has no parameter descriptions (coverage 0%).

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 verb 'Discover' clearly indicates the action, and 'new keyword ideas using Google Ads Keyword Planner' specifies the resource and purpose. It is distinct from sibling tools like get_keyword_performance or get_search_terms, which focus on existing data rather than generation of new ideas.

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

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

It provides explicit guidance on when to use include_monthly_volumes ('when the user asks about demand trends, seasonality, or 'when should I ramp budget'') and explains the two input modes (keywords or URL). However, it does not directly contrast with sibling tools for when this tool is the better choice.

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 'returns a PREVIEW, does NOT create' and mentions atomic keyword inclusion, making the tool's non-destructive behavior clear despite annotations indicating otherwise.

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

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

The description is concise but slightly redundant (first sentence and second sentence overlap). It is well-structured with clear parameter descriptions and a next-step note.

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?

It provides enough context for a draft operation, including the follow-up action. It does not mention error cases, but for a preview tool it is sufficiently complete.

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

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

The description explains the purpose of most parameters: campaign_id, ad_group_name, keywords, and cpc_bid_micros. Only customer_id is left unexplained, but it has a default and is less critical.

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

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

The description clearly states the tool's purpose: 'Draft a new ad group within an existing campaign' and emphasizes it returns a preview, not a creation. This is specific and distinguishes it from creation 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?

It gives usage context by explaining the draft nature and directs the agent to call confirm_and_apply with the returned plan_id. However, it does not explicitly compare with alternatives like update_ad_group, but the preview aspect implies when to use it.

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

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

The description mentions 'returns a PREVIEW,' which implies the operation is not immediately destructive, but it does not clarify whether a draft is persisted or has side effects. The annotations indicate readOnlyHint false and destructiveHint false, but the description alone leaves the behavior ambiguous regarding whether any state is modified.

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 exceptionally concise, consisting of a single sentence that communicates the core action and a notable output characteristic. It avoids unnecessary elaboration while still conveying key 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?

The description lacks important contextual details. It does not explain that this tool is part of a draft-then-apply workflow (given the existence of confirm_and_apply), nor does it specify the expected output structure or how errors are handled. The context of similar tools (e.g., draft_campaign, draft_sitelinks) is not leveraged to clarify the tool's role.

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 parameters campaign_id, callouts, and customer_id are listed with types and requiredness, but no descriptions of their meaning or expected format are provided. For instance, it is unclear what format the callouts array strings should take (e.g., plain text, character limits, or any validation rules).

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

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

The description clearly states the action (draft) and the resource (campaign callout assets), and explicitly notes that it returns a preview. The verb 'draft' and the preview mention make the tool's primary purpose understandable, though the exact meaning of 'draft' in this context is not fully elaborated.

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

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

The description provides no guidance on when to use this tool versus other drafting tools (e.g., draft_sitelinks, draft_campaign) or when to prefer a different approach. It does not mention any prerequisites, nor does it explain the workflow relationship with confirm_and_apply.

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 states 'returns a PREVIEW, does NOT create anything' and instructs to call confirm_and_apply to execute, which contradicts the annotation readOnlyHint=false. This annotation implies the tool may modify data, creating a direct conflict with the description's claim of no actual creation.

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 logically structured with bullet points and covers all key aspects, but it is somewhat verbose with repeated parameter explanations. It could be tightened slightly without losing clarity.

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

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

The description provides all necessary context: what the tool does, what it does not do, parameter details including required fields and examples, and the next step (confirm_and_apply). It is sufficiently comprehensive for an agent to use correctly.

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

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

The description adds significant meaning to the parameters, explaining bidding_strategy options, target_cpa/roas requirements, max_cpc behavior, and providing common geo and language ID examples. This goes well beyond the schema's bare types and defaults.

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

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

The description clearly states it drafts a full campaign structure and returns a preview, explicitly listing what is created in the preview and what is excluded (ads). It distinguishes itself from other drafting tools like draft_responsive_search_ad.

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

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

The description explains when to use the tool (to draft a campaign) and when to use a follow-up tool (draft_responsive_search_ad after the campaign exists). It also directs the user to confirm_and_apply to execute the preview, providing a clear workflow.

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

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

The description transparently explains that the action returns a preview and does not apply until confirmed, aligning with the annotations (readOnlyHint=false, destructiveHint=false). It also details the fallback behavior for default_value and the immutability flag, disclosing the tool's operational nuances without contradicting 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 concise and well-structured, using line breaks to separate distinct concepts. It avoids unnecessary verbosity, though the repeated 'legal fallback' phrase adds slight redundancy. Overall, it is efficient and readable.

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

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

The description covers the tool's purpose, return behavior (preview with plan_id), and next steps (confirm_and_apply), which is sufficient for a draft operation. It does not explain every parameter, but that gap is partially addressed in parameter semantics. Given the availability of an output schema (not shown), the description adequately contextualizes the workflow.

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

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

The description provides meaningful explanations for several key parameters (type_, category, default_value, always_use_default_value, include_in_conversions_metric) but leaves others (counting_type, currency_code, primary_for_goal, attribution_model, windows, phone duration) undefined. Since schema coverage is 0%, the description partially compensates but not fully, warranting a moderate 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 clearly states 'Draft a new Google Ads ConversionAction — returns a PREVIEW,' identifying the specific action and its preview nature. It distinguishes from sibling tools like draft_update_conversion_action and draft_remove_conversion_action, 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 explicitly instructs to 'Call confirm_and_apply with the returned plan_id to execute,' providing a clear next step. It also notes that include_in_conversions_metric is immutable on create and suggests using draft_update_conversion_action for changes, guiding appropriate usage among siblings.

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

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

The description is transparent about the tool's non-committal nature: it 'returns a PREVIEW' and requires a separate confirm_and_apply call to execute. This aligns with the annotations (readOnlyHint=false, destructiveHint=false) and clarifies that no immediate changes are applied.

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

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

The description is well-organized with clear sections and bullet lists, making the constraints and accepted values easy to scan. It avoids fluff and each sentence serves a purpose, such as explaining the default negative behavior and the requirement to call confirm_and_apply.

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 (multiple optional lists, negative flag, and confirmation step), the description provides sufficient context: it states the preview nature, the required selection constraints, the exact accepted enum-like values, and the follow-up action. This is enough for an agent to use the tool correctly without additional documentation.

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

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

The description thoroughly explains the meaning and accepted values for most parameters, including negative boolean, age_ranges, genders, parental_statuses, and income_ranges with country limitations. However, customer_id is present in the schema but not mentioned in the description, leaving its role or necessity unaddressed.

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 ('Draft demographic targeting') and the specific resource it operates on (age/gender/parental status/income segments). It also distinguishes its preview-only behavior and explicitly points to confirm_and_apply for execution, which differentiates it from related tools.

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

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

The description explains when to use the tool (to exclude or narrow demographic targeting) and provides key constraints: exactly one of ad_group_id or campaign_id, and at least one demographic list. It also lists all accepted values and instructs to call confirm_and_apply with the returned plan_id, giving clear next-step guidance.

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

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

Annotations indicate readOnlyHint=false and destructiveHint=false, which already convey that this is a non-read-only, non-destructive operation. The description adds that it drafts from local files, but does not disclose deeper side effects like whether existing drafts are replaced or if any confirmation is required. With annotations present, this is adequate but not thorough.

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

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

The description is a single, focused sentence that directly states the purpose and the accepted input file types. It is concise and well-structured with no redundant 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?

The description is minimal and leaves out critical context. It does not mention what happens after drafting (e.g., whether assets are automatically applied or need approval), any output format, or the significance of the customer_id. Given that this is a creation-like operation with potential side effects, the lack of such details makes it incomplete.

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

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

Schema description coverage is 0%. The description does not explain any of the three parameters (campaign_id, customer_id, image_paths). The tool description offers no clues about what these parameters mean or how they should be supplied, leaving the agent completely in the dark.

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

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

The description clearly states the verb 'Draft' and the resource 'campaign image assets', and further specifies the accepted file types (PNG, JPEG, GIF). This is unambiguous and distinguishes it from other drafting tools for campaigns, ad groups, etc.

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

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

The description provides no explicit guidance on when to use this tool versus alternatives. It only states what it does; there is no mention of when not to use it or how it compares to other drafting tools (e.g., draft_campaign).

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

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

Explicitly states it returns a PREVIEW and requires confirm_and_apply to execute, so it does not directly modify state. Also notes 'Applies to future data only', which sets expectations. This aligns with annotations (readOnlyHint false, destructiveHint false) and adds useful 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 reasonably concise but has some redundancy (e.g., the repeated 'the fix for' phrasing and quotes). It is structured in short lines, but could be tightened without losing 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?

Provides enough context for drafting: mentions preview, plan_id for confirmation, and future-data scope. The output schema is not described but its existence is indicated, so a user can infer that confirm_and_apply will require the returned plan_id. Slight gap on property_id semantics.

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?

While event_name is obvious and counting_method is explained with examples, property_id is not described in the text. Since the schema has no descriptions (coverage 0%), the description should compensate but fails to explain what property_id represents or when to override its default.

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

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

The description clearly states the tool drafts a GA4 key event and returns a preview, distinguishing it from execution tools like confirm_and_apply. It also specifies the diagnostic context (fixing untracked conversions) which clarifies its role.

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

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

Provides when-to-use guidance by referencing attribution_check and validate_tracking as diagnostics that precede this action. It also mentions counting_method examples but does not explicitly list when not to use it or alternative tools beyond the implicit context.

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

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

The description explicitly states that the tool does not add keywords and returns a preview, disclosing its non-final nature. This goes beyond the annotations (readOnlyHint=false) to explain the draft workflow.

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

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

The description is concise, using two short sentences to convey the tool's purpose and workflow. It is well-structured 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?

The description provides enough context by referencing the 'confirm_and_apply' tool and the workflow of drafting before applying. It effectively differentiates from sibling tools like 'add_negative_keywords' or 'draft_ad_group'. The existence of output schema reduces the need to describe return values.

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

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

The description explains the structure of the 'keywords' parameter, specifying the required fields (text and match_type) and allowed match_type values. However, it does not describe 'ad_group_id' or 'customer_id', leaving those parameters undefined. With only one of three parameters described, the coverage is low and not fully compensated.

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 drafts keyword additions and returns a preview, distinguishing it from tools that actually add keywords. It names the specific resource (keywords) and the action (draft).

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

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

The description explicitly directs the user to call confirm_and_apply with the returned plan_id to execute, providing clear next steps. It also warns that no keywords are added immediately, guiding appropriate usage.

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

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

Explains the conceptual effect of removal (stops counting, drops from goal lists, preserves history, irreversible). Since annotations only show readOnlyHint=false and destructiveHint=false, this context is additive and not contradictory for a draft 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?

Compact, well-structured description with a clear purpose, follow-up instruction, and constraint note. 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?

Provides the essential workflow (draft -> confirm_and_apply) and key restrictions, and an output schema is present. Minor gap is lack of explicit parameter guidance for the two input fields.

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

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

Input schema has 0% parameter descriptions and the description does not explain customer_id or conversion_action_id format/value. The target is inferable from the tool name, but the description does not compensate for the missing schema detail.

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 drafts a removal of a ConversionAction and returns a preview. Distinguishes from sibling draft_create and draft_update actions.

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

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

Explicitly instructs to call confirm_and_apply with the returned plan_id to execute, and notes SMART_CAMPAIGN_* and GOOGLE_HOSTED types will reject removal, giving the agent actionable selection and post-draft 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?

Given the annotations (readOnlyHint: false, destructiveHint: false) which are ambiguous, the description adds critical transparency by stating it returns a preview and does NOT create the ad, and that confirm_and_apply is needed to execute. This clearly communicates the tool's non-destructive, non-read-only nature.

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

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

The description is concise overall, but there is minor redundancy: the opening line 'returns a PREVIEW, does NOT create the ad' is reiterated later with 'Call confirm_and_apply to execute.' The structure uses clear bullet points for the headline/description format, making it scannable, but a small trim would improve efficiency.

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 drafting tool, the description covers the essential context: what it does, its relationship to confirm_and_apply, and the critical input constraints. It does not describe the preview's content or error scenarios, but given the tool's straightforward nature and the presence of sibling tools, this is reasonably complete.

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

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

The schema has zero description coverage for parameters, so the description must compensate. It thoroughly explains headlines and descriptions (including constraints and pinned object format), but leaves ad_group_id, final_url, path1, path2, and customer_id without any explanation. While some may be self-explanatory, the description only partially covers the 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 purpose: to draft a responsive search ad and return a preview without creating it. It explicitly distinguishes itself from the confirm_and_apply tool, leaving no ambiguity about its role.

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

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

The description provides concrete usage guidance: it mentions the need to call confirm_and_apply for execution, specifies the required number and character limits for headlines and descriptions, and explains the pinned format. It also clarifies that this tool does not create the ad, acting as an explicit when-not-to-use indicator.

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 clearly conveys that the tool creates a draft and returns a preview, and that actual execution requires a separate confirm_and_apply call. This explains the side-effect (non-destructive, non-read-only) beyond the minimal annotations, which only indicate readOnlyHint=false and destructiveHint=false.

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

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

The description is well-structured with a clear lead line, parameter breakdown, recommendation, and execution note. It is reasonably concise, though the parameter list is somewhat repetitive with the schema. Every element adds value, and no extraneous content is present.

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

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

For a drafting tool, the description covers the purpose, input parameters, a usage constraint, and the next step (confirm_and_apply). It does not detail the output schema or error scenarios, but given the presence of an output schema and the straightforward drafting nature, it is sufficiently complete for an agent to call it correctly.

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

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

The description explains the two required parameters (campaign_id and sitelinks) and the subfields of each sitelink item (link_text, final_url, description1, description2). However, it omits the optional customer_id parameter, and the schema has zero description coverage, so a small gap remains. Overall, the key parameters are well explained.

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: drafting sitelink extensions for a campaign and returning a preview. It also distinguishes itself from related drafting tools by the resource type (sitelinks) and the explicit workflow of confirming with confirm_and_apply.

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 some usage guidance (Google recommends at least 4 sitelinks, fewer than 2 may not show, and the need to call confirm_and_apply to execute), but does not explicitly state when to use this tool versus alternatives like draft_callouts or draft_structured_snippets. The purpose is clear from the name, but explicit when/when-not guidance is absent.

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 notes that it 'returns a PREVIEW', which clarifies the non-final nature of the operation. However, it does not specify whether any underlying draft data is persisted, and annotations are minimal.

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 efficiently conveys the tool's purpose.

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

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

Given the lack of parameter explanations and only a vague mention of a preview return, the description is insufficient for an agent to correctly construct the required input or understand the full output.

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

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

The schema has no property descriptions, and the description does not explain the structure of the 'snippets' array or the other parameters. This leaves significant ambiguity for the agent.

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

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

The description clearly states the verb 'Draft' and the specific object 'campaign structured snippet assets', and distinguishes it from other draft tools for different asset types like callouts and sitelinks.

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 by naming the asset type, but does not explicitly contrast with sibling tools or provide conditions for when to use it 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?

Beyond annotations, the description clarifies that this tool only returns a preview and does not execute changes until confirm_and_apply is called. Also explains partial-update semantics, which is important for user 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?

Description is compact and front-loaded with the core purpose, then gives practical usage instructions. No redundant information 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?

Covers the full workflow: how to identify the target entity, what parameters are sent, what the response contains (plan_id), and how to commit the change. Adequate for an agent to use this tool correctly among many related siblings.

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

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

Schema description coverage is 0%, and the description only vaguely references call-duration threshold and attribution. Many domain-specific parameters (counting_type, attribution_model, always_use_default_value, include_in_conversions_metric, window days) are not explained, leaving ambiguity about allowable values and meanings.

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 drafts a partial UPDATE of an existing ConversionAction and returns a PREVIEW, which distinguishes it from create/remove actions. Lists specific use cases like rename, demote, change value, adjust call-duration threshold, and change attribution.

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 scenarios and explains that only non-empty/non-default parameters are sent. Includes concrete next steps: find the ID via the SELECT query and call confirm_and_apply with the returned plan_id to execute.

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

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

The description is transparent about side effects: it only drafts and returns a preview, not applying the change until confirm_and_apply is called. This is critical behavioral information that goes beyond the annotations and prevents the agent from assuming the entity is enabled immediately.

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

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

The description is concise and well-organized, using bullet points and examples effectively. Every sentence adds value, and there is no redundant or irrelevant wording.

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

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

The description covers the main action, required parameters, and the follow-up step to apply the draft. It does not mention customer_id, but the output schema is present and the return behavior (preview with plan_id) is implied clearly.

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?

entity_type and entity_id are well documented, including acceptable values and ID formats for each entity type. customer_id is present in the schema but not explained in the description, which is a minor gap since it is optional with a default.

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

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

The description clearly states the tool's purpose: drafting the enabling of a paused campaign, ad group, ad, or keyword. It also distinguishes this from related tools like pause_entity and remove_entity by emphasizing the 'draft' and 'preview' nature.

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 guidance that this returns a preview and that confirm_and_apply must be called to execute. It does not explicitly contrast with pause_entity or remove_entity, but the draft/preview wording makes the intended usage clear.

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

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

The description clearly states 'without creating anything', aligning with the readOnlyHint and destructiveHint annotations. It additionally discloses a non-obvious behavior: per-keyword max_cpc values are collapsed to a campaign-level cap, which is valuable transparency beyond the annotations.

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

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

The description leads with the purpose, then a caveat, then parameter details, which is logical and mostly concise. Some redundancy exists (max_cpc appears both in the keyword object and as a standalone note), but it does not significantly harm readability.

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

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

Given an output schema exists, the description adequately explains what the tool does and the key inputs. It lacks an explicit mention of the output shape or any error/rate-limit behavior, and customer_id is unexplained, but these are minor 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?

Prose descriptions cover keywords, max_cpc, geo_target_id, language_id, daily_budget, and forecast_days with defaults and example values, compensating for the schema's lack of descriptions. However, customer_id is not explained at all, leaving one parameter semantically undocumented.

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

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

The description states a specific action ('Forecast') and precise objects ('clicks, cost, and conversions for a set of keywords'), clearly distinguishing this from reporting or discovery tools. Mentioning Google Ads Keyword Planner adds concrete context without ambiguity.

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 identifies the use case ('Essential for budget planning before launching campaigns') and notes the operation creates nothing, indicating when it is safe to use. It does not explicitly contrast with alternative tools, but the context is sufficient for most agents.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description aligns by describing generation of code and an optional read-only check against GA4. It adds context about the 'ready-to-paste' output and the check, but no side effects are mentioned, which is consistent with the annotations.

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

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

The description is concise, consisting of two sentences that front-load the main action and then elaborate on the output and optional check. No redundant information or unnecessary detail is present.

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

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

The description covers the core purpose and mentions the optional check, but it lacks details about the output format (e.g., the structure of the gtag code), the exact behavior when 'check_existing' is false, or how 'event_params' is used. Given the tool's complexity (5 parameters, nested object in schema), the description is not fully complete.

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

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

The description explicitly explains the 'trigger' parameter and implicitly references 'event_name' and 'check_existing', but it does not clarify the purpose of 'property_id' or 'event_params'. Given the schema has 5 parameters, this leaves a significant gap in understanding the full input requirements.

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: generating a GA4 event tracking JavaScript snippet. The verb 'generate' is specific, and the resource (GA4 event tracking code) distinguishes it from sibling tools like 'get_tracking_events' or 'validate_tracking'.

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

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

The description implies when to use the tool (e.g., to produce tracking code, with optional checks for existing events) but does not explicitly contrast it with alternatives. Siblings like 'validate_tracking' exist, but no clear 'use this instead of X' guidance is provided.

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

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

Annotations already indicate read-only and non-destructive behavior. The description adds that it lists only accessible accounts/properties and specifies return contents, providing useful context beyond annotations without contradicting them.

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

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

The description is succinct, with two clear sentences conveying purpose and usage. No redundant or vague wording.

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 parameterless listing operation, the description fully explains what it does and what it returns. It is complete without an output schema, as the return fields are explicitly mentioned.

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

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

The input schema has zero parameters, so schema coverage is 100% (trivially). The description adds no parameter information because none exist. 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 clearly states the tool lists all GA4 accounts and properties accessible by the authenticated user, and explicitly mentions the returned fields (account names, property names, property IDs). It distinguishes itself from sibling account-listing tools by specifying GA4 scope.

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

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

It explicitly instructs to use this as the first step to discover available GA4 properties, which is a clear usage guideline that differentiates it from other discovery or query 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?

The description is consistent with readOnlyHint=true and describes only data retrieval with no side effects. It also discloses output-shaping behavior for compact mode, adding useful transparency beyond the annotations.

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

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

The description is concise and front-loaded with the tool's purpose, followed by a short returns list and a compact-mode note. There is no redundant or misleading 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?

Core return fields and compact-mode behavior are covered well, and the annotations clarify read-only safety. It could provide more context around date-range and customer_id semantics, as well as explicit differentiation from sibling reporting tools, but it is generally sufficient.

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

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

Only the compact parameter is explained in detail; customer_id, date_range_start, and date_range_end are left without format or constraint guidance. Parameter names provide basic meaning, but the schema description coverage is 0% and the description does not fill all gaps.

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

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

The description clearly states that the tool retrieves ad-level performance data and enumerates the returned metrics. It is easy to distinguish from campaign, keyword, and asset reporting tools by title and content.

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 some usage guidance by suggesting compact=true for audits/overviews, but it does not explicitly explain when to prefer this tool over sibling tools such as get_campaign_performance or get_keyword_performance. The intended use case must be inferred.

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

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

The annotations indicate readOnlyHint=true and destructiveHint=false, which align with the description's 'Returns' wording. The description adds a functional limitation (no performance labels) not covered by annotations, increasing transparency beyond the structured metadata.

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

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

The description is concise and well-structured: a clear opening statement, a list of returned fields, a note on limitations with an alternative, and a parameter explanation. No redundancy or irrelevant 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?

The description provides sufficient context for a read-only tool: it names the resource, the fields returned, and a relevant limitation. However, the missing explanation for customer_id and no mention of the output structure (though an output schema exists) leaves minor gaps, but overall it is adequate.

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

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

Schema description coverage is 0%, and the tool description only explains campaign_id ('optional filter to a single PMax campaign'). The customer_id parameter is left entirely undocumented, leaving users to infer its meaning without additional guidance.

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

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

The description clearly states the tool retrieves per-asset details for Performance Max campaigns, specifying the exact fields returned (field_type, primary_status, content). This is specific and unambiguous, distinguishing it from other asset-performance tools.

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

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

The description explicitly notes that per-asset performance labels are not available and directs the user to an alternative tool (get_detailed_asset_performance) when that capability is needed. It also explains the optional campaign_id filter, providing 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?

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds context about what data is returned and the limitation regarding PMax, which complements the annotations without contradicting them. No side effects or destructive actions are implied.

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

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

The description is compact and well-organized: purpose statement, output details, usage note, and parameter notes. Each sentence adds value without redundancy, and the structure makes it easy to scan for key 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 that an output schema exists (though not shown) and the description enumerates the output fields and audience types, the description provides enough context for an agent to understand what the tool returns and when to use it. It also covers the date range defaults and the campaign filter, making it sufficiently complete for a straightforward read-only reporting tool.

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

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

Schema description coverage is 0%, so the description must compensate. It does clarify that campaign_id is an optional filter and states the date format (YYYY-MM-DD) and default behavior (empty = last 30 days). However, customer_id is left undocumented, and there is no explanation of how the parameters interplay (e.g., whether both campaign and customer can be specified together). This partial compensation earns a middle 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 clearly states the tool retrieves audience segment performance metrics, enumerates the metric fields (impressions, clicks, cost, conversions, CTR, CPC) and audience types (remarketing, in-market, affinity, demographics). It also distinguishes itself from PMax-related reporting, helping an agent choose this tool for explicit audience targeting scenarios.

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

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

The description gives an explicit when-not scenario: PMax audience targeting is automatic and may not appear in this report, which implies the tool is intended for Search/Display campaigns with explicit targeting. However, it does not explicitly name an alternative tool (e.g., get_pmax_performance) for PMax cases, so the guidance is slightly less explicit than ideal.

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

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

Annotations already mark readOnlyHint=true and destructiveHint=false. The description uses 'Get' and describes returns without any destructive or side-effect language, showing full consistency. It adds context about the compact mode, which is a behavioral variant, but not a side effect.

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

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

The description is concise, about 60 words, with a clear structure: purpose, returned fields, then usage notes on dates and compact mode. 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?

Lists all key returned fields, provides date defaults, and explains the compact alternative. With an output schema present but not shown, the description covers the essential context 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?

The schema has 4 parameters with 0% description coverage. The tool description covers date_range_start and date_range_end (format and default), and compact (behavior). However, customer_id is not mentioned at all. Given that 3 of 4 parameters are explained, it compensates well but not fully.

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 retrieves campaign-level performance metrics, lists the specific metrics returned, and implicitly distinguishes it from sibling tools like get_ad_performance or get_keyword_performance by focusing solely on campaigns.

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

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

Explicitly explains date format (YYYY-MM-DD, empty = last 30 days) and provides guidance on when to use compact=true for large accounts, including what it returns. This gives clear operational instructions.

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

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

Annotations indicate readOnlyHint=true and destructiveHint=false, which aligns perfectly with the description's 'List' action. The description adds context about default behavior and the non-modifying nature of the tool, enhancing transparency without contradiction.

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

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

The description is tightly written with no redundant phrases. It efficiently covers the tool's purpose, parameter constraint, and output details, while the final sentence about default behavior adds value without bloat.

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?

It describes the output fields (value, negative/positive, status, remove_id) and explains how to use remove_id, which is sufficient for a read-only list operation. Minor gaps remain regarding customer_id usage and potential error cases, but the description is largely complete for the intended use case.

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

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

The description clarifies the relationship between ad_group_id and campaign_id (exactly one must be provided) but does not explain the purpose or requirement of customer_id. Since schema coverage is 0%, the description only partially compensates for the lack of parameter documentation.

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

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

Clearly states the tool lists demographic targeting criteria (age, gender, parental status, income), which is a specific verb and resource. It is distinguishable from sibling tools that focus on other entity types.

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

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

Explicitly instructs to provide exactly one of ad_group_id or campaign_id, which is a critical usage rule. Also explains how the returned remove_id can be used with remove_entity, providing clear guidance for the agent.

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

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

Annotations already indicate read-only and non-destructive behavior, which covers safety. The description adds that it lists assets and their field types, but does not mention any potential side effects, data freshness, or limitations. Since the annotations carry the primary safety signal, the description provides minimal extra transparency beyond clarifying its reporting nature.

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 somewhat redundant, repeating the campaign_id filter and restating the purpose, but it remains relatively compact and focused. It avoids unnecessary jargon and clearly conveys the tool's function without excessive length.

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

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

An output schema is provided, so the return format is defined. The description explains the purpose and gives a hint about the optional filter. It does not mention prerequisites or edge cases, but given the tool's straightforward read-only nature, it is reasonably complete for an agent to understand and call 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?

Only campaign_id is mentioned in the description as an optional filter, with no explanation for customer_id. The schema itself has no descriptions (coverage 0%). This leaves the meaning and purpose of customer_id ambiguous, though the description does clarify campaign_id's role.

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 'Get[s] top-performing asset combinations for Performance Max campaigns' and elaborates that it shows which headline, description, and image combinations Google selects most often. This distinguishes it from sibling tools like get_asset_performance or get_pmax_performance by focusing specifically on combinations.

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

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

The description does not provide any guidance on when to use this tool versus alternatives such as get_asset_performance or get_pmax_performance. It lacks information on use cases, scenarios, or why one might prefer this over other reporting 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, establishing the safety profile. The description adds context about the returned data (parameters, triggers, priority, etc.) without contradicting the read-only nature. No side effects are mentioned, but the tool is clearly a get operation.

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

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

The description is two concise sentences, front-loading the primary purpose and then elaborating on the included details. No unnecessary words or redundant information, and it is well-structured with a clear flow from what it does to when to use it.

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?

Provides enough context to understand the tool's function and usage scenario, including the mention of audit_event_coverage. The return content is described sufficiently for an agent to know what to expect. However, parameter meanings are not covered, leaving a minor gap, but the existence of an output schema reduces the need for detailed return 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?

The description does not explain the meaning or purpose of tag_id, gtm_account_id, or gtm_container_id. With zero schema descriptions for these parameters, the agent must infer that tag_id likely identifies the tag, but this is not explicit. This is a significant gap for correct invocation.

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

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

Clearly states it retrieves the full RAW configuration for a single GTM tag, specifying both the resource and the scope. Differentiates from list_gtm_tags by focusing on a single tag's detailed configuration, and from get_gtm_trigger by covering the tag-level data including triggers.

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 a specific use case ('Use to inspect a tag flagged by audit_event_coverage'), giving practical guidance on when to apply the tool. Does not explicitly mention alternatives like list_gtm_tags for listing, but the purpose is clear enough that an agent can infer the appropriate context.

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

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

The annotations already declare readOnlyHint true, so the description doesn't need to repeat that it's read-only. However, the description adds valuable content about what the response includes (filters, validation settings, tags), which goes beyond the annotation. It does not mention any side effects, which is consistent with the read-only annotation. No contradiction.

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

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

The description is two sentences, direct, and free of unnecessary detail. It front-loads the primary action ('Get the full RAW configuration') and then adds relevant specifics about the content and purpose. Every word contributes to understanding the tool's function.

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

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

The description provides enough context for an agent to decide when to use this tool: it specifies the input (trigger ID) and the output (full config, including filters and associated tags) and the use case (diagnosis). It doesn't describe the output schema, but the tool has an output schema defined, so that is not a gap. The description adequately covers the tool's role in the larger workflow.

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

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

The schema has three parameters (trigger_id required, gtm_account_id and gtm_container_id with defaults), but the description does not explain any of them. The tool name suggests trigger_id is the main identifier, but the purpose of the account and container IDs is not clarified. Since the schema coverage is 0%, the description must compensate but fails to do so, leaving the agent to infer their roles from context.

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

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

The description clearly states the tool retrieves the full RAW configuration for a single GTM trigger, listing specific content (filters, validation settings, tag list). It distinguishes itself from list_gtm_triggers by focusing on one trigger's detailed config, making it unambiguous.

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

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

It explicitly says to use it to diagnose why a tag fires or not, providing a concrete use case. It does not explicitly say when to use list_gtm_triggers instead, but the sibling tool list_gtm_triggers is present, and the description's emphasis on 'single' and 'full configuration' implies the alternative. Slightly more guidance on when not to use would make it a 5.

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

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

Annotations already indicate readOnlyHint and destructiveHint, and the description adds context by specifying the returned data (name, description, fingerprint, entity lists). No contradiction with annotations.

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

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

Two concise sentences, no fluff, with the primary purpose stated upfront and the use case appended. Efficient and well-structured.

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

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

Covers purpose, use case, and returned data. Does not explicitly describe prerequisite steps beyond 'after list_gtm_versions', but is sufficient for an agent to decide when to call it. No mention of error conditions, but that is not critical for a simple 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 has zero descriptions for parameters, and the tool description does not explain the roles of gtm_account_id, gtm_container_id, or container_version_id. It only implies the version ID comes from list_gtm_versions, leaving the other two parameters ambiguous.

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 action ('Get'), the resource ('full metadata + entity counts for a single GTM container version'), and distinguishes it from siblings by specifying the use case ('Use after list_gtm_versions').

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 guidance on when to use the tool ('Use after list_gtm_versions when correlating a metric drop with a specific publish'), which differentiates it from listing or other get operations.

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 expands on the read-only behavior by detailing the returned data: 'Returns the list of entities (tags, triggers, variables) added, modified, or deleted relative to the live published version, plus any merge conflicts.' It also explains the is_clean flag semantics. This is consistent with the annotations (readOnlyHint=true, destructiveHint=false) and adds useful output 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 concise and front-loaded. The first sentence states the purpose, the second details the output, the third provides a usage scenario, and the fourth explains the is_clean field. Every sentence adds value with 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?

While the purpose and output are covered, the description is not fully complete because it omits parameter explanations and does not provide a full output schema. A user may not know how to correctly invoke the tool, especially with the optional parameters, and what exact structure the returned entities have. The description relies on prior knowledge of GTM workspaces.

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 description coverage is 0% for parameters, and the description does not compensate. workspace_id, gtm_account_id, and gtm_container_id are not explained at all. Even though the names are somewhat self-explanatory, the role of optional parameters like gtm_account_id and gtm_container_id, and their relationship to workspace_id, is ambiguous. This is a significant gap.

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

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

The description clearly states the tool's purpose: 'Show drafted-but-not-published changes in a GTM workspace.' This specifies both the action (show) and the resource (GTM workspace changes). It also differentiates from sibling tools like list_gtm_workspaces by focusing on the diff between the draft and published versions.

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 concrete use case: 'Common cause of "I edited a tag but nothing happened" — the workspace was never published.' This helps users understand when to use the tool. While it doesn't explicitly name alternative tools, it implies the scenario where checking uncommitted changes is needed, which is sufficient context.

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

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

The description aligns with the read-only and non-destructive annotations and adds context by explaining that compact=true changes the return format to a summary. This goes beyond the annotations and clarifies expected behavior without contradiction.

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

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

The description is concise and well-structured, with the purpose front-loaded, followed by return fields and the compact mode explanation. It avoids unnecessary fluff and communicates the essential information efficiently.

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

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

The description provides a solid overview of functionality and return data, and the output schema likely covers detailed fields. However, it lacks context on parameter defaults and date handling, which would be helpful for full usability. Still, it is adequate for a read-only reporting tool.

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

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

The description only explains the compact parameter, which is valuable, but provides no explanation for customer_id, date_range_start, or date_range_end. Given the schema has no descriptions (0% coverage), the description fails to add sufficient meaning for these parameters, leaving their format and semantics unclear.

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

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

The description clearly identifies the tool's purpose as retrieving keyword metrics, specifically mentioning quality scores and competitive data. This distinguishes it from sibling tools like campaign or ad performance, making the resource and scope explicit.

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 specific usage scenario (audits/overviews) with the compact=true option, giving concrete guidance on when to use the summary mode. However, it does not explicitly contrast with alternative tools like get_campaign_performance or get_search_terms, so some inference is required.

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

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

Beyond the annotations (read-only, non-destructive), the description discloses additional behavioral traits: data lags reality by ~30 minutes, and CRITICAL account-level issues can stop offers from serving entirely. This gives agents a clearer expectation of freshness and impact, going beyond the basic annotation hints.

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