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

No annotations are provided, so the description carries the burden of behavioral disclosure. It usefully explains the confirm flag's dry-run behavior ('must be true to apply, else dry-run'), which is valuable safety context. However, it does not disclose other behavioral traits such as duplicate handling, idempotency, permission needs, or effects on existing keywords.

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

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

The description is compact, front-loaded with the main purpose, and followed by a terse bullet-style argument list. Every line contributes meaning, with defaults and safety behavior included without unnecessary prose.

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

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

For a mutation tool with no annotations, the description covers the key call semantics, parameter meanings, and dry-run behavior. An output schema exists, so return-value details are not required. Mild gaps remain around explicit prerequisites and constraints, but the description is sufficient for an agent to invoke this tool correctly in most cases.

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

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

Schema description coverage is 0%, so the description must fully compensate. It does: every parameter is explained with domain meaning, including customer_id as a 10-digit account id, match_type enum values with a default, cpc_bid as optional per-keyword max CPC, and confirm as the dry-run gate. This adds real semantic value far beyond the raw schema.

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

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

The description states a clear, specific action: 'Add positive keywords to an ad group.' It identifies the resource and operation, and distinguishes the tool from its close sibling ads_add_negative_keywords by explicitly scoping to positive keywords. The name and description align 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?

The description does not explicitly say when to use this tool versus alternatives such as ads_add_negative_keywords or other ad-group mutation tools. The positive-keyword phrasing weakly implies usage context, but there is no guidance about when not to use it or which sibling to prefer in a given scenario.

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

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

With no annotations provided, the description carries the behavioral burden. It explicitly discloses the confirmation gate: 'confirm: must be true to apply (else dry-run).' This is a key side-effect disclosure. It does not cover duplicate handling or other edge behaviors, but the most important behavioral trait is present.

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

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

The description is short and well-structured: a one-line purpose followed by a clean argument list. Every sentence adds value, and there is no filler or redundant restating of the tool name.

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

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

All five parameters are explained with meaningful semantics, and the dry-run/apply behavior is explicitly documented. Since an output schema exists, return values do not need description coverage. For a write tool of this complexity, 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?

Schema description coverage is 0%, so the description is essential. It compensates fully by defining every parameter: customer_id format, ad_group_id target, keywords as a list, match_type allowed values, and confirm semantics. This goes well beyond the sparse JSON schema.

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

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

The description clearly states the action ('Add negative keywords to an ad group') and the resource it operates on. The parenthetical 'block wasteful queries' further clarifies intent and distinguishes it from the sibling tool ads_add_keywords.

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

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

The description gives clear context for when to use the tool: to block wasteful queries with negative keywords. However, it does not explicitly mention the alternative ads_add_keywords or state when not to use it, so it stops short of a 5.

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

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

Since no annotations are provided, the description carries the full burden. It clearly warns that applying can change bids, budgets, keywords, or ads, and explains the confirm/dry-run behavior. It does not mention permissions or possible irreversibility, but the core mutation side-effect is disclosed.

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

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

The description is short, front-loaded with purpose, and then transitions into a clean Args section. Every sentence adds value; there is no filler or redundant restating of the tool name.

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

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

With an output schema present, the description does not need to explain return values. It provides the essential operational knowledge for calling the tool correctly, though it stops short of explicitly warning that customer_id and resource_name are effectively required despite the schema showing defaults.

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 (0% coverage), so the description fully compensates by explaining customer_id as a 10-digit account id, resource_name as the recommendation, and confirm as the applied-vs-dry-run switch. This adds real meaning beyond the structured schema.

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

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

The description states a specific verb ('Apply'), a clear resource ('Google Ads Recommendation'), and references the source 'list_recommendations.' This distinguishes the tool from the many list/querying siblings and from other mutation tools in the set.

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

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

It provides clear context by telling the agent where resource_name comes from and that the tool performs a dry-run unless confirm is true. It does not explicitly list 'when not to use' or name alternative tools (e.g., manual bid/budget updates), but the context is strong enough for an agent to choose it appropriately.

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

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

With no annotations provided, the description carries the burden, and it does well: 'report' establishes a read-only operation, and the metrics list plus 'sorted by cost descending' and 'restrict to ENABLED campaigns' disclose concrete output and filtering behavior. It could go further on auth or omitted customer_id behavior, but the core behavioral profile is clear.

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

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

The description is minimal and efficient: the purpose and key metrics are front-loaded, and the Args section is neatly formatted with one line per parameter. Every sentence earns its place with no filler.

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

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

An output schema exists, so return value details are not required. The description covers all key metrics, sorting, and parameter semantics. The only gaps are the lack of explicit usage differentiation from sibling tools and the ambiguity around customer_id being nullable in the schema despite being described as the account id.

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%, but the description compensates fully by explaining every parameter: customer_id is a 10-digit account id, date_range is a GAQL date constant with examples, limit caps the number of campaigns, and only_active restricts to ENABLED campaigns. This adds meaning beyond the raw schema defaults and types.

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

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

The description clearly identifies the resource (campaign performance) and the specific metrics returned (impressions, clicks, CTR, cost, conversions, CPA, ROAS, conversion value), differentiating it from the sibling ads_keyword_performance tool. The word 'report' plus the metrics list leaves no ambiguity about what the tool does.

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

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

The description implies use for campaign-level performance reporting but does not explicitly state when to choose this over alternatives like ads_keyword_performance or ads_search_terms_report. It provides parameter context but no when-to-use or when-not-to-use guidance.

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

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

With no annotations, the description carries the full behavioral burden. It goes beyond the schema by disclosing that confirm must be true to apply and that otherwise it is a dry-run, which is a crucial side-effect trait. It does not cover auth or permissions, but the dry-run/apply behavior is meaningfully transparent.

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

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

The description is compact and well-structured: a single purpose sentence followed by a clean Args list. Every line earns its place, and the most important behavioral note (confirm/dry-run) is included without padding.

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

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

The description covers all parameters and the dry-run behavior, and an output schema exists so return values are covered. However, it leaves requiredness ambiguous (the schema lists 0 required params while the description only marks default_cpc_bid optional) and does not address when to choose this over the video ad group sibling.

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%, but the description compensates for every parameter: customer_id is a 10-digit account id, campaign_id is the parent campaign, default_cpc_bid is optional and for manual bidding, status is ENABLED|PAUSED, and confirm triggers the dry-run vs. apply behavior. This adds substantial meaning beyond the bare schema property names.

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

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

The description states a clear action and resource: 'Create an ad group inside a campaign.' It does not explicitly distinguish itself from the sibling ads_create_video_ad_group, but the resource wording is specific enough for a standard ad group, and the parameter list clarifies its 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?

No explicit guidance is given for when to use this tool versus alternatives such as ads_create_video_ad_group. The description implies usage by stating its purpose, but it never states prerequisites, exclusions, or selection conditions.

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

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

With no annotations provided, the description carries the full burden and exceeds expectations. It disclose several critical behaviors: created PAUSED to prevent spending, the confirm flag enables a dry-run mode, start_paused forces safety, and the VIDEO channel-type restriction. These are all non-obvious behaviors an agent must know to avoid unintended outcomes.

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 tightly organized with a clear 'Args:' listing, each line providing necessary detail without redundancy. The safety default and dry-run mechanism are front-loaded, and every statement adds value. No fluff or irrelevant content.

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

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

For a complex creation tool with 11 parameters, the description is comprehensive: it covers all inputs, default behaviors, safety mechanisms, and a critical platform limitation (VIDEO blocking). Although the return format is not described, the agent has enough to call it correctly and understand the implications. Everything else is adequately addressed.

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 is the only source of parameter guidance. It covers all 11 parameters with explicit explanations, including enum values, defaults, and nuanced notes (e.g., TARGET_CPV for skippable in-stream, manual CPV retired). The description fully compensates for the schema's lack of 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?

The description opens with a clear, specific action: 'Create a new campaign with its own daily budget.' It names the resource (campaign) and the key constraint (daily budget), and immediately distinguishes itself by stating the campaign is created PAUSED by default. This is unambiguous and differentiates it from campaign management tools.

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

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

The description provides contextual guidance by noting that Google blocks VIDEO campaign creation via API and directs the agent to use the UI for the shell, while mentioning video tools exist to populate it. This implies when to use this tool and when not to, though it does not explicitly reference sibling tools like ads_set_campaign_status for enabling. It gives clear context but lacks explicit exclusions or alternative routes for non-video cases.

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

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

With no annotations, the description carries the full burden, and it excels: it discloses that the ad is 'Created PAUSED by default,' that the confirm flag is a dry-run gate ('must be true to apply'), and that Google policy imposes headline/description limits. These are meaningful behavioral traits beyond the simple creation action.

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 sections for policy limits, args, and behavior. It is slightly repetitive (limits are stated in the header and then re-stated in the arg list), but every section adds useful detail for a 9-parameter tool, so it remains appropriately concise.

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

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

For a complex creation tool with 9 parameters, no annotations, and 0% schema coverage, the description is remarkably complete: it covers all parameter semantics, validation limits, default status, dry-run behavior, and required confirm flag. An output schema exists, so return-value documentation is not needed here.

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

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

Schema description coverage is 0%, so the description must fully compensate—and it does. It explains every parameter: customer_id, ad_group_id, final_url, headlines (3-15, <=30 chars), descriptions (2-4, <=90 chars), optional path1/path2 (<=15 chars), status values (ENABLED|PAUSED), and confirm semantics. This far exceeds schema-only info.

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

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

The description uses a specific verb and resource: 'Create a Responsive Search Ad (RSA) in an ad group.' This clearly distinguishes it from sibling creation tools like ads_create_ad_group and ads_create_video_ad, and leaves no ambiguity about what object is being created.

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

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

The description gives clear context for when to use the tool: when creating an RSA with headlines, descriptions, and a final URL. It does not explicitly mention alternatives or exclusions (e.g., 'for video ads use ads_create_video_ad'), so it falls just short of a 5, but the purpose is clear enough for an agent to select it appropriately.

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

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

With no annotations provided, the description carries the full behavioral burden. It does well by stating that ads are 'Created PAUSED' and that confirm must be true to apply while otherwise it is a dry-run. This discloses mutation safety and default state, which is valuable beyond the schema.

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

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

The description is front-loaded with the core purpose, then prerequisites and format mapping, followed by a compact, complete Args list. Each line earns its place, and the formatting makes the information easy to scan for an AI agent.

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 10 parameters with zero schema coverage, the description fully documents all of them, plus prerequisite lookup advice, format constraints, default status, and dry-run behavior. An output schema exists, so the description need not detail return values. No critical usage gap remains.

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

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

Schema description coverage is 0%, so the description must compensate entirely. It does: every parameter is explained, including customer_id format, video_asset_id type, video_format allowed values, status choices, and confirm's dry-run behavior. This adds meaning far beyond the raw schema field names.

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

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

The description opens with a specific verb and resource: 'Create a video ad in a video ad group, linking an existing YouTube video asset.' This distinguishes it from siblings like ads_create_video_ad_group and ads_create_responsive_search_ad. The boundary is clear without needing to open any other schema.

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

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

The description gives strong usage context: the YouTube asset must already exist, its id should come from a GAQL asset query, and video_format must match the ad group type. It does not explicitly name alternative tools or state when not to use this tool, but the context is clear enough to route an agent correctly.

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

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

No annotations are provided, so the description carries the behavioral burden. It discloses a dry-run/apply gate ('confirm: must be true to apply'), a prerequisite about the parent campaign bidding type, and the meaning of the default ad_group_type. It does not discuss side effects such as irreversibility or permission requirements, but the critical creation behavior is clear.

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

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

The description is front-loaded with purpose and routing, then a compact Args list. The enumerated ad_group_type values and confirm explanation are necessary because the schema lacks descriptions and enums, and there is no wasted prose.

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 7-parameter creation tool with no annotations, it covers purpose, alternative, preconditions, parameter semantics, enum choices, and confirmation behavior. An output schema exists, so return-value documentation is not required; it only leaves implicit which fields are mandatory.

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

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

Schema coverage is 0%, and the Args section fully compensates: it explains customer_id format, campaign relationship, cpv_bid units, valid ad_group_type values, status values, and the confirm dry-run behavior. This goes well beyond the schema's bare property names 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?

States a specific action ('Create a video ad group') and bounds it to a VIDEO campaign. The explicit 'Use this (not create_ad_group) for video campaigns' names the sibling it is distinct from, so an agent can disambiguate immediately.

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 an explicit routing rule: use this tool, not ads_create_ad_group, for video campaigns. It also gives conditional guidance (default ad_group_type for skippable in-stream TrueView, cpv_bid semantics) and a hard prerequisite (parent campaign VIDEO + MANUAL_CPV), so there is no ambiguity about when and how to invoke it.

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

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

With no annotations provided, the description carries the burden of communicating behavior. 'Get details' clearly indicates a read operation rather than a mutation, and the listed fields define what the agent can expect to learn. It does not discuss auth or edge cases, but for a simple getter the behavior is reasonably transparent.

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

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

The description is compact and front-loaded with the core purpose, followed by the only parameter's semantics. Every sentence adds value and there is no redundant phrasing.

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 single-parameter read tool with an output schema present, this description is complete: it states what is retrieved, the parameter format/default, and the scope. Nothing needed for correct invocation appears missing.

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

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

Schema coverage is 0%, but the description fully compensates: it explains customer_id is a 10-digit account id, that dashes are acceptable, and that it defaults to the environment default. This adds meaningful format and fallback semantics beyond the schema.

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

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

The description starts with a specific verb and resource: 'Get details for a single account.' It enumerates the returned fields (name, currency, time zone, status, etc.) and the 'single account' scope differentiates it from sibling tools like ads_list_accounts.

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

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

The 'single account' framing clearly signals this is for retrieving one account's detail, with the optional customer_id defaulting to the environment default. It does not explicitly name alternatives or provide exclusion criteria, so it stops short of fully explicit routing 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?

There are no annotations, so the description bears the full behavioral burden. It states that this is a read-style lookup returning monthly volume and competition and explicitly warns that no idea expansion happens; however, it does not mention permissions, rate limits, or how missing/invalid keyword IDs are treated. The output schema covers return shape, keeping the gap moderate.

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

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

The description is short, front-loads the core behavior and scope in the first sentence, adds an explicit use case, and then lists the args in a scannable block. Every sentence earns its place with no repetition.

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

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

For a read-only historical lookup tool with an output schema, the description covers purpose, scope, use case, and all parameters. It could be more complete by naming the sibling keyword-ideas tool or noting account prerequisites, but the agent has enough to select and invoke it correctly.

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

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

Schema description coverage is 0%, and this description compensates by documenting all four parameters with useful semantics: customer_id is a 10-digit account id, keywords are an exact list, location_ids get a concrete example ([2840] = US), and language_id gets a constant example (1000 = English). It doesn't explain null defaults or how to discover valid ID values, but it adds substantial meaning beyond the bare schema.

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

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

The description opens with a specific verb+resource/operation ('Get historical monthly search volume + competition') and narrows scope to 'a specific list of keywords (no idea expansion)', which clearly distinguishes it from the sibling tool for idea generation (ads_keyword_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?

'Use to size demand for exact terms you already have' plus the explicit '(no idea expansion)' tells the agent when this tool is appropriate and implies it is wrong for exploratory keyword discovery. It stops short of naming an alternative tool, so it lacks the fully explicit routing of a 5.

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

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

With no annotations, the description carries the behavioral burden. It usefully notes that any account with Planner access works and that omitting location_ids removes geo constraints. However, it does not explicitly state that at least one seed source should be provided, nor does it mention read-only behavior, failure modes, or limits beyond the limit parameter.

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

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

The purpose is front-loaded in one sentence, followed by a clean, scannable Args block. Every line adds information (examples, defaults, optionality), with no filler or repetition of schema types.

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

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

Given the 7 parameters and an output schema that covers return shape, the description covers inputs thoroughly and gives practical examples. The only notable gap is not explicitly stating that at least one seed source (keywords or page_url) is expected despite no schema-required parameters.

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

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

Schema description coverage is 0%, and the description fully compensates by explaining every parameter with examples and defaults: customer_id, seed_keywords with example values, page_url as optional, location_ids with geo ID examples, language_id with constants, limit, and include_adult with its default. This adds substantial meaning beyond the bare schema.

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

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

The description states a specific verb and resource: 'generate keyword ideas with avg monthly searches, competition level, and top-of-page bid range' and identifies itself as the 'Keyword Planner research tool.' It is clear, but it does not explicitly contrast with sibling tools like ads_historical_search_volume or ads_keyword_performance, so it stops short of full differentiation.

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 opening 'Keyword research' and 'This is the Keyword Planner research tool' imply when to use it, and the seeding options are described. However, there is no explicit statement of when not to use it or which sibling should be chosen for historical volume, performance, or adding keywords.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It implies a read-only performance report and defines the scope of data, but it does not explicitly state that it is non-mutating, how results are aggregated, or what happens when filters are omitted. The report-like nature is strongly implied, but some behavioral details remain implicit.

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

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

The description is compact and front-loaded, with the data scope and metrics in the first line followed by a concise argument list. There is no filler or redundant repetition of schema information; every sentence adds useful signal.

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, the description does not need to explain return values, and it covers purpose, metrics, and all parameter semantics. The main remaining gap is the lack of explicit guidance comparing this to sibling reporting tools and clarifying the practical requirement of customer_id, but overall it is sufficient 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 zero description coverage, but the description compensates by explaining all four parameters: customer_id format, date_range as a GAQL constant, campaign_id as an optional filter, and limit as a cap. It does not clarify whether customer_id is practically required despite its nullable default, but the schema supplies the 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 identifies the tool as a keyword-level performance report by naming the exact metrics returned: text, match type, quality score, clicks, cost, conversions, and CPA. This distinguishes it from sibling tools like ads_campaign_performance, though it lacks an explicit action verb such as 'retrieve' or '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 explicitly states a use case: 'Useful to find wasteful or high-performing keywords.' This gives an agent clear context for when to select this report, but it does not mention alternatives or exclusion conditions, so it falls just short of full routing 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?

There are no annotations, so the description carries the behavioral burden. It discloses an important environment-dependent behavior: the result set changes depending on whether GOOGLE_ADS_LOGIN_CUSTOMER_ID points to an MCC account or not. As a listing tool, 'List' and 'available to use' also convey a read-only, no-mutation operation, which is sufficient for this simple scope.

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

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

Three concise sentences, each earning its place: the first states the core purpose, the second explains environment-scoped behavior, and the third gives the use case and next-step value. The most important action and resource are front-loaded.

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

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

For a no-argument discovery tool with an output schema available, this description is nearly complete. It explains the data returned, the environment variable that changes behavior, and how the output should be used. It could explicitly mention that this is a read-only operation, but the verb 'List' and the phrase 'available to use' make that sufficiently clear.

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

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

The tool has zero parameters, so parameter explanation is unnecessary. The description still clarifies what the tool returns (customer ids and names), which is more relevant than input semantics here. The 0-parameter baseline of 4 is appropriate.

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

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

The description opens with a specific action and resource: 'List Google Ads accounts (customer ids + names) available to use.' It also states the exact output shape (customer ids and names) and positions the tool as the discovery entrypoint for other tools, which clearly separates it from siblings like ads_get_account_details or ads_run_gaql.

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

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

The description gives concrete guidance: when GOOGLE_ADS_LOGIN_CUSTOMER_ID points to an MCC, the tool returns the full manager tree, and otherwise it falls back to directly accessible customers. It also says 'Start here to discover the 10-digit customer_id for other tools,' which tells the agent the correct first step. It doesn't explicitly mention when not to use sibling tools, but the context is strong.

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

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

With no annotations provided, the description carries the full burden. It discloses the output structure (resource_name + type) and implies a read-only listing operation. It also hints at the connection to apply_recommendation. It does not mention auth, rate limits, error behavior, or pagination, but for a simple listing tool these are minor omissions given the clear purpose.

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 efficient: one paragraph explains the purpose and output, another lists the two arguments with brief semantics. No unnecessary detail, and the purpose is front-loaded. It earns every sentence.

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

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

Given it is a simple listing tool with only two parameters and an output schema (not shown but indicated), the description provides enough for an agent to call it correctly: it states what it does, the input parameters, and how the output relates to apply_recommendation. It lacks explicit error handling or auth notes, but these are not critical for a basic list operation.

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

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

The description adds meaning beyond the schema by explaining customer_id as a 10-digit account id and limit as max recommendations. This goes beyond the bare type definitions. It does not clarify that customer_id is optional (schema default null) or that limit has a default of 50, but the core semantics are covered.

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 Google's optimization Recommendations for the account, explicitly tying it to the Ads UI Recommendations tab and giving concrete examples of recommendation types (keywords, budgets, bids, ad strength). It also notes that each result contains a resource_name and type, which directly distinguishes it from apply_recommendation and other list 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 implies a workflow by stating that the returned resource_name and type can be passed to apply_recommendation, giving some context on when to use this tool. However, it does not explicitly state when to use it versus alternatives, nor does it mention exclusions or conditions. There is no comparison with sibling list tools like ads_list_accounts.

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

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

With no annotations available, the description carries the full burden of behavioral disclosure, and it does this well: it reveals that the tool aggregates multiple diagnostic categories (policy, budget, pause anomalies, optimization score) into a synthesized overview rather than returning raw data. The main gaps are that it never explicitly states it is read-only/side-effect-free, and it doesn't say what happens when the optional customer_id is omitted.

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 and front-loaded: the opening sentence states the purpose, the four bullets are scannable and each adds distinct information, and the usage directive and argument note each earn their place. No filler or repetition of schema content.

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

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

For a simple one-parameter tool with an output schema present, the description covers the core needs: what it checks, what it surfaces, when to run it, and the argument format. Remaining gaps are minor — no explicit read-only confirmation, no behavior when customer_id is not supplied, and no differentiation from the closely-adjacent ads_list_recommendations sibling. The output schema relieves it of documenting 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?

Schema description coverage is 0%, so the description must compensate — and it does: 'customer_id: 10-digit account id' adds the format constraint (10-digit) and semantic meaning (account id) that the bare string/null schema lacks. It could go further by explaining that the parameter is optional and what behavior results from omitting it, but for a single-parameter tool the compensation is adequate.

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 purpose (health/status monitor) with a concrete verb ('surfaces issues') and a precise resource (account health). The four bullet points define exactly what it detects — disapproved/limited ads, budget-limited campaigns, paused campaigns that recently spent, and optimization score — which clearly distinguishes it from performance-report siblings like ads_campaign_performance or ads_keyword_performance. The 'quick what's wrong / what to fix overview' framing further pins down 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 gives an explicit usage instruction: 'Run this for a quick what's wrong / what to fix overview.' This provides clear context for when an agent should invoke it. However, it does not name alternatives or state when NOT to use it — e.g., it doesn't contrast with ads_list_recommendations or ads_campaign_performance for deeper per-metric analysis.

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

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

With no annotations, the description carries the behavioral burden. It explicitly identifies the tool as a read tool and discloses the client-side row cap with a default of 200. It doesn't cover error handling or authentication, but the read-only nature and row-limiting behavior are the key traits an agent needs.

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

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

Well-structured: purpose sentence, usage note, a clear example query, then a tight Args list. Every line earns its place and the example adds practical value without fluff.

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

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

For an arbitrary-query tool, the description covers the essentials: what it does, when to use it, how to construct the query, account id format, and row limits. The output schema already exists, so return-value documentation is not needed. Nothing critical is missing.

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

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

Schema description coverage is 0%, so the description must fully document parameters. It does: customer_id is explained as a 10-digit account id with dashes allowed, query is 'full GAQL query string,' and limit is a max-rows client-side cap with default 200. This fully compensates for the empty schema descriptions.

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

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

Opens with a specific verb and resource: 'Run an arbitrary GAQL query and return rows.' The 'most flexible read tool' framing explicitly differentiates it from narrower reporting siblings like ads_campaign_performance and ads_keyword_performance, and the example query makes the purpose concrete.

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

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

States clearly to use it for 'any custom report,' which is actionable context. It does not explicitly name alternatives or exclusion conditions, but the custom-vs-prebuilt distinction is strong enough for an agent to route correctly.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses what data the report returns (queries, cost, conversions) and frames it as an analysis/reporting read. It does not mention permissions, data-availability windows, or result shaping, but for a straightforward report tool the core behavior is adequately disclosed with 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?

Purpose is front-loaded in the opening sentence, the usage guidance follows in one clause, and a clean args block completes it. No filler; every sentence carries weight.

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

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

With an output schema present and all four parameters documented with format details, the definition is largely complete for a report tool. The only minor gap is not flagging potential data-availability limits of search-terms reports, which is a small omission against an otherwise thorough definition.

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

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

Schema description coverage is 0%, so the description must compensate — and it fully does. It documents every parameter with concrete format guidance: '10-digit account id', 'GAQL date constant (e.g. LAST_30_DAYS)', 'optional campaign filter', and 'max rows'. This adds real semantic meaning beyond the bare schema titles (Limit, Date Range, Campaign Id, Customer Id).

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

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

States a specific resource ('actual queries that triggered ads') with clear output metrics (cost, conversions), and implicitly differentiates from siblings — it is distinct from ads_keyword_performance (keyword-level), ads_campaign_performance (campaign-level), ads_keyword_ideas (suggestions), and ads_historical_search_volume (volume data). An agent can tell exactly what this tool returns.

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

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

Explicitly names two use cases: mining new keywords (high converters) and mining negatives (spend, zero conversions). This tells an agent when to reach for this tool. It does not explicitly name alternatives or exclusions, but the use-case framing is strong enough that an agent could route correctly among the ads_* siblings.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It states that this is a 'Money change' and explains the dry-run vs. apply behavior via the confirm flag: 'must be true to apply (else dry-run).' This is meaningful behavioral context for a mutating financial operation, though it does not address permissions, reversibility, or 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 tightly structured: a one-sentence purpose, a short 'Money change' flag, and a clean argument list with inline explanations. Every sentence earns its place and there is no redundant or filler content.

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

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

Given the moderate complexity, no annotations, and an output schema, the description covers the essential details: the operation, the manual-bidding restriction, the monetary impact, the dry-run confirmation behavior, and all parameters. It does not state permission requirements or potential side effects, but the available context is otherwise sufficient for correct invocation.

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

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

Schema description coverage is 0%, so the description must compensate, and it does. Every parameter is explained: customer_id as a 10-digit account id, ad_group_id as the ad group id, cpc_bid as the new max CPC in account currency with an example, and confirm as the required flag to apply versus dry-run. This adds substantial meaning beyond the bare schema.

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

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

The description names a specific verb and resource: 'Set an ad group's default max CPC bid,' with the important qualifier 'manual bidding only.' This clearly distinguishes it from sibling tools like ads_set_campaign_bidding_strategy, ads_update_campaign_budget, or ads_set_campaign_status, and the 'Money change' tag reinforces that it is a mutating monetary operation.

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

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

The description gives a clear usage condition: 'manual bidding only,' which tells the agent when this tool applies and implicitly when it should not be used. It does not name explicit alternatives or contrast with sibling bid-related tools, so it falls short of full guidance, but the context is sufficiently clear for an agent to select it.

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

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

With no annotations provided, the description carries the full burden. It discloses the dry-run behavior via the confirm flag and the three possible statuses, which is useful. However, it does not disclose side effects of 'remove' (e.g., whether it is reversible, whether it deletes permanently), nor does it mention permission requirements or rate limits. The description adds some behavioral context but not rich 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 compact and front-loaded with the core action, followed by a concise parameter list. Every sentence earns its place, and the dry-run note is important. It could be slightly more structured, but it is efficient.

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

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

The tool has an output schema, so return values are covered elsewhere. The description covers the essential parameters and the confirm dry-run behavior. However, it lacks guidance on when to use this tool vs siblings, and it does not explain the implications of 'remove' or any prerequisites. For a mutation tool with no annotations, this is a moderate gap.

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

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

Schema description coverage is 0%, so the description must compensate. It does explain all four parameters: customer_id, ad_group_id, status, and confirm, including the confirm dry-run semantics. However, it does not add detail beyond the schema's names and defaults, such as the format of customer_id (10-digit) is given, but ad_group_id format is not. The description is adequate but not rich.

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

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

The description states a clear verb ('Enable, pause, or remove') and a specific resource ('ad group'), which distinguishes it from sibling tools like ads_set_campaign_status and ads_set_ad_status. It could be slightly more explicit about the 'remove' semantics (removed vs deleted), but the core purpose is unambiguous.

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

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

The description implies usage by listing the required arguments and the confirm flag, but it does not explicitly state when to use this tool versus alternatives like ads_set_ad_status or ads_set_campaign_status. The dry-run behavior is mentioned, which gives some context, but there is no explicit when/when-not guidance.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It explicitly discloses that confirm must be true to apply (otherwise a dry-run is performed) and enumerates the three allowed statuses, including REMOVED, which signals modify/remove behavior. It does not cover reversibility or permissions, but the dry-run/confirm safety gate is a significant and well-disclosed trait.

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 one-sentence summary followed by a tight five-item argument list with no filler or repetition. The primary action is front-loaded and every line contributes new, relevant information.

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

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

Given 0% parameter coverage and no annotations, the description covers all parameters and the key behavioral caveat (confirm vs dry-run). It does not specify optionality or prerequisites, and it doesn't explain return values in the text, but the presence of an output schema covers the return format. Overall it is sufficient for a mutation tool with a safety gate.

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

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

Schema description coverage is 0%, and the description compensates by documenting every parameter: customer_id as a 10-digit account id, ad_group_id as the group the ad belongs to, ad_id, status with its allowed values, and confirm with the dry-run/apply semantics. This adds meaning well beyond the bare names and defaults in the schema, especially for status and confirm.

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

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

The opening line 'Enable, pause, or remove a specific ad' states a concrete action and resource, and 'specific ad' clearly distinguishes this from sibling status tools like ads_set_campaign_status and ads_set_ad_group_status. The verb phrase and scope leave no ambiguity about the tool's purpose.

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

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

The description states what the tool does to an ad but gives no explicit guidance on when to prefer it over the many sibling status tools. The only context is the scope 'specific ad', which implies it is not for campaign- or ad-group-level status changes, but no alternatives or exclusions are named. Thus usage is implied rather than clearly stated.

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

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

With no annotations, the description carries the behavioral burden. It discloses that only the bidding strategy field is updated, switching resets the previous one, and the operation is bid-affecting; it also surfaces the confirmation/dry-run mechanism. It could add permission/reversibility info, but these are substantial disclosures.

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

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

The description is front-loaded with the main verb and scope, followed by a compact behavioral note and a clearly formatted Args list. Every sentence adds operational value without padding.

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

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

For a mutation with seven parameters and no required fields declared in the schema, the description covers every caller decision: strategy choices, conditional targets, the mandatory ceiling for TARGET_SPEND, and the confirmation requirement. An output schema exists, so return semantics need not be spelled out.

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

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

Schema coverage is 0%, so the description is the only source of parameter meaning. It defines all seven parameters, lists the allowed bidding_strategy values, explains optional targets, and calls out that cpc_ceiling is required for TARGET_SPEND because Google rejects an unset ceiling. This fully compensates for the schema's lack of descriptions.

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

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

The description opens with a specific verb ('Change') and identifies the exact resource: an existing campaign's standard (non-portfolio) bidding strategy. This distinguishes it from sibling tools like ads_set_campaign_status or ads_update_campaign_budget and clarifies that portfolio strategies are out of 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 clearly frames the tool for changing standard campaign bidding strategies and states that confirm=false performs a dry-run while true applies the change. It does not explicitly name alternative tools for portfolio strategies or related ad-group bid changes, but the context is clear enough for selection.

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

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

With no annotations, the description carries the disclosure burden and does a good job: it reveals the dry-run guard ('confirm must be true to apply'), the allowed status transitions including REMOVED, and the customer_id format. However, it stops short of explicitly warning that REMOVED is likely destructive/irreversible or noting any permission requirements.

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

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

The description is a tight, front-loaded action sentence followed by a compact Args block. Every line adds information, with no filler or repetition of the schema.

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

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

For a simple status-mutation tool, the description covers purpose, parameter semantics, and the dry-run safety mechanism, and an output schema exists so return details need not be specified. It lacks usage-differentiation guidance and an explicit note about the destructive nature of 'REMOVED', leaving a small but meaningful gap.

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

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

Schema coverage is 0% and the schema has no enum values, so the description fully compensates: it explains all four parameters, including the 10-digit customer_id requirement, status values (ENABLED/PAUSED/REMOVED), and the semantic meaning of confirm as a dry-run switch. This is exactly what an agent needs beyond the bare schema.

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

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

States a specific verb and resource: 'Enable, pause, or remove a campaign.' The resource is explicit in both the name and description, making it easy to distinguish from ads_set_ad_group_status and ads_set_ad_status. The phrase 'Core status-monitoring action' is slightly odd for a mutating action, but the main purpose is unambiguous.

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

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

Provides no guidance on when to use this tool versus alternatives. It does not mention the sibling tools for ad group status or ad status, nor any conditions that would make campaign-level control preferable. The 'Core' label implies centrality but does not explain selection criteria.

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

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

With no annotations, the description carries the behavioral disclosure burden. It does well by flagging 'Money-affecting change' and explaining that confirm must be true to apply, with anything else acting as a dry-run. It does not mention permissions, reversibility, or shared-budget implications, but the key safety-relevant behaviors are disclosed.

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

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

The description is compact and front-loaded: the first sentence states the operation, the second flags risk, and the Args block cleanly maps to the schema. Every sentence earns its place with 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?

The description is sufficient to invoke the tool correctly, covering all parameters and the critical dry-run/apply behavior. The only gap is lack of explicit when-to-use guidance relative to the many sibling ad-management tools, which is minor given the operation is self-descriptive and an output schema exists.

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

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

Schema description coverage is 0%, and the description compensates fully by documenting all four parameters. It adds crucial meaning beyond the raw schema: customer_id is specified as a 10-digit account id, new_daily_budget gets a concrete example, and confirm's true-only-applies behavior is 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 states a specific action ('change') on a specific resource ('campaign's daily budget') with a clear unit ('account currency'). It distinguishes itself from sibling budget/status/bidding tools by naming the exact budget amount being updated.

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

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

The intended use is implied by the action statement, but no explicit guidance is given for when to choose this tool over alternatives like ads_set_campaign_status or ads_set_campaign_bidding_strategy. The confirm/dry-run note provides operational context, but the description does not state exclusions or alternative routing.

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

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

The description discloses key behavioral traits beyond the schema: archive is permanent, the parameter name cannot be reused, and confirm=true is always required. This is valuable context that the schema does not provide. It doesn't mention side effects like whether existing reports break, but the disclosed permanence and irreversibility are significant.

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

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

The description is two sentences with no wasted words. It front-loads the core action, then packs critical caveats (permanence, no reuse, confirm requirement) into the second sentence. Every sentence earns its place.

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

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

Given the tool's complexity (3 params, 1 required) and the presence of an output schema, the description covers the most important behavioral caveats. It doesn't explain what the response looks like, but the output schema exists. The main gap is not explaining property_id's role, but the tool is still callable with just dimension_id. Overall, it's complete enough for an agent to invoke correctly.

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

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

Schema description coverage is 0%, so the description must compensate. It mentions confirm=true as a requirement, which adds meaning to the confirm parameter. However, it doesn't explain dimension_id or property_id semantics beyond what the schema names imply. The description adds some value but leaves the agent to infer the meaning of the other parameters.

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

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

The description clearly states the action ('Archive a custom dimension') and the resource, distinguishing it from sibling tools like ga4_create_custom_dimension and ga4_list_custom_dimensions. It also adds a critical distinction: GA4 has no delete, only archive, which clarifies the tool's unique 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 implies when to use this tool (when you need to archive a custom dimension) and explicitly notes that archive is permanent and the parameter name cannot be reused, which serves as a caution. It doesn't explicitly name alternatives or say when not to use it, but the context is clear enough for an agent to select it appropriately.

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

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

No annotations are provided, so the description carries the full burden. It discloses the confirm guard, membership_duration_days range and RLSA threshold, and the exact membership semantics of event_name_filter. It could say more about side effects or failure modes, but the output schema covers return shape and the core behavioral safety is well communicated.

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

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

The description is front-loaded with a one-sentence purpose, followed by scope limits and a compact Args block. The filterClauses rationale is useful but slightly wordy; still, every sentence contributes to either correct usage or safe invocation.

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

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

The description covers the essential behavioral and usage context for a flat 6-parameter create tool, and the output schema means return values do not need to be described. The main gap is property_id's role and fallback behavior, but the clear arg names and strong usage guidance make the description largely complete.

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

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

Schema description coverage is 0%, so the description must compensate. It adds real meaning for membership_duration_days, event_name_filter, and confirm, but it does not explain property_id at all and leaves display_name/description to name-based inference. This partial compensation keeps it adequate but not complete.

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

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

Description states a specific action ('Create a simple event-based audience') with an example condition, making the tool's purpose immediately clear. It also differentiates itself from the GA4 UI by explicitly limiting scope to single-event conditions, so an agent can tell it apart from list/read siblings and from a manual UI workflow.

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

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

The description explicitly tells the agent when to use this tool versus when to avoid it: anything beyond a single event condition should be built in the GA4 UI. It repeats this guidance in the event_name_filter arg and warns about the filterClauses shape being error-prone, giving strong routing context.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. It adds non-obvious behaviors: the confirm flag must be true to actually create, and the event must already be firing or GA4 rejects it. It also surfaces the dependency on the Ads link. It does not fully cover permissions or idempotency, but the most operationally critical behaviors are disclosed.

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

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

The description is compact and front-loaded, with a functional first sentence followed by a tight Args list containing precise guidance. No filler or redundant restatement of the tool name or schema.

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

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

For a create operation with an output schema, the description covers the core prerequisites, confirmation behavior, and the Ads link dependency. The main gap is the undocumented property_id parameterhol, but since it is optional with a default of nullressing, the description is still largely complete for correct invocation.

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

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

The schema has 0% description coverage, so the description must compensate. It does this well for event_name (exact dataLayer/gtag name, examples, rejection condition) and confirm (must be true). However, property_id is present in the schema but completely absent from the description, leaving one parameter under-documented.

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

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

The description uses a specific verb ('Mark an event as a conversion') with the resource named (GA4 conversion/Key event) and explains the downstream purpose (feeds Ads bidding and Conversions column). It clearly distinguishes this tool from related GA4 tools like ga4_list_conversion_events and ga4_delete_conversion_event, and even references ga4_create_google_ads_link as a dependency.

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 precondition: the event must already be firing at least once, otherwise GA4 rejects it. It also states the GA4↔Ads link requirement and points to the specific sibling tool needed to establish that link. It does not explicitly list exclusions or when to prefer an alternative, but the context is actionable.

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

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

With no annotations, the description carries the behavioral burden. It discloses the confirm guard ('must be true to actually create'), implies mutating action, and warns against duplicate predefined dimensions. It doesn't mention persistence/irreversibility, but the explicit confirm flag is a strong safety signal.

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

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

The purpose and caveat are front-loaded, and the Args block is compact with no filler. Every sentence earns its place.

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

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

It is well-scoped for a 6-parameter tool but not complete: the required display_name and the optional property_id/description remain unexplained, and it doesn't direct the agent to ga4_list_custom_dimensions as a precursor. Output schema and sibling names fill part of the gap, but not all.

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

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

Schema coverage is 0%, and the description compensates for parameter_name, scope (with an explicit enum), and confirm. However, it omits the required display_name as well as property_id and description, so an agent gets only partial parameter guidance.

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

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

The description states a specific verb ('Register') and resource ('custom dimension') and explains the outcome ('an event parameter becomes reportable'). It doesn't explicitly call out sibling alternatives like ga4_create_custom_metric or ga4_list_custom_dimensions, so it falls just short of full differentiation.

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

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

It gives an explicit pre-check: verify predefined dimensions don't already cover the parameter, with the rationale that duplicating is wasteful. It doesn't say when to prefer the custom-metric sibling or archive/list tools, but the context is clear enough for a first-time caller.

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

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

No annotations were provided, so the description must carry the full behavioral burden. It only states 'Register a custom metric' and leaves out the fact that creation likely requires confirmation (confirm parameter), where property_id is resolved, and whether the call can overwrite or is idempotent. For a state-changing tool this is a substantial gap.

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

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

The description is a single, front-loaded sentence without filler. Every word earns its place: the verb, the resource, and the distinguishing trait are all present, and there is no restatement of the tool name.

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

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

For a 6-parameter creation tool with no annotations, the description is far from complete. It doesn't mention the confirmation flag, default property_id source, measurement_unit enum semantics, or naming rules for parameter_name. Even though an output schema exists, an agent would still have to guess at critical invocation details.

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

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

The schema has 0% description coverage and the tool description does not compensate: it says nothing about parameter_name, display_name, measurement_unit, confirm, description, or property_id behavior. The only added semantic is that the metric is a numeric event parameter, which loosely clarifies parameter_name but leaves the rest to name guessing.

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

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

The description uses a specific verb ('Register') and resource ('custom metric'), then disambiguates the resource with 'a numeric event parameter, e.g. a lead value'. That parenthetical is precisely what separates a custom metric from the sibling ga4_create_custom_dimension, so an agent can pick correctly without opening schemas.

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

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

There is no when-to-use or when-not-to-use guidance, no mention of prerequisites, and no mention of alternatives beyond the implied GA4 domain. The 'lead value' example suggests a use case but does not give enough context to choose this over a custom dimension or a conversion event conceptually.

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

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

With no annotations provided, the description carries the full behavioral burden. It does disclose one genuinely useful behavior - confirm must be true to actually create - which is a safety gate not obvious from the schema alone. However, it omits other behavior such as whether creation is reversible, error outcomes, or what the response contains, so coverage is partial.

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

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

The description is efficient and front-loaded: the key behavioral fact (measurement ID minting) appears immediately, followed by a compact Args list. Each parameter line earns its place. It is slightly format-heavy with the 'Args:' block, but nothing is wasted and it reads clearly.

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 five parameters, no annotations, and the presence of an output schema (so return values need no explanation), the description covers most of what an agent needs: the confirm gate, required URI, and stream types. The undocumented property_id parameter, absent from both schema semantics and description, leaves the call incomplete in one area.

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

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

Schema description coverage is 0%, so the description must compensate. It explains four of five parameters with real semantics: display_name as the GA4 UI label, default_uri as the site root URL required for web streams, stream_type's three enum values, and confirm's gating role. Only property_id is left unexplained, leaving a small 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?

States a specific verb and resource ('Create a data stream') and goes further to explain the concrete effect: for WEB_DATA_STREAM it mints the measurement ID (G-XXXXXXX) that a GTM tag or gtag.js points at. This is a specific, distinguishing detail that sets it apart from the sibling create/update/delete/list data stream 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 arg explanations give partial usage guidance (default_uri is 'required for WEB_DATA_STREAM', stream_type lists the three valid values), which helps an agent build a correct call. However, there is no explicit when-to-use versus when-not-to-use guidance, and no alternatives are named, so the usage context is implied rather than stated.

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

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

No annotations are provided, so the description carries the burden. It discloses side effects (auto-audiences created, conversion import behavior), the confirm flag requirement, and the customer_id format. It does not mention whether the operation is reversible or what the response contains, but the output schema exists and the key behavioral traits are covered.

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

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

The description is compact and front-loaded: the main action and side effects come first, followed by a concise Args section. Every sentence adds value, and the confirm warning is placed where it is most likely to be noticed.

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

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

For a 4-parameter tool with an output schema and no annotations, the description covers the critical behavioral context (auto-audiences, conversion import, confirm requirement). It could be more complete by explaining property_id and ads_personalization_enabled, but the core call semantics are sufficiently clear.

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

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

Schema description coverage is 0%, so the description must compensate. It explains customer_id format ('10-digit Ads customer id, dashes ok') and confirm semantics ('must be true to actually create'). It does not explain property_id or ads_personalization_enabled, but those are reasonably inferable from their names 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 the verb ('Link'), the resource ('a Google Ads account to a GA4 property'), and the key side effects (creates auto-audiences and enables conversion import). It is distinguishable from siblings like ga4_list_google_ads_links and ga4_delete_google_ads_link.

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 what the link accomplishes and notes the biddable-in-Ads prerequisite for conversions to import. It does not explicitly say when to use this tool versus alternatives, but the context is clear enough for an agent to infer this is the creation action among the google_ads_links 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?

No annotations are provided, so the description carries the behavioral disclosure burden. It usefully reveals the confirm guardrail, which prevents accidental creation when false, and indicates that creating a property is the actual side effect. However, it does not state what happens when confirm is false, whether the operation is reversible, or what permissions are needed. This is adequate but not fully transparent.

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

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

The description is well-structured and efficient. The one-sentence purpose is followed by a compact Args list, with each parameter receiving only the necessary explanatory detail. There is no filler or repetition of schema defaults, and the most critical usage detail (confirm must be true) is clearly highlighted.

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

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

The description covers all six parameters, identifies the prerequisite account_id source, and notes the confirm guardrail, which is enough for an agent to make a correct call. Since an output schema exists, the description does not need to explain return values. Minor gaps remain: the description gives only examples for industry_category rather than a full enumeration, and the behavior when confirm is false is not described.

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

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

Schema description coverage is 0%, so the description must fully explain the parameters, and it does. Every parameter is covered: account_id is identified as numeric and sourced from ga4_list_accounts, display_name is tied to the GA4 UI, time_zone uses IANA examples, currency_code uses ISO examples, industry_category is marked optional with examples, and confirm is explained as a required true flag for actual creation. This adds substantial meaning beyond the bare schema.

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

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

The description opens with a specific verb and resource: 'Create a new GA4 property under an account.' This clearly distinguishes it from sibling tools like ga4_create_data_stream or ga4_create_conversion_event, which create different GA4 resources. The account scope is also stated, so an agent knows exactly what operation this tool performs.

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

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

The description provides clear context for when to use the tool by explaining the relationship to ga4_list_accounts: the account_id comes from that tool. It also tells the agent that confirm must be true to actually create, which is important operational guidance. It does not explicitly name alternatives or exclusions, but no sibling tool offers the same create-property operation.

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

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

With no annotations, the description carries the behavioral disclosure burden. It adds meaningful context by requiring confirm=true and precisely defining event_id as the numeric last path segment of conversionEvents/<id>, not the event name. It could mention irreversibility or permissions, but the confirm requirement and clear action provide adequate transparency.

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

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

Extremely concise and front-loaded: the core purpose comes first, followed by the critical confirm requirement, then a focused Args block. No filler or redundant restatement of the schema.

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

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

For a single-required-parameter delete-style operation, the description covers the essential call requirements. property_id is left undocumented, and side effects are not elaborated, but the presence of an output schema means return values need not be covered.

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

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

Schema description coverage is 0%, so the description compensates well for event_id by explaining its source, type, and exact location. It also clarifies that confirm must be true. The one gap is property_id, which is not explained at all.

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

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

The description states a specific verb ('Un-mark') and resource ('an event as a conversion'), clearly identifying the tool's action. It distinguishes itself from sibling tools like ga4_create_conversion_event and ga4_list_conversion_events by describing the inverse operation.

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

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

Gives clear invocation context: confirm must always be true, and event_id must come from ga4_list_conversion_events. It does not explicitly state when-not-to-use or name alternatives, so it stops short of a 5.

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

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

With no annotations, the description carries the full behavioral burden and does so well. It warns that deleting the wrong stream orphans GTM tags/gtag.js calls and that the operation fails silently rather than erroring, which is critical, non-obvious behavior for an agent to know.

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

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

Two short sentences, front-loaded with the core purpose and followed by the one indispensable warning. Every clause earns its place; there is no filler or restating of schema fields.

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

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

The description covers the destructive consequence and the required confirm flag, which are the highest-risk aspects of this tool. An output schema exists, so return values need no explanation. The remaining gap is that property_id and stream_id semantics are not addressed, though the tool is otherwise simple enough to invoke correctly.

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

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

Schema description coverage is 0%, so the description must compensate. It adds real meaning to confirm with 'Always needs confirm=true,' correcting the schema's default false. However, it does not explain stream_id format or the optional property_id parameter, leaving important parameter semantics 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 opens with 'Delete a data stream,' stating a specific verb and resource. Among siblings like ga4_create_data_stream, ga4_update_data_stream, and ga4_list_data_streams, this uniquely identifies the deletion operation without needing to parse the schema.

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

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

There are no true alternative deletion tools, so 'Delete a data stream' provides the clear context for when to invoke this tool. The explicit 'Always needs confirm=true' adds a hard precondition for calling it. It lacks an explicit when-not-to-use caveat, but none is obviously needed here.

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

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

With no annotations, the description carries the full behavioral burden, and it does well: it discloses the destructive nature, the confirm=true safety guard, the exact 403 failure mode (credential has Viewer not Editor), and the remediation path (Admin > Property Access Management, or manual deletion in GA4 UI). This goes beyond a bare 'delete' statement.

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

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

Well-organized with a front-loaded purpose line followed by terse, information-dense arg explanations. Every sentence earns its place — the 403 handling and fallback are genuinely useful, not padding.

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

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

Complete for a destructive unlink operation: it covers the confirm guard, the auth failure mode, the remediation, and the link_id source. The output schema frees it from explaining return values. The only gap is the unexplained property_id parameter.

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

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

Schema coverage is 0%, so the description must compensate. It explains link_id (from ga4_list_google_ads_links, and explicitly not the customer_id) and confirm (must be true to actually delete) — both high-value disambiguations. However, property_id is not mentioned anywhere despite being a listed parameter.

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

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

States a specific verb+resource ('Remove a GA4<->Ads link') with a concrete example use case (a link pointed at a deactivated Ads account). The name itself and the example make it unambiguous against siblings like ga4_create_google_ads_link and ga4_list_google_ads_links.

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

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

Gives a clear when-to-use context via the deactivated-account example and the 403/Versus-Editor scenario plus a UI fallback. However, it never explicitly states when not to use the tool or names an alternative to prefer, so usage guidance is implied rather than explicit.

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

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

No annotations are provided, so the description alone must carry the behavioral burden. It only says 'full detail' and does not disclose that this is a read-only operation, whether it depends on a specific account selection, or anything about the output. Behavioral expectations are largely implicit.

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?

There is zero fluff; a five-word sentence delivers the core meaning. The key modifier 'one' is front-loaded and distinguishes the operation from listings.

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 present, so the return format does not need to be spelled out. For a one-parameter getter this is mostly adequate, but the description does not state how property_id is supplied or what happens when no ID is given, leaving a small but important gap.

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

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

Schema description coverage is 0%, and the description never mentions property_id. While the parameter name and schema make it reasonably self-explanatory, the description adds no extra guidance on how to identify the property, format the ID, or handle the nullable optional 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 'Full detail for one GA4 property' clearly signals a single-property retrieval and the use of 'one' distinguishes it from list/create/update siblings. It lacks an explicit action verb, but the tool name reinforces the getter semantics.

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 use for retrieving a single property, but does not explicitly contrast it with ga4_list_properties or mention when someone should choose this over create/update. The one-vs-list phrasing gives limited guidance, but no alternative or conditional context is stated.

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

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

With no annotations, the description carries the behavioral disclosure burden, and it does so well: it states that the result is limited to accounts the credential can reach, and explains the empty-result failure mode. It doesn't cover rate limits or pagination, but those are minor for a simple list operation.

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

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

Two sentences, zero filler: the core action is front-loaded, and the second sentence adds essential workflow context. Every word earns its place.

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

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

For a zero-parameter discovery tool with an output schema, the description gives everything an agent needs: what it returns, when to call it, and how to interpret an empty result. The troubleshooting note adds real value without over-explaining.

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

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

The tool takes zero parameters, so there are no parameter semantics to document. The description appropriately focuses on the outcome and usage rather than inventing unneeded parameter details.

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

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

The verb 'List' plus the resource 'every GA4 account this credential can reach' precisely defines both the operation and its scope. The GA4 prefix clearly separates it from ads_list_accounts and gtm_list_accounts.

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

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

The instruction 'Call this first' gives explicit placement in the agent's workflow, and the follow-up diagnosis of an empty result tells the agent exactly what it means and what to check next. This is clear, actionable usage guidance.

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

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

The description adds a key behavioral detail: it includes auto-created audiences such as 'All Users' and 'Purchasers' when a Google Ads link exists. It implies a read-only operation but does not disclose pagination, rate limits, or authentication needs. With no annotations provided, the description carries the burden and only partially covers behavioral aspects.

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 leads with the action and resource. It contains no filler and provides an important edge case (auto-created audiences) without redundancy.

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

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

While the output schema exists and the tool is simple, the description fails to explain the property_id parameter, its optionality, or what happens when it is omitted. This gap in parameter semantics affects overall completeness, though the core purpose is clear.

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

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

The sole parameter property_id is not explained in the description at all. Schema coverage is 0% and the description only vaguely mentions 'on a property' without connecting it to the parameter name or its optionality. The agent is left without any guidance on what value to provide.

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

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

The description clearly states the verb 'List', the resource 'audiences', and the scope 'on a property'. It further distinguishes itself by noting it includes auto-created audiences from Google Ads links, which is specific and not mentioned by sibling tools like ga4_list_properties.

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

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

The description implies the tool is used to list audiences for a property, and there is a separate create tool (ga4_create_audience). However, it does not explicitly state when to use this tool versus alternatives or any exclusions, leaving room for ambiguity.

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

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

With no annotations, the description carries the behavioral disclosure burden. It usefully reveals that deleted events can appear briefly with countingMethod unset during propagation, which is non-obvious and valuable. It does not mention permissions or rate limits, but for a simple list operation the disclosed caveat is meaningful.

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 compact sentence that front-loads the core purpose and then adds useful detail. Every clause earns its place, with no filler or repetition.

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

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

For a low-complexity list tool with one optional parameter and an output schema, the description covers what is returned (custom/default status, counting status) and includes a relevant edge case. It lacks explicit usage guidance, but the remaining context is sufficiently complete.

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

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

Schema description coverage is 0%, so the description must compensate for the undocumented property_id parameter. It only says 'on a property', which adds minimal meaning beyond the parameter title and does not explain the expected format, whether it's required, or how it maps to the GA4 property.

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

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

The description uses a specific verb ('List') and resource ('conversion events (Key events) on a property') and adds the distinguishing elements of custom vs default and counting status. This clearly separates it from sibling mutation tools like ga4_create_conversion_event and ga4_delete_conversion_event.

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

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

The description gives no explicit guidance on when to use this tool versus alternatives, no exclusions, and no mention of related tools such as ga4_create_conversion_event or ga4_delete_conversion_event. Usage context is only implied by the word 'List' and the sibling names.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action ('List') but does not disclose read-only behavior, pagination, whether archived custom dimensions are included, or what happens when property_id is omitted. The description is not misleading but leaves important behavior unspecified.

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

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

The description is a single clear sentence with no filler and the verb is front-loaded. It is concise, though it achieves this by omitting contextual details that other dimensions penalize.

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

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

For a simple list operation with only one optional parameter and an output schema, the description is minimally viable: it names the resource and scope. However, with no annotations, no usage guidance, and no parameter explanation, there are clear gaps for an agent trying to call it correctly without prior GA4 knowledge.

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 by explaining the property_id parameter. However, it only says 'on a property' and does not clarify the expected format (e.g., numeric GA4 property ID), whether the parameter is effectively required despite being optional, or what the default null means. The schema title alone carries most of the meaning.

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

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

The description names a specific verb ('List'), a specific resource ('custom dimensions'), and a clear scope ('on a property'). This distinguishes it from sibling tools like ga4_create_custom_dimension, ga4_archive_custom_dimension, and ga4_list_custom_metrics without needing to open the schema.

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

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

There is no guidance about when to use this tool versus ga4_list_custom_metrics or ga4_list_properties. The description does not mention prerequisites, such as obtaining a property_id from ga4_list_properties, nor does it state any exclusions or alternatives. An agent must infer usage entirely from the tool name and sibling list.

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

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

With no annotations, the description carries the full behavioral disclosure burden. 'List' clearly indicates a read-only operation, but the description does not reveal any additional behavioral traits such as whether archived metrics are included, pagination behavior, or permission requirements. It is adequate for a simple list operation but not rich.

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

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

The description is a single front-loaded sentence with no filler. Every word ('List', 'custom metrics', 'on a property') contributes to the meaning, making it highly concise 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?

Given the tool's simplicity, one optional parameter, and an output schema, the description conveys the core action. However, it lacks parameter semantics and usage guidance, so an agent might not know how to correctly provide property_id or when to choose this tool over a similar list tool. It is minimally viable but has clear gaps.

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

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

Schema description coverage is 0%, so the description must compensate. It only says 'on a property', which barely adds meaning beyond the parameter title 'Property Id' and the tool name. It does not explain the expected format of property_id, whether it is required, or what happens when it is null, leaving a significant semantic 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 uses the specific verb 'List' with the resource 'custom metrics' and scopes it to 'a property', making the operation unambiguous. It distinguishes from sibling tools like ga4_list_custom_dimensions (different resource) and ga4_create_custom_metric (different action) without needing to open schemas.

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

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

There is no guidance about when to use this tool versus alternatives, such as ga4_list_custom_dimensions or ga4_run_report. No exclusions, prerequisites, or context are provided, leaving the agent to infer usage solely from the tool's name and one-line description.

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

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

There are no annotations, so the description carries the burden. The word 'List' conveys a read-only operation, and the description adds that the result includes the measurement ID. It does not disclose expected response shape, pagination, or permissions, though the output schema is present to fill some of that gap.

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

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

One sentence, front-loaded with the action and resource, with the measurement-ID detail placed where it adds value. Every word earns its place; there is no filler or repetition of the schema.

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

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

For a simple list operation with one optional parameter and an output schema, the description is mostly complete: it names the resource, the scoping property, the key output field, and the common use case. It is only missing an explicit note on property_id format/omission behavior and pointers to how to obtain the property ID.

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

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

Schema description coverage is 0%, so the description must compensate. It only says 'on a property,' which identifies the intended scope but does not explain how to format property_id, whether it must match a GA4 property resource name, or what happens when it is omitted (default null). With a single optional parameter, more explicit parameter guidance was needed.

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

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

Description opens with a specific verb and resource ('List data streams') and scopes it to 'on a property', clearly distinguishing it from ga4_list_accounts, ga4_list_properties, and the data stream create/update/delete siblings. It also adds the concrete output purpose (measurement ID for GTM tags or gtag.js), making the tool's role unmistakable.

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

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

The description gives a clear context for when this tool is useful: when the G-XXXXXXX measurement ID is needed to wire up GTM tags or gtag.js. It does not explicitly name alternatives or exclusion conditions, so it stops short of a full 5.

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

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

With no annotations, the description carries the behavioral burden. It conveys that this is a read-only listing operation, but it does not disclose whether property_id may be omitted, how pagination or large result sets are handled, or what happens when no links exist. The description is not misleading, but it adds little beyond the verb 'List'.

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

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

The description is a single sentence with no filler or redundant information. It is appropriately concise, front-loaded with the verb and resource, and every word contributes to meaning.

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

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

The tool is simple: one optional parameter and an output schema, so return values need not be described. However, the description leaves property_id semantics and usage boundaries implicit, and the absence of annotations means the agent gets no extra context. It is adequate for a minimal list tool but not fully complete.

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

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

Schema description coverage is 0%, and the description only indirectly references property_id by mentioning 'GA4 property'. It does not explain the expected format (e.g., numeric GA4 property ID) or the effect of leaving it null, even though the schema marks it optional with a default of null. The description adds minimal semantic value beyond the schema.

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

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

The description uses a specific verb ('List') and a specific resource ('Google Ads accounts linked to a GA4 property'), making the tool's function unambiguous. It clearly distinguishes this tool from ga4_create_google_ads_link and ga4_delete_google_ads_link, and also from ads_list_accounts, which lists Google Ads accounts directly.

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

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

The description implies the use case: retrieving the set of Google Ads accounts linked to a given GA4 property. However, it does not explicitly state when to prefer this over alternatives such as ads_list_accounts, nor does it mention that link creation/deletion are handled by sibling tools. No exclusions or conditional guidance are provided.

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

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

No annotations are provided, so the description carries the behavioral disclosure burden. It adds the scoping behavior (filter by account vs. all) but does not disclose potential limitations like pagination, rate limits, or response size. Since the tool is a straightforward read operation, the lack of harm details is partially mitigated by the verb 'List'.

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

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

The description is compact—two sentences plus a clear args block. The main purpose is front-loaded, and the parameter explanation is neatly separated. No fluff or redundancy.

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

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

For a simple list tool with one optional parameter and an output schema (which presumably covers return values), the description provides all necessary context: what it does, the parameter's meaning and source, and the behavior when omitted. It is sufficient for an agent to call it correctly.

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

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

Schema coverage is 0%, so the description must explain the parameter. It specifies that account_id is numeric and should come from ga4_list_accounts, and explains the omitted-case behavior. This adds crucial meaning beyond the bare schema (string or null). It does not give the exact format of the numeric string, but that is minor.

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

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

The description states a specific verb ('List') and resource ('GA4 properties'), and clarifies the optional account filter. It naturally distinguishes itself from siblings like ga4_get_property (single property) and ga4_list_accounts (lists accounts).

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

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

It explains when to use the optional account_id and that omitting it lists all reachable properties. It references ga4_list_accounts as the source of account IDs, implying a dependency. It does not explicitly name alternatives for when to avoid this tool, but the guidance is adequate for the simple use case.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It only mentions the approximate 30-minute lookback; it does not state that the operation is read-only, whether property_id is required in practice, whether results are sampled, or whether API limits apply. This is a significant gap for a reporting tool.

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

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

The description is short, front-loaded with the main purpose, and uses a clear Args block with examples. There is no filler. The slight ambiguity in how the dimension examples are formatted prevents a perfect score, but the overall structure is efficient.

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

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

The output schema may cover return values, but the description is incomplete for confident selection and invocation. It lacks guidance on property_id and limit, does not differentiate from ga4_run_report, and provides no behavioral context beyond the time window. Given no annotations and 0% schema coverage, important selection information is missing.

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

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

Schema description coverage is 0%, so the description must compensate, but it only gives example values for dimensions and metrics. It omits meaning for limit and property_id, and the example formatting is ambiguous because dimensions are shown as separate single-element arrays rather than one list. Partial guidance only.

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

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

The description clearly identifies the resource as a realtime report and defines its scope as roughly the last 30 minutes of activity. It does not use an explicit verb, and it does not directly name sibling tools, but 'realtime' plus the time window meaningfully distinguishes it from historical reports like ga4_run_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 phrase 'activity in roughly the last 30 minutes' implies when the tool is appropriate, giving a clear temporal context. However, it does not explicitly state when to prefer this over ga4_run_report or other reporting tools, and it names no alternatives or exclusions.

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

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

There are no annotations, so the description carries the behavioral burden. It discloses useful defaults (order_by_metric defaults to the first metric, desc defaults to descending) and that the filter is a single exact match, but it does not mention property selection when property_id is null, limit behavior, pagination, or any quota/error 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 one-line summary is front-loaded and the Args section is organized and free of filler. The listing is somewhat long, but each parameter entry earns its place given the tool has 10 parameters.

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

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

The description covers the core parameters and the main calling patterns, while the output schema carries the return-value documentation so the description does not need to restate it. The main gaps are the unstated semantics of property_id when null and the limit parameter, which prevents a 5.

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

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

Schema description coverage is 0%, and the description compensates well by giving concrete examples for dimensions, metrics, date formats, filtering, and sorting. It omits semantic detail for limit and property_id, though their names and defaults are reasonably self-explanatory.

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

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

The description opens with a specific verb and resource ('Run a GA4 report') and clearly scopes the tool to arbitrary dimension/metric combinations over a date range. It does not explicitly differentiate from ga4_run_realtime_report, so it stops short of a 5.

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

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

The 'any dimension x metric combination over a date range' wording implies a general-purpose reporting tool, and the parameter examples clarify acceptable input formats. No explicit guidance is given about when to choose this over ga4_run_realtime_report or another sibling, and there are no exclusions or alternatives mentioned.

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

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

No annotations are provided, so the description carries the burden of explaining behavior. It does disclose the output composition, sort order, and the 'convenience report' nature, which implies a read-only analytics operation. However, it does not explicitly state read-only behavior, date handling, property fallback, or any limits/pagination, leaving some behavioral gaps.

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

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

Two sentences with no filler. The core report behavior is front-loaded, and the client-context sentence earns its place by clarifying the intended use. It is appropriately sized for the tool's simplicity.

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

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

The output schema covers return values, so the description need not explain those. The description conveys the report's purpose and composition, but it leaves parameter semantics and usage boundaries unaddressed. For a four-parameter tool with no annotations, this is still a noticeable completeness gap.

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

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

Schema description coverage is 0%, and the description does not explain any of the four parameters (limit, start_date, end_date, property_id). The parameter names and defaults are somewhat self-explanatory, but the description adds no meaning beyond the schema and does not compensate for the absence of parameter descriptions.

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

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

The description states exactly what the report returns: sessions by source/medium, conversions, conversion rate, sorted by conversions descending. It also frames the business question it answers. It does not explicitly name a sibling alternative like ga4_run_report, so it stops short of full differentiation, but the purpose is unambiguous.

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

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

The description implies when to use it: when the client needs to know which channels produce leads. However, it provides no explicit guidance on when NOT to use it or which alternative tool should be used for custom or more detailed reports. Usage context is present but not exclusionary.

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

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

There are no annotations, so the description carries the full burden of behavioral disclosure. It conveys that the operation is a mutation and adds the 'web streams only' constraint for default_uri, but it does not mention the confirm parameter, side effects, permission requirements, or whether the update is partial or full replacement.

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, efficiently worded sentence with the main action front-loaded and no filler. It is appropriately concise, though the terseness contributes to the completeness gaps elsewhere.

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

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

With five parameters, no annotations, and 0% schema description coverage, the description is too thin for an agent to invoke the tool with confidence. It omits the purpose of the required stream_id, the optional property_id, and the confirm flag. The output schema exists, so return values need not be explained, but the input-side gaps remain significant.

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

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

Schema description coverage is 0%, so the description must compensate, but it only adds meaning to display_name and default_uri. It leaves stream_id, property_id, and confirm unexplained, and it does not clarify how property_id relates to stream_id or why confirmation is required.

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

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

The description states a specific verb ('Update') and resource ('a data stream'), and narrows the scope to display name or default URI. This is enough to distinguish it from sibling tools like ga4_create_data_stream, ga4_delete_data_stream, and ga4_update_property.

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

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

The description implies when to use the tool (when a data stream's display name or web default URI needs changing), but it does not explicitly state when not to use it or name alternative tools. Unlike higher-scoring definitions, it offers no routing guidance between ga4_update_data_stream and ga4_update_property.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It does state the partial-update behavior ('Only the fields you pass are changed'), which is useful. However, it omits crucial behaviors: the 'confirm' parameter is not explained (likely a confirmation flag for mutation), there is no mention of permissions, response format, or idempotency. For a mutating operation, this is insufficient.

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 extremely concise: two sentences with no filler. The primary purpose is front-loaded in the first sentence, and the critical partial-update behavior is clearly stated second. Every word earns its place.

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

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

Given no annotations and an output schema (not shown), the description still lacks crucial context: the 'confirm' field's purpose, the exact format for each field, and any prerequisites (e.g., required permissions or property ownership). An agent cannot safely call this tool correctly without additional knowledge, especially for a mutation that may have side effects.

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

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

Schema description coverage is 0%, so the description must compensate for parameter meaning. It lists the field names (display_name, time_zone, currency_code, industry_category), which aligns with the schema's property names, but adds no format guidance (e.g., time zone format, currency code standard, industry category options). The 'confirm' parameter is entirely unexplained. The description adds only marginal value over the schema's property keys.

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 ('Update') and the specific resource type ('GA4 property') along with exactly which fields it affects (display name, time zone, currency, industry). This distinguishes it from sibling tools like ga4_update_data_stream and ga4_create_property without needing to inspect the schema.

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

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

The description implies usage by listing updatable fields, but it does not explicitly say when to use this tool over alternatives (e.g., when you need to modify property-level settings rather than data streams) or mention any exclusions. The lack of comparison to ga4_get_property or ga4_create_property leaves the agent to infer context.

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