AdCopilot

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

Annotations already declare readOnly/idempotent/non-destructive, so the lower bar applies, yet the description still adds real substance: the score is weighted, it covers only the checks applicable to this account, and it reports how many checks could actually be evaluated (a key caveat for trusting the number). It does not explain cost, latency, or what happens with a too-short lookback window.

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

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

Two compact sentences, front-loaded with the return value and immediately followed by the scope caveat; nothing is padded. Minor density cost from the embedded clause about the audit's 74 checks.

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?

Output schema exists, so return values need no prose, and annotations cover the safety profile. But for a tool with four undocumented parameters (including a lookback window defaulting to 30 days) the description leaves too much for the agent to guess about how to configure the call.

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

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

Schema description coverage is 0% across four parameters, so the description must compensate and it does not: days, detail, render and customer_id are never mentioned. In particular the summary/full detail enum is ambiguous — it is unclear whether 'full' reintroduces findings, which directly conflicts with the 'no findings' promise.

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?

Names a specific artifact (weighted 0-100 health score with letter grade and per-category breakdown) computed over the audit's applicable checks, and states what it does NOT return (findings, evidence). That scope statement implicitly separates it from full_audit-style siblings, though it never names the alternative tool outright.

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 'the cheapest way to ask how the account is doing' implies a quick-glance use case versus deeper audit tools, but there is no explicit 'use this when X, use full_audit when Y' routing. An agent must infer the boundary from the 'no findings, no evidence' caveat.

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

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

Beyond the annotations, it discloses the create-if-missing behavior ('adds the words to that list if the account already has one, and otherwise creates the list'), Google's one-list/1,000-keyword caps, duplicate dropping, and which campaign types the list applies to vs. which it doesn't. That is substantive operational context an agent could not infer from readOnlyHint/destructiveHint alone.

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

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

The structure is excellent — purpose, when-to-use, API mechanics, limits, args, returns — and it is front-loaded. It is on the long side, with some Google Ads internals (CustomerNegativeCriterion, shared set type) that a calling agent does not strictly need, though they do support the behavior claims.

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 two-parameter mutation with no schema descriptions, the definition covers everything: preconditions, side effects, hard limits, default match type, and a described return payload (shared_set_id, created flag, keywords added). Combined with the existing output schema, an agent has sufficient information to invoke it correctly.

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

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

Schema description coverage is 0%, so the description must carry the parameter burden, and it does: customer_id is documented as digits only with no hyphens, and keywords is documented down to the nested text and match_type fields, the EXACT/PHRASE/BROAD enum, the BROAD default, and duplicate suppression. Nothing in the args is left undefined.

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 ('adds account-level negative keywords') and immediately defines the scope as 'words blocked in every campaign,' which separates it from campaign-, ad-group-, and shared-list-level siblings. The explicit contrast with remove_account_negatives and the account-level list framing leave no ambiguity about what this tool does.

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

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

It states exactly when to use it ('words the business never wants to show for anywhere') with concrete examples like brand-safety terms, 'free', and 'jobs'. It names the inverse tool (remove_account_negatives) and, through the account-level scoping, implicitly rules out the per-campaign and per-ad-group negative keyword tools.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=false, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds that the return is a count of assets added, but says nothing about what happens with duplicate assets, partial failures, or whether previously attached assets are affected — notable for a non-idempotent mutation.

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 line, followed by a usage line and a compact Args/Returns block; every section maps to something the agent needs. The Returns block is partly redundant given an output schema exists, costing a little space.

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 3-parameter mutation with an output schema and full annotation coverage, the description supplies the missing parameter semantics and the usage context. Remaining gaps are error/partial-success behavior and whether referenced assets must already exist, which an agent would likely need.

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 carries the full burden and mostly does: it specifies customer_id must be numbers only with no hyphens, names the asset group resource name, and enumerates the per-asset fields including the nine allowed field_type values. It does not reconcile this with the schema, which types assets loosely as free-form string maps, leaving the exact item shape slightly ambiguous.

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

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

States a specific verb and resource ("Adds assets to an existing asset group") and the second sentence clarifies the lifecycle position — after creation — which separates it from create_asset_group. It does not explicitly name the close siblings link_asset_to_campaign or link_assets_to_customer, so an agent must still infer the distinction.

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 this to add more assets to an asset group after it's been created" gives a clear usage condition and implicitly excludes the create path. There are no explicit when-not conditions (e.g., when to use link_asset_to_ad_group instead) or stated prerequisites such as the asset already existing.

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

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

Annotations already declare this is a non-read-only, non-destructive, non-idempotent mutation, so the safety profile is covered. The description adds useful behavior — it names the return payload ('created keyword resource names and count') and documents the default match type — but omits what many agents need most for a non-idempotent add: what happens with duplicate keywords, whether validation fails the whole batch or partially succeeds, and what errors look like.

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 front-loaded sentence states the action, followed by tightly structured Args and Returns blocks with no filler. The Returns block is somewhat redundant given an output schema exists, but it is short and does not bloat the definition.

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 3-parameter mutation with annotations and an output schema, the description supplies the field-level detail the schema lacks and confirms the return shape. The remaining gap is failure/duplicate semantics for a non-idempotent write, which an agent calling this repeatedly would want to know.

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 keywords array is an untyped object in the schema, so the description is the sole source of parameter meaning — and it delivers. It specifies the customer_id format ('numbers only, no hyphens'), the purpose of ad_group_id, and the three sub-fields of each keyword object including the EXACT/PHRASE/BROAD enum, the BROAD default, and the micros unit for CPC bids.

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: 'Adds keywords to an ad group.' An agent knows exactly what entity is created and where. It does not, however, distinguish itself from close siblings like add_negative_keywords, add_to_negative_keyword_list, or update_keyword, so the agent must infer the boundary from the names alone.

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 statement of when to use this tool versus alternatives such as add_negative_keywords (for exclusions) or update_keyword (for changing existing bids/match types), nor any prerequisites about the ad group or customer account. Usage is only inferable from the name and the parameter 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?

Annotations already cover the mutation/safety profile, and the description adds meaningful context: negative keywords suppress ads for specific searches, removal is handled by a sibling, and creation returns resource names. It does not discuss duplicate handling or limits, but the added behavioral context is solid beyond annotations.

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

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

The description is front-loaded with purpose and structured with Args/Returns, making it easy to scan. It is slightly less concise than ideal because the Returns line partly duplicates output-schema information, but there is little wasted text.

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

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

Given a three-parameter mutation tool with an output schema and annotations covering safety, the description is complete enough to invoke correctly. It documents the nested keyword object format that the input schema leaves ambiguous and explains the operation's effect and return.

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 carries the full burden and does so effectively: customer_id format is specified, campaign_id is identified, and keywords are explained as objects with text and match_type. It also gives allowed match types and the default, which the schema does not 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 states a specific verb/resource/scope: adding negative keywords to a campaign to block irrelevant traffic. It clearly distinguishes the operation from remove_negative_keywords and implies campaign-level scope versus sibling account/list variants.

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 useful context and names the inverse operation, remove_negative_keywords, but does not explicitly compare against sibling add tools such as add_account_negatives, add_to_negative_keyword_list, or attach_negative_keyword_list. The campaign scope is clear, but when-not guidance is limited.

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

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

Annotations cover the safety profile (not read-only, not destructive, not idempotent, closed-world), and the description adds behavior they don't: changes propagate to every attached campaign immediately, exact duplicates are silently dropped, and large input lists are batched. The immediate-propagation warning is exactly the kind of side effect an agent needs before writing.

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?

Front-loaded with the one-line purpose and the propagation warning, then cleanly split into Args and Returns. The embedded multi-line SQL block is useful but heavy relative to the rest, and the trailing 'Tools revision' tag is noise rather than 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?

An output schema exists, yet the description still telegraphs the return (resource names and count), so the caller knows what to report back. Combined with dedup, batching, and default match type, nothing material is missing for a three-param write tool.

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

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

Schema coverage is 0% and the item schema is a bare additionalProperties:string object, so the description carries the full burden — and does: customer_id is numbers only with no hyphens, shared_set_id identifies the list, and each keyword object needs text plus a match_type restricted to EXACT/PHRASE/BROAD with BROAD as default. This documents constraints the schema cannot.

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: adds negative keywords to an *existing shared* negative keyword list. That scope word 'existing' implicitly separates it from create_negative_keyword_list, and the explicit pointer to remove_from_negative_keyword_list separates it from the removal sibling.

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 the operative context (the list must already exist and be attached to campaigns), names the inverse tool, and supplies a concrete SQL query against the search tool to locate shared_set_id when the caller doesn't have one. That is actionable routing guidance rather than inference.

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?

Adds real behavior beyond annotations: it never proposes broad-match negatives, it emits pre-built add_negative_keywords calls per theme, and it details the language-detection fallback (writing system vs campaign language, no call when unavailable). The restated 'Read-only' duplicates readOnlyHint=true but does not contradict it.

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?

Front-loaded with the core action and themes, then the output contract. The middle sentence about language detection is dense and parenthetical but still earns its space; overall only minor tightening is possible.

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 values need no explanation, and the analysis purpose is well covered. However, for a 7-parameter tool with no schema field descriptions, the missing parameter guidance (filters, output format, caps) leaves the definition only marginally complete.

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

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

Schema description coverage is 0%, so the description must carry the parameter burden. It covers the theme list and implies the 30-day window, but says nothing about detail, render, min_clicks, max_findings, or how to override days — four of seven parameters are undocumented anywhere.

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 ('Group the last 30 days of search terms into negative-keyword candidates') and enumerates the exact themes it detects. An agent can distinguish it from siblings like analyze_waste or add_negative_keywords without opening any 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?

Makes the workflow clear: it returns 'one ready-to-run add_negative_keywords call per theme,' which routes the agent to the follow-up tool. 'Never proposes broad-match negatives' and 'Read-only' set boundaries, but there is no explicit when-not-to-use or comparison against analyzer siblings like analyze_waste.

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

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

Annotations already declare readOnlyHint/idempotentHint/destructiveHint=false, so the trailing 'Read-only' is redundant, but the description adds genuine value by describing the shape of the response (typed findings, per-finding cost, paired remediation call). It doesn't cover cost/rate characteristics or how thresholds interact, but it exceeds what the annotations convey.

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

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

Three tight sentences, front-loaded with the diagnostic scope before the return shape. The trailing 'Tools revision: 5c9bea8f.' is versioning noise that doesn't help tool selection.

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 the return contract is covered and the description's summary of findings is a bonus. The real gap is that a 6-parameter analysis tool ships with zero parameter documentation anywhere, leaving the agent to guess at window length, sensitivity thresholds, and output volume.

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% across all 6 parameters, so the description is the only place meaning could be added — and it adds none. Nothing explains what `days`, `min_clicks`, `max_findings`, `detail`, or `render` do or how they change the findings; the two enums are the only self-documenting signals.

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

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

The description states a specific verb+resource in concrete terms: zero-converting search terms/keywords, broad match on manual bidding, campaigns under 1.0 ROAS. An agent can tell this apart from the broad diagnostic siblings (full_audit, bidding_audit, analyze_search_terms) because the scope is explicitly 'spend with nothing to show for it' and the outputs are enumerated.

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 clear context for when to reach for this tool (wasted spend diagnosis with a remediation attached), and the 'exact negative-keyword or pause call that fixes it' tells the agent what to do next. It stops short of naming alternatives or exclusions, e.g. when to prefer analyze_search_terms or bidding_audit instead.

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

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

The annotations already declare readOnly=false, destructive=false, and idempotent=false, but the description adds substantial context beyond them: the attachment applies to future list additions, links cannot be paused, the connector cannot remove links, and word-level removals affect every attached campaign. No annotation contradiction 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 front-loaded with the core action, then adds behavioral and detach limitations before documenting Args and Returns. The extra explanation is directly relevant to correct use, and there is no redundant filler.

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

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

For a three-parameter mutation tool with an output schema, the description covers the key calling constraints, side effects, and detach/removal limitations. It leaves no important ambiguity about what the tool does or how it differs from nearby tools.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning, and it does explain all three parameters. customer_id includes the useful numbers-only/no-hyphens constraint, campaign_id is identified as the campaign ID, and shared_set_id includes its provenance; however, campaign_id and shared_set_id formats are only minimally described.

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 gives a specific verb and resource: it attaches a shared negative keyword list to a campaign. It also clarifies the practical scope: the campaign stops showing for every word in the list, including words added later. This distinguishes it from siblings such as create_negative_keyword_list and remove_from_negative_keyword_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?

It clearly states when this tool is used and names alternatives: there is no detach tool, removal happens outside the connector, and individual words can be removed with remove_from_negative_keyword_list. It also explains that shared_set_id comes from create_negative_keyword_list or search.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the trailing 'Read-only' adds nothing. The description does add real diagnostic context — that results are judged against the account's own conversion volume rather than fixed industry thresholds — but says nothing about permissions, cost/latency, or how findings are ranked.

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

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

Two dense, front-loaded sentences that enumerate actionable finding types with no filler. The appended 'Tools revision: 5c9bea8f' line is pure noise for an agent deciding whether to call the tool.

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

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

An output schema exists, so return-value explanation is not required, and annotations cover the safety profile. What is missing is any guidance on the runtime knobs that materially change the result set (detail, max_findings, days), leaving an agent to guess at cost and coverage for a five-parameter audit.

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% across five parameters, and the description explains none of them: the lookback window (days), the summary-vs-full verbosity (detail), the render mode, or the finding cap (max_findings) are all left to inference. Only 'conversion volume' loosely hints that a historical period is involved.

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 gives a specific verb and resource ('audit bidding strategies against the account's own conversion volume') and enumerates the exact finding classes it produces, which makes it distinguishable from generic siblings like full_audit or account_health_score. It stops short of naming a sibling it should be preferred over, so it lands just below 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?

Usage is implied by the enumerated problem scenarios (manual bidding with enough data, unrealistic CPA/ROAS targets, stuck learning, low-volume campaigns), which tells an agent this is a diagnostic to run when those symptoms are suspected. There is no explicit when-not guidance and no pointer to alternatives such as full_audit, conversion_setup_audit, or budget_pacing when the issue is not bid-strategy related.

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

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

Annotations already cover read-only/idempotent/non-destructive, so the description earns credit for adding real behavior: time-zone-normalized projection, de-duplication of budgets shared by multiple campaigns, and precisely what the flags mean. "Read-only." merely restates an annotation, so not a full 5.

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

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

Three tight, front-loaded sentences that lead with the projection logic and follow with flag semantics and the month format. Minor waste: "Read-only." repeats annotations and the "Tools revision" trailer adds nothing for an agent selecting or calling the tool.

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

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

An output schema exists and the tool is read-only, so return format and safety need no elaboration. However, with 0% schema coverage on five parameters, the missing semantics for detail/render/max_findings are a real gap for correct invocation.

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

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

Schema description coverage is 0%, so the description carries the full burden, yet it explains only month (YYYY-MM, omit for current month). The detail, render, max_findings, and customer_id parameters — including two enums — are left entirely undocumented outside their 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?

States a specific verb and resource — projecting this month's spend against each daily budget — with precise scope (account's own time zone, shared budgets projected once on combined spend). No sibling does pacing projection, so an agent can distinguish it from analyze_waste or full_audit without opening 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 when the tool is useful ("Flags budgets heading past their cap or leaving money unspent while losing impression share") and explains the month parameter, but never names an alternative tool or states exclusions. 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?

Annotations already declare read-only, idempotent, non-destructive behavior, so repeating 'Read-only' adds little. But the description adds genuinely useful caveats beyond the annotations: 30-day retention, omission of Google Ads Editor changes and some Change History rows, and minute-level lag. These are the kind of source-data limitations an agent cannot get from schema or annotations.

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

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

The core sentence is front-loaded and dense with useful specifics, and the caveats follow compactly. The trailing 'Tools revision: 5c9bea8f.' is build metadata that does not help an agent invoke the tool and could be dropped.

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 values need not be explained, and the description adequately covers the data source and its limitations. The gap is parameter coverage: with six parameters and 0% schema descriptions, omitting `detail`, `render`, `campaign_id`, and `max_findings` leaves meaningful invocation behavior undocumented.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning, yet it only documents `days` (1-30, default 7), which is genuinely helpful beyond the bare integer schema. The other five parameters — `detail` and `render` enums, `campaign_id` filtering, `max_findings`, and `customer_id` — are never mentioned, leaving the agent to guess their semantics.

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

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

The description opens with a specific verb and resource ('List what changed in the account') and enumerates the exact dimensions returned (when, by which Google login, which channel). This clearly distinguishes it from siblings like account_health_score or full_audit, which analyze rather than enumerate changes.

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

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

Usage is only implied: an agent can infer this is the tool for auditing recent account changes, and the 30-day Google retention window signals a bounded lookback. However, there is no explicit when-to-use/when-not guidance or named alternative (e.g., versus full_audit or list_recommendations) to route an agent deciding between change tracking and diagnostics.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, and the description's 'Read-only.' merely restates that. The audit-scope list adds some substance about what the tool inspects, but there is no disclosure of cost, latency, or how findings are summarized versus detailed.

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 front-loaded sentence delivers the core scope, and 'Read-only.' is a useful one-word safety restatement. The trailing 'Tools revision: 5c9bea8f.' is metadata noise that does not help an agent select or call the tool.

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

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

The output schema and annotations cover return shape and safety profile, so those needn't be explained. The real gap is parameter behavior at 0% schema coverage: an agent cannot tell what 'detail: full' returns versus 'summary', or how max_findings interacts with render.

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% for all five parameters, so the description bears the burden of explaining days, detail, render, and max_findings. It mentions none of them, leaving the agent with bare, undescribed fields whose defaults and effects (especially detail vs. max_findings) must be guessed.

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 ('Check whether...') and resource ('conversion tracking'), then enumerates the exact dimensions audited: primary actions, enhanced conversions, attribution model, values, duplicate counting, GA4 link, consent mode, tag firing. That enumeration distinguishes it cleanly from siblings like explain_conversion_gap, bidding_audit, and full_audit.

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 framing 'the measurement every other number in the account rests on' implies this is the prerequisite audit before trusting other metrics, which is useful usage context. However, it never says when to prefer this over full_audit or explain_conversion_gap, nor any prerequisites 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?

Annotations already declare this is a non-read-only, non-idempotent, non-destructive mutation, so the description does not need to restate those basics. It adds meaningful behavioral context: cpc_bid_micros currency semantics, allowed ad group types, and what an ENABLED ad group does in an already-running campaign.

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, clearly structured under Args and Returns, and every section is relevant. It repeats a few schema defaults, but those repetitions support interpretation of currency and enum meaning rather than adding noise.

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 the description does not need to explain return values in depth, and it still briefly notes that the return includes the created resource name. Combined with full parameter documentation and status semantics, it gives an agent enough information to invoke this creation tool correctly.

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

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

Schema description coverage is 0%, so the description must carry the full parameter burden, and it does: it documents all six parameters, including customer ID formatting, campaign ID purpose, cpc bid micros conversion, ad_group_type enum values, and status enum values 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 states a specific verb and resource: creates a new ad group within a campaign. That is much clearer than a tautology, but it does not explicitly distinguish this from the sibling update_ad_group or create_campaign 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?

Usage is implied by 'Creates a new ad group within a campaign,' and the status parameter includes useful operational guidance about ENABLED versus PAUSED. However, it does not explicitly say when to use this instead of update_ad_group or how to choose the parent campaign in context.

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

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

Annotations already declare destructiveHint=true, openWorldHint=true and idempotentHint=false, so safety is covered. The description adds real behavioral context beyond that: asset groups and assets must be created in a single batch, assets must pre-exist, and an ENABLED group begins serving from the campaign budget immediately upon approval — a consequence an agent would otherwise miss.

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 front-loaded with the core action, then a requirements block and a clean Args section. It is long, but for a 15-parameter batch tool each section is load-bearing; the Returns note mildly overlaps the output schema.

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

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

Given 15 parameters, 0% schema coverage and a true mutation with destructive semantics, the description supplies everything needed: ordering constraint, asset minimums, defaults, formatting rules, and the serving consequence of the status default.

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% across 15 params, so the description must carry the load and does: it explains each parameter's meaning, per-list minimums and maximums, the ENABLED/PAUSED distinction, customer_id formatting (numbers only, no hyphens), and the 15-character limit on path1/path2.

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 (creates an asset group for a Performance Max campaign) plus the linking behavior in the same sentence. An agent can distinguish it from create_performance_max_campaign and add_assets_to_asset_group without opening any 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?

Gives explicit ordering guidance (create assets first with create_text_asset, create_image_asset, etc., then pass resource names) and the hard minimum/maximum asset counts. It does not explicitly point to add_assets_to_asset_group as the alternative for supplementing an existing group, which is the one obvious gap.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, and openWorldHint=false, so the mutation profile is covered. The description adds the one-line return shape (created asset resource name) but says nothing about duplicate-creation behavior despite idempotentHint=false, nor about permissions or quota implications.

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 statement is front-loaded in the first sentence and the Args/Returns structure is easy to scan. Slight redundancy with the return-value sentence given an output schema exists, but no filler.

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

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

For a 4-param mutation tool with annotations and an output schema, the definition covers identity, field formats, enum values, and default. The remaining gap is operational behavior (duplicates, permission requirements) rather than anything that would block a correct call.

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

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

Schema coverage is 0%, yet the description documents all four parameters with real added value: customer_id must be numbers only with no hyphens, country_code is two-letter with examples, and call_conversion_reporting_state enumerates the three valid values plus the DISABLED default — none of which the schema itself carries. Only phone_number ("The phone number string") is left without format guidance such as E.164.

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 ("Creates a call asset") and clarifies its role — a phone number attached to an ad — which differentiates it from the many sibling create_*_asset tools. It also notes the asset must then be linked to a campaign or ad group, hinting at the follow-up tool, though it does not name link_asset_to_campaign explicitly.

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

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

Usage is only implied: the mention that the asset "can be linked to campaigns or ad groups" suggests creating first then linking, but no sibling is named and no prerequisite (e.g., an existing call conversion action for the USE_RESOURCE_LEVEL state) or exclusion is given.

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

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

Annotations already cover the safety profile (readOnlyHint=false, destructiveHint=false, non-idempotent, closed-world), and the description adds real constraints beyond them: the 25-character cap on text and the YYYY-MM-DD date formats. It does not warn that repeated calls create duplicate assets (relevant given idempotentHint=false) or that a separate link call is required, which keeps it below a 5.

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

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

Front-loaded one-line purpose followed by a concrete callout example, then Args/Returns. The Args list duplicates schema titles, but that duplication is justified given zero schema description coverage; the Returns block is somewhat redundant since an output schema exists.

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 return-value note is a bonus rather than a requirement, and all four parameters are explained. The notable omission is the post-creation step — a callout asset must be linked via link_asset_to_campaign or link_asset_to_ad_group to have any effect, which the description only gestures at with 'can be linked'.

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

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

Schema description coverage is 0%, so the description carries the full burden — and it does: customer_id 'numbers only, no hyphens', callout_text 'max 25 characters', and date formats plus optionality for both date fields. Only minor gaps remain (timezone/date semantics, whether start_date is required for end_date to apply).

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 ('Creates a callout asset') and immediately disambiguates it from the many sibling create_*_asset tools by explaining what a callout is ('short snippets of text ... e.g. "Free Shipping"'). An agent can distinguish it from create_sitelink_asset or create_text_asset without opening 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 phrase 'can be linked to campaigns or ad groups' hints at the surrounding workflow, but the description never says when to pick a callout over another asset type, nor that creation alone does not attach the asset. Usage 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?

Goes well beyond the annotations (readOnly=false, destructive=true, openWorld=true), which already cover the safety profile. It discloses atomic budget+campaign creation so no orphan budget is left behind, that the budget is not shared, that validation rejects bad channels/strategies/targets before any call is sent, and that everything is created PAUSED because ENABLED is refused.

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?

Front-loads the core action, then organizes behavior, Args and Returns clearly, and every parameter entry earns its place. Slightly verbose in the language-setting paragraph and repeats the micros conversion formula twice, but the length is largely justified by a 15-parameter schema with no field descriptions.

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

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

Given a 15-parameter mutation tool with zero schema coverage, the description supplies defaults, enums, cross-parameter validity rules, creation semantics and the atomicity guarantee. An output schema exists, and the description still briefly notes the return shape, so nothing needed to call it correctly is missing.

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

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

Schema coverage is 0% across 15 parameters, so the description carries the full burden and does: it enumerates every allowed enum value, gives defaults, explains the micros-to-currency conversion with a worked example, and spells out conditional requirements (target_cpa_micros required with TARGET_CPA and refused otherwise; cpc_bid_ceiling_micros only with TARGET_SPEND) plus the channel-specific defaults for search_partners, display_network and geo_target_type.

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

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

States a specific verb and resource ('Creates a new Google Ads campaign with a budget') and immediately names the sibling it is not for, telling the agent that Performance Max campaigns go to create_performance_max_campaign. The agent can distinguish it from create_ad_group / create_responsive_search_ad without opening any 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?

Routes Performance Max explicitly to create_performance_max_campaign and points to update_campaign and add_negative_keywords for follow-up language concerns. However, it never states the obvious boundary that this tool only builds the campaign shell and that ad groups, keywords and ads require the create_ad_group / add_keywords / create_responsive_search_ad 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?

Goes well beyond the annotations: states it creates exactly one ENABLED action, 'changes nothing else', and never edits/demotes/removes existing actions or goals — which confirms the destructiveHint=false and idempotentHint=false hints in concrete terms. It also discloses the side-effect caveat that no conversions are counted until the Tag Manager container is published.

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?

Front-loaded: the core action, the WEBPAGE-only constraint, and the downstream Tag Manager requirement all come before the parameter list. The Args block repeats a little (e.g. primary_for_goal's meaning appears twice), but given 0% schema coverage that verbosity is functional rather than wasteful.

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 10-parameter mutation with an output schema present, the description covers creation semantics, defaults, side effects, failure modes, and the post-creation workflow the agent must drive. Nothing needed to invoke it correctly or to hand its result to gtm_create_tag 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 coverage is 0%, so the description carries the full burden and does: customer_id format (digits, no hyphens), name uniqueness, the full category enum, the meaning and bidding consequence of primary_for_goal, the unit gotcha for default_value ('a plain amount, not micros'), ISO 4217 for the currency code, per-category counting_type defaults, and the 1-90 range for the lookback window.

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+resource ('Creates a Google Ads conversion action') and immediately parenthesizes what a conversion action is, plus states that the return carries the conversion_id/label for the website tag. It is clearly distinguishable from GA4-side conversion tools (ga4_create_conversion_event) and from read-only siblings like conversion_setup_audit.

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 scopes what is creatable ('Only type WEBPAGE'), states an exclusion with rationale ('Analytics-imported types ... cannot be created through the Google Ads API and are refused with an explanation'), and names the follow-on path (stage via Tag Manager using the returned ids, nothing counted until publish). It even instructs the agent to ask the user for primary_for_goal rather than guessing.

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

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

Annotations declare readOnlyHint=false, destructiveHint=false, idempotentHint=false and openWorldHint=true; the description adds substantive context beyond that: the 5120 KB cap, format restriction, aspect-ratio/minimum-dimension requirements per asset type, and the Search-account eligibility/refusal rules. It does not explain what happens on re-upload of the same asset name (duplicate creation) or any permission requirements, which keeps it short of a 5.

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

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

Front-loaded with the core action, then a clearly separated usage section and an Args section. Every sentence carries non-redundant information, though the aspect-ratio enumeration is dense and slightly long relative to the core call decision.

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 and the description only briefly gestures at return values (resource name, mime_type, width, height), which is acceptable. With three undocumented-in-schema parameters, the description fully compensates on inputs, constraints, and downstream routing, leaving nothing an agent needs to call this tool correctly.

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

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

Schema description coverage is 0%, so the description carries the full burden and does so: customer_id is 'numbers only, no hyphens', image_source enumerates the three accepted forms (http(s) URL, base64 data URI, local file path) and warns the path form only works when the server shares the filesystem. asset_name is described as the asset's display name. All three parameters gain meaning absent from the schema.

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

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

The first sentence names a specific verb and resource — 'Uploads a PNG or JPEG image (max 5120 KB) to the account's asset library' — which is immediately distinguishable from siblings like create_text_asset, create_youtube_video_asset, or create_logo_asset variants. Scope and accepted formats are stated up front, so an agent can select it without opening 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 explicitly routes the agent: use add_assets_to_asset_group for Performance Max, link_asset_to_campaign / link_asset_to_ad_group for Search, and it names the exact asset field types (MARKETING_IMAGE, SQUARE_MARKETING_IMAGE, LOGO, AD_IMAGE, BUSINESS_LOGO) each context accepts. It also states the negative case — marketing image and logo types are refused for Search campaigns — which is genuine 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?

Annotations already declare the safety profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false, openWorldHint=false), so the bar is lower. The description adds that the asset collects user information from the ad and gives character limits, but says nothing about permissions, verification requirements for lead forms, or irreversibility of the creation.

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

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

Front-loaded with a clear purpose sentence and a one-line behavioral gloss before the Args block. The Args list is long but every line earns its place given 0% schema coverage; the Returns block is mildly redundant since an output schema exists.

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 9-parameter mutation tool with 7 required fields and no schema descriptions, the description supplies everything needed to construct a valid call: every parameter, character limits, enum vocabularies, and which two are optional. An output schema already documents the return value, so the brief Returns line is sufficient.

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

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

Schema description coverage is 0%, so the description must carry the full burden and it does: all nine parameters are explained, including a note that customer_id takes numbers only with no hyphens, max lengths for headline (30) and description (200), and the full allowed-value lists for call_to_action_type (14 values) and fields (13 values) that the schema does not encode as enums.

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 ('Creates a lead form asset') and adds a clarifying sentence about what the asset is for ('collect user information directly from the ad'). It implicitly distinguishes itself from the many other create_*_asset siblings through the unique resource name, but never explicitly contrasts with e.g. create_call_asset or create_text_asset.

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 'can be linked to campaigns or ad groups' implies the follow-up step (link_asset_to_campaign / link_asset_to_ad_group), which is useful implied usage. However there is no explicit when-to-use vs. alternative asset types, no prerequisites, and no note on account/permission requirements before creation.

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

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

Annotations already declare non-read-only, non-destructive, non-idempotent, closed-world. The description adds real behavior beyond that: the list is inert until attached, exact duplicate keywords are silently dropped, and the name must be unique among the account's negative keyword lists. It does not cover failure modes (e.g. duplicate name error) or permission requirements, so it is strong but not complete.

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?

Front-loaded with the one-line purpose, then scope, then args. Every paragraph earns its place except the Returns block, which partly restates what the output schema already provides. Dense but not padded.

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

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

With an output schema present, the description need not explain return values, and it still summarizes them briefly. Combined with annotations and full param documentation, an agent has everything needed to construct a correct call and knows what to do next with the resulting list.

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 types keywords as an untyped object map, so the description carries the entire burden. It documents all three parameters: customer_id format ('numbers only, no hyphens'), name constraints (unique, 1-255 chars), and keyword structure with text plus match_type values EXACT/PHRASE/BROAD and a BROAD default — information that exists nowhere in the schema.

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

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

Opens with a specific verb+resource ('Creates a shared negative keyword list, optionally with its keywords') and immediately defines what a shared list is versus the per-campaign/account negative tools in the sibling set. An agent can distinguish this from add_negative_keywords and attach_negative_keyword_list without opening any schema.

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

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

Explicitly states the key usage fact ('The list does nothing until it is attached') and names attach_negative_keyword_list, add_to_negative_keyword_list and remove_from_negative_keyword_list as the follow-up paths. It stops short of a decision rule versus account-level or campaign-level negative tools, so the when-not guidance 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?

Adds substantial behavior beyond the annotations: only PAUSED is accepted and ENABLED calls are refused entirely, languages changes ad-matching semantics per channel, and over_comfort_ack is recorded locally and never sent to Google. None of that is inferable from destructiveHint/openWorldHint/idempotentHint.

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?

Front-loaded with the action then ordered workflow steps, and the Args block maps to the parameter list; nearly every sentence is load-bearing. The languages paragraph runs long and the Returns note duplicates the output 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 14-parameter mutation with an output schema and prerequisites on other tools, the description covers ordering, defaults, currency units, constraints, and side effects. Nothing an agent needs before invoking it is absent.

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

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

Schema description coverage is 0%, so the description carries the full burden and does: micros-to-currency conversion with an INR/USD example, logo dimension requirement, customer_id format, date formats, bidding-strategy-conditional target_cpa_micros vs target_roas, and language code examples. The one weak spot is bidding_strategy_type lacking a stated pairing rule with target_cpa/roas beyond 'optional with'.

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 ('Creates a Performance Max campaign') plus the mandatory inputs, which separates it cleanly from the sibling create_campaign and create_asset_group tools. An agent can pick this tool without opening 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?

Gives an explicit prerequisite chain (create_text_asset / create_image_asset first, then pass resource names) and a follow-up chain (more assets, then create_asset_group). What's missing is an explicit statement of when NOT to use it — e.g. that non-PMax campaigns go to create_campaign.

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

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

Annotations already declare the mutation profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false), so the description needn't restate them. It usefully adds hard constraints (3–8 offerings, 25-char limits) that predict validation failures, but says nothing about required permissions or what happens on quota/permission errors.

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?

Front-loaded with the action, then structured Args/Returns sections with no filler beyond the one explanatory line about what price assets are. The nested offering bullet list is efficient, though the "Returns" line is redundant given an output schema exists.

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 creation tool with an output schema, the description covers the inputs, the required multi-element list, and the return value. The remaining gap is workflow context — that the created asset still needs a separate link call — which the description only gestures at.

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

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

Schema description coverage is 0%, so the description carries the full burden and does so: every one of the 5 parameters is documented, including allowed enum values for price_type, price_qualifier and unit, the micros conversion example (9990000 = 9.99), defaults for currency_code, language_code and price_qualifier, and the nested offering field list. This is meaningfully more than the schema conveys.

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

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

The first sentence names a specific verb and resource ("Creates a price asset") and the second clarifies the concept, which distinguishes it from the many sibling asset creators (callout, sitelink, text, image) by subject matter. It does not explicitly contrast with those siblings, 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 clause "can be linked to campaigns or ad groups" implies the follow-up step, but no explicit when-to-use rule or naming of the alternatives (link_asset_to_campaign, link_asset_to_ad_group) is given. An agent must infer that creation alone leaves the asset unattached.

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

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

The annotations already declare that this is a non-read-only, non-destructive, non-idempotent creation operation. The description adds that the resulting asset can be linked to campaigns or ad groups and returns a resource name, but it does not discuss permissions, side effects, duplicate creation behavior, or linking requirements beyond that brief mention.

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 appropriately so for a 14-parameter creation tool. It is front-loaded with the core action and asset explanation, then organizes parameter details cleanly under Args and Returns with no meaningful filler.

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

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

Given the output schema and annotations, the description covers nearly everything needed to invoke the tool correctly, especially the full parameter semantics. The only notable gap is that it does not explain the subsequent linking lifecycle in detail, despite mentioning that the asset can be linked.

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 carries the full burden and does so thoroughly. It documents all 14 parameters, including formats, defaults, enum values, the percent_off versus money_amount_off_micros choice, micros conversion, currency expectations, and date formats.

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 gives a specific verb and resource: it creates a promotion asset. It also explains that promotion assets highlight sales and special offers, which distinguishes this asset type from the many other create_*_asset siblings.

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

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

The description implies the tool is for sales and special-offer promotions, but it does not explicitly say when to choose this over alternatives such as create_price_asset, create_callout_asset, or create_sitelink_asset. It also does not mention prerequisites beyond the required landing page.

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

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

Annotations already declare readOnly=false, destructiveHint=true, idempotent=false, and openWorld=true, so the mutation profile is covered. The description adds genuinely useful behavior beyond that: it explains that an ENABLED ad in a running campaign serves immediately from the campaign budget once Google approves it, and that PAUSED holds it. It does not mention that creation cannot be undone or any required OAuth/permission scope, which keeps it short of a 5.

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

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

The purpose is front-loaded, followed by a short explanatory paragraph, then a clean Args section and a one-line Returns. Given that the schema has no parameter descriptions, the long Args block earns its space; the Returns note is slightly redundant because an output schema exists.

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 non-idempotent, destructive-annotated mutation tool with an output schema, the description covers what is created, all constraints, the status semantics, and the return value. An agent has everything needed to invoke it correctly; the only gap is sibling routing, which is not essential 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 carries the full burden, and it does: customer_id format ('numbers only, no hyphens'), headline min/max counts and 30-character limit, description min/max counts and 90-character limit, path1/path2 optionality plus 15-character limits, and status enum values with default. This is complete semantic coverage for all 8 parameters.

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

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

The description states a precise verb and resource ('Creates a responsive search ad in an ad group') and follows with a one-line explanation of what an RSA is, so an agent knows exactly which entity is produced. It distinguishes the ad type from asset-creation siblings (create_text_asset, create_image_asset, etc.) by naming the ad unit explicitly, though it never contrasts itself with those tools in words.

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

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

Usage is only implied: you call this when you need an RSA placed in an existing ad group. There is no explicit 'use this instead of create_text_asset' or prerequisite guidance (e.g., that the ad group must already exist, or that headlines/descriptions become assets), and no when-not-to-use conditions.

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

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

Annotations already declare this is a non-read-only, non-destructive, non-idempotent write operation, so the safety profile is covered. The description adds concrete field constraints (25-char link text, 35-char description lines, YYYY-MM-DD dates), but omits operational behavior an agent would want: whether the created asset is auto-attached to anything, whether it requires review/approval, and what happens on duplicate calls given idempotentHint=false.

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

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

Purpose is front-loaded in the first sentence, followed by a short explanatory line and a clean Args block. The Returns line slightly duplicates what the output schema already declares, but overall there is no filler.

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

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

For a 7-parameter mutation with zero schema descriptions, the definition supplies enough to fill the fields correctly, and the presence of an output schema means return values need not be spelled out. The remaining gap is workflow context — that creation and linking are separate steps — which an agent would need to complete the task.

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

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

Schema description coverage is 0%, so the description carries the full burden and does so: all seven parameters are documented with meaning, the required/optional split, character limits and the date format, plus the notable 'numbers only, no hyphens' rule for customer_id. This is meaningfully more than the schema titles 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?

States a specific verb and resource ('Creates a sitelink asset') and adds a one-line explanation of what sitelinks are, which implicitly separates it from the other create_*_asset siblings. It never explicitly contrasts itself with create_callout_asset or create_text_asset, so the differentiation is inferential rather than stated.

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

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

The phrase 'can be linked to campaigns or ad groups' hints at the create-then-link workflow, but it never says the asset must subsequently be attached via link_asset_to_campaign or link_asset_to_ad_group, nor when a sitelink is preferable to another asset type. Usage is implied rather than guided.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=false and destructiveHint=false, so the mutation profile is covered. The description adds the useful operational note that at least 3 values are recommended and that the asset only takes effect once linked, but says nothing about validation failures, account permissions, or what happens on duplicate creation.

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

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

Front-loaded with the purpose sentence, then a clarifying example, then per-argument notes. Every section earns its place, though the Args/Returns scaffolding is slightly verbose for only three 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?

For a 3-parameter mutation tool with full annotation coverage and an output schema, the definition supplies the essential enum, format constraints, and linking context. The only real gap is guidance on what happens when creation fails or the header/values pair is rejected.

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

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

Schema description coverage is 0%, so the description carries the full burden and does it well: it documents the numeric-only, hyphen-free format for customer_id, enumerates the complete allowed header list (the schema has no enum at all), and gives the minimum-values recommendation for the values array.

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

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

The first sentence states a specific verb and resource ('Creates a structured snippet asset') and adds where it can be applied (campaigns or ad groups). The concrete example (header 'Brands' with values ['Nike', 'Adidas', 'Puma']) makes the asset type unmistakable against the many other create_*_asset siblings.

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

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

The description notes the asset 'can be linked to campaigns or ad groups', which hints at the follow-up linking workflow, but it never states when an agent should choose this asset type over create_callout_asset or create_sitelink_asset, nor any exclusions or prerequisites. Usage context is implied rather than prescribed.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=false, destructiveHint=false, openWorldHint=false, so safety is covered. The description adds character limits and the return shape, which is useful, but it does not warn that the non-idempotent behavior means repeated calls create duplicate assets, nor does it state account-access 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?

Front-loaded with the action and scope, then a short usage line and compact Args/Returns block. The Returns section is slightly redundant given an output schema exists, but overall the text is tight with no wasted sentences.

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 two-parameter creation tool with an output schema, the description covers both parameters, the character-limit constraint, and the returned resource name. Missing only cross-tool workflow context (create here, then link) which would complete the picture.

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

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

Schema description coverage is 0%, so the description carries the burden and largely meets it: it explains customer_id must be numbers only with no hyphens, and maps text to per-type character limits (30/90/90). Only omission is that the caller must pick a type implicitly via the limit, with no parameter for it.

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

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

States a specific verb and resource (create text asset) and narrows scope to Performance Max asset groups, listing the three text sub-types it covers. It differentiates implicitly from siblings like create_call_asset or create_image_asset by naming text asset types, though it never names an alternative explicitly.

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

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

"Use this to create headline, description, and long headline assets that can be linked to asset groups" gives implied usage context, but there is no when-not guidance, no mention that linking requires add_assets_to_asset_group or link_asset_to_ad_group, and no prerequisites (permissions, campaign type).

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false and openWorldHint=true, so the safety profile is covered. The description adds one genuinely useful behavior: asset_name falls back to the video ID when omitted, and a resource name is returned. It does not warn that because the call is non-idempotent, repeated invocations create duplicate assets, nor mention permission requirements on the customer.

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 sentence is front-loaded and the Args/Returns block is compact and scannable. The docstring scaffolding is slightly formal for a three-parameter tool, but every line conveys real information.

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

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

For a simple three-parameter create call with an output schema present (so return values need no elaboration), the definition covers purpose, inputs and the default-name behavior adequately. The notable omission is lifecycle context — that the asset is inert until linked to a campaign or asset group.

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

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

Schema description coverage is 0%, so the description carries the full burden and largely meets it: customer_id format is specified (numbers only, no hyphens), youtube_video_id is explained with a URL-extraction example, and asset_name's optional default behavior is stated. What is missing is validation guidance, such as what happens if the video ID is invalid or not owned by the account.

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 ("Creates a YouTube video asset") plus the campaign context ("for use in Performance Max campaigns"), which cleanly separates it from sibling create_*_asset tools by resource type. It stops short of naming which sibling it complements (link_asset_to_campaign / link_assets_to_customer) to actually get the asset served.

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 Performance Max note implies when this tool is appropriate, but there is no explicit when-to-use/when-not or comparison to the many other create_*_asset siblings. Critically, it never says the created asset must subsequently be linked via link_asset_to_campaign or link_assets_to_customer before it has any effect.

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

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

Annotations already declare read-only, idempotent, non-destructive behavior. The description adds valuable context beyond that: it will not invoke a tool call and instead returns step-by-step guidance for fixing losing day-parts. It does not describe data freshness or output shape, but the output schema covers return structure.

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 and the description is only a few sentences. The trailing 'Tools revision' line is metadata noise that does not help an agent decide or invoke the tool, but the rest 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 description is adequate for understanding the analytical intent and the no-tool-call behavior, and the output schema handles return values. However, with five parameters at 0% schema description coverage, the definition is incomplete on how to configure the analysis.

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

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

Schema description coverage is 0%, so the description must carry the burden. It does not explain the days, detail, render, max_findings, or customer_id parameters, aside from an implicit 90-day default. An agent cannot learn from the description how to control scope, detail level, or output rendering.

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 analytical operation: breaking 90 days of cost, conversions, and CPA down by day of week and hour, and identifying money-losing and underserved day-parts. It clearly distinguishes this diagnostic tool from the sibling mutation tool set_ad_schedule by noting that it only provides steps and returns no tool call.

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 clear implied usage context: use this to diagnose day-part performance and get guidance for schedule changes. It also implicitly routes agents to set_ad_schedule for actually applying changes. It does not explicitly state when not to use this versus other analysis tools like analyze_waste or bidding_audit.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context by listing what it reads—conversion action windows, counting and attribution, date bases, Analytics attribution model, lookback windows, export scope—and what output themes it reports, including named causes and unexplained remainder.

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 and mostly efficient: purpose first, then data sources read, then output content. The trailing 'Tools revision' line is non-functional noise, preventing a perfect conciseness score.

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

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

The description explains the analytical purpose and much of the underlying behavior, and an output schema exists so return values need not be detailed. However, for an 8-parameter read tool with 0% schema description coverage, it leaves parameter meaning and usage routing substantially incomplete.

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

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

Schema description coverage is 0% across 8 parameters, and the description does not explain any parameter semantics. It implies concepts like dates, conversion actions, and Analytics properties, but does not clarify customer_id, detail, render, ga4_event, conversion_action_id, or date-format expectations beyond the schema titles.

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 gives a specific verb and resource: explain why Google Ads and Analytics report different conversion counts for the same dates. It clearly frames the task, but it does not explicitly distinguish this from nearby siblings such as conversion_setup_audit or ga4_get_attribution_settings.

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

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

Usage is implied by the 'same dates' discrepancy context, but the description gives no explicit when-to-use/when-not guidance and does not point agents to or away from alternative tools for attribution or conversion setup checks.

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

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

The annotations already establish read-only, idempotent, non-destructive behavior. The description adds useful behavioral detail beyond that: check counts, health-scoring, findings ordering by failure/severity/status, advice-only trailing items, some results carrying a fixing call, and the get_org_context prerequisite.

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-loads the audit scope, but it is extremely telegraphic and some phrases are cryptic, such as 'not impact' and 'advice-only last per status.' It avoids waste but sacrifices readability.

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

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

For a complex 7-parameter audit tool, it covers the broad purpose, depth modes, sections, result ordering, and prerequisite context well. Still, with 0% schema description coverage, missing render and max_findings explanations leave notable gaps for correct invocation.

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

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

Schema description coverage is 0%, so the description carries the full burden. It clarifies depth (deep default, quick scores three), detail full, days, and sections via named checks, but it does not explain render enum values, max_findings, or customer_id.

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

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

The description clearly states a specific verb and resource: auditing a Google Ads account across conversion tracking, wasted spend, structure, keywords, ads, and settings. It differentiates deep vs quick modes and names check IDs, but it does not explicitly distinguish itself from sibling audit tools such as account_health_score or conversion_setup_audit.

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 some usage context by saying deep is the default with 74 checks and quick scores three month-to-date, and it mentions using named checks with their sections and detail full. However, it gives no explicit when-not conditions or alternatives, so an agent must infer when to choose this over narrower audit siblings.

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

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

The description adds real value beyond the annotations by disclosing the no-op path for events that are already key events and the resulting 'already_key_event: true' field. However it says nothing about required permissions, whether the conversion is applied immediately, or other side effects; note also the mild tension with idempotentHint=false, since a same-argument repeat appears to be a no-op.

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 and the duplicate-handling behavior follows compactly. The trailing 'Tools revision: 5c9bea8f.' is internal build noise that earns no place in an agent-facing description.

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 values are covered, and the top-level purpose is clear. But for a two-parameter creation tool with zero schema documentation and no alternatives guidance, the description leaves too much for an agent to guess — particularly the property identifier format and the relationship to ga4_update_conversion_event.

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 does not: 'property' (presumably a 'properties/123456789' resource name) and 'event_name' formats are never explained. An agent could easily pass a bare numeric ID or a display name and fail.

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 ('Mark an event as a conversion on a GA4 property'), which is far better than a tautology. It doesn't differentiate itself from near-siblings like ga4_update_conversion_event or ga4_list_conversion_events, so an agent must infer create-vs-update from the name alone.

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 explicit when-to-use guidance: nothing says when to call this versus ga4_update_conversion_event, nor what prerequisites (property ID format, admin permissions) must hold. The only conditional described is the duplicate case, which is behavioral rather than 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?

Annotations already declare readOnlyHint=false, idempotentHint=false, destructiveHint=false, and openWorldHint=false, so the basic safety profile is covered. The description adds only that creation targets a GA4 property; it does not explain whether new dimensions become immediately active, whether names must be unique, or what happens on duplicate creation attempts.

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 first sentence is front-loaded and efficient, but the second sentence is a revision tag that adds no invocation value. The overall definition is concise but under-specified rather than optimally 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?

For a four-parameter mutation tool with zero schema description coverage, the description is too thin. Even with an output schema handling return values, an agent lacks enough context to confidently supply parameter_name, display_name, and scope.

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% for all four parameters, so the description must carry the burden. It only mentions 'property' and says nothing about parameter_name, display_name, or the scope default of EVENT, leaving critical parameter meaning undocumented.

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

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

The description states a specific verb and resource: create a custom dimension on a GA4 property. It distinguishes the tool from siblings like ga4_create_custom_metric and ga4_update_custom_dimension by naming the resource and operation, though it does not explicitly route away from alternatives.

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

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

The description gives no indication of when to use this tool versus alternatives such as ga4_create_custom_metric or ga4_update_custom_dimension, nor does it mention prerequisites like required GA4 permissions or property readiness.

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

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

Annotations already indicate this is a non-readonly, non-idempotent, non-destructive, closed-world mutation. The description adds no behavioral context beyond the property target, such as permission requirements, side effects, or whether repeated calls create duplicates.

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 a single clear sentence, but the trailing "Tools revision: 5c9bea8f." adds no task-relevant value. The description is concise but too sparse for the tool's complexity.

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

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

This is a five-parameter mutation with zero schema description coverage. Although annotations cover basic safety and an output schema exists, the input semantics are essentially undocumented, leaving the agent under-equipped 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 description coverage is 0%, and the description provides no explanation of the five parameters. It does not clarify the difference between parameter_name and display_name, the meaning of scope, or valid measurement_unit values.

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

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

The description states a specific verb and resource: "Create a custom metric on a GA4 property." This is clear enough to distinguish creation from update/list siblings, but it does not distinguish custom metrics from the closely related ga4_create_custom_dimension.

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 on when to use this tool versus ga4_create_custom_dimension, ga4_update_custom_metric, or ga4_list_custom_metrics. It also omits prerequisites such as required GA4 permissions or property scope.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=false, destructiveHint=false, openWorldHint=false, so the mutation profile is covered without the description. The description adds nothing beyond them: it doesn't say what state a new stream starts in, whether duplicates are possible, or what permissions are needed. The 'Tools revision: 5c9bea8f' line is versioning noise, not behavioral context.

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

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

The operational sentence is short and front-loaded with no wasted words. The appended 'Tools revision' line is dead weight but small enough not to disrupt the structure.

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

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

A mutation tool with an output schema (so return values needn't be explained) but with 0% parameter coverage and an untyped nested object parameter, the description leaves an agent guessing about required formats and valid stream types. It is not complete enough to invoke confidently without inspecting the upstream GA4 API.

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% on all four parameters, so the description must compensate and instead says nothing about them. Key unknowns remain: the required 'property' format (e.g., 'properties/123456'), the allowed stream_type values and what changing them implies, and the shape of the free-form 'web_stream_data' object that anyOf accepts.

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?

Names a specific verb and resource ('Create a data stream on a GA4 property'), which cleanly separates it from the ga4_list_data_streams and ga4_update_data_stream siblings by operation. It doesn't explicitly call out those siblings, but the operation prefix makes disambiguation straightforward.

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 statement of when to use this versus ga4_update_data_stream (which presumably configures an existing stream) or ga4_create_property (which a stream likely depends on). No preconditions such as needing an existing GA4 property ID.

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

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

Annotations already mark this as a non-destructive write, and the description adds meaningful context beyond them: the link has no unlink tool, so it persists; linking shares audience and remarketing data when personalization is enabled; and duplicates are preventable by checking first. Those are exactly the side effects an agent needs before calling a mutation.

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

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

Four tight sentences: purpose and rationale first, parameter formats next, then prerequisite and irreversibility. Every sentence adds information an agent can act on.

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 three parameters are explained despite zero schema descriptions, the prerequisite is named, and the output schema handles return values. Nothing needed to call it correctly is missing.

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

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

Schema coverage is 0%, so the description carries the full burden. It gives the property format ('properties/<id>'), says customer_id is the Ads account number with hyphens stripped, and explains that ads_personalization_enabled defaults off and what it actually enables.

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 ('Link') and both resources (GA4 property and Google Ads account) and explains the effect on key events and paid/organic traffic. It also distinguishes itself from the sibling ga4_list_google_ads_links and notes there is no unlink counterpart.

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

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

Explicitly instructs to read ga4_list_google_ads_links first so an agent avoids creating a duplicate link, and says ads_personalization_enabled should stay off unless the user asks. That covers both when to use it and how to gate the risky option.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false and idempotentHint=false, so the agent knows this is a non-destructive, non-idempotent mutation. The description adds useful operational context the annotations cannot: where defaults come from, what to do when they are missing, and the expected next call in the workflow.

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

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

Front-loaded with the action and scope, then defaults-sourcing, then param formats, then the next step — a sensible ordering. Slightly dense with an awkward line break mid-sentence, but nearly every clause carries 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?

An output schema exists, so return-value explanation is unnecessary, and the description covers the workflow gap around default values and the natural successor tool. The only hole is the optional industry_category, which is undocumented anywhere in the 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% (titles only), so the description carries the burden — and it does for the two error-prone params, specifying time_zone as an IANA name with an example and currency_code as ISO 4217 with an example, plus the accounts/<id> format for account. display_name is self-evident, but industry_category is left entirely unexplained in both schema and description.

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 GA4 property') and pins the parent scope ('under an Analytics account (accounts/<id>)'), including the resource-name format. An agent can distinguish it from ga4_update_property and the other ga4_create_* siblings without opening a 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?

Gives real routing guidance: pull time zone and currency from get_org_context (the Analytics card's property_defaults), and if absent, ask the user rather than guessing. It also names the follow-up step, ga4_create_data_stream. It does not, however, contrast this with ga4_provision_account, which is the nearest alternative for account/property setup.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds value by disclosing the response shape — Google's raw answer plus a `plain` summary of the four settings — which tells the agent what to expect back. It does not discuss permissions or quotas, but those are minor for a read.

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?

Core content is front-loaded in one dense, useful sentence covering what is read and what is returned. The trailing 'Tools revision: 5c9bea8f.' is build metadata that does not help an agent select or invoke the tool.

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

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

For a one-parameter, read-only tool with an output schema, the description supplies the necessary scope and a summary of the returned fields. The only real gap is the exact form of the `property` argument, which neither the schema nor the description pins down.

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 single `property` parameter has no schema-level documentation. The description partially compensates with the '(properties/<id>)' hint, suggesting the GA4 resource-name form, but it stays ambiguous about whether a bare numeric ID is accepted or whether the full 'properties/123' string 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?

States a specific verb and resource ('Read a GA4 property's attribution settings') and then enumerates exactly what is retrieved: attribution model, lookback windows for first-visit/first-open and other key events, and Google Ads credit channels. The read/update split against the sibling ga4_update_attribution_settings is unambiguous from the verb alone.

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

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

Usage is only implied: reading current attribution configuration is the obvious precursor to ga4_update_attribution_settings, but the description never says when to call this versus the update tool, nor does it mention prerequisites such as property access. An agent can infer intent, but nothing 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the description need not restate safety. It adds nothing beyond that: no note on scope (built-in vs custom), freshness, or result size. The only extra line is a build revision string, which is not behavioral context.

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

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

The core sentence is efficient and front-loaded, but the second line about the tools revision is operational noise that does not help an agent select or invoke the tool.

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

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

The presence of an output schema means return values need not be described. However, for a tool whose only input is an undocumented property identifier, the description should carry the identifier format, and it does not.

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% for the single required 'property' parameter. The description does not clarify the expected identifier form (e.g., 'properties/123456789'), so the agent gets no help on a parameter that must be supplied correctly.

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

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

Specific verb and resource: lists the dimensions and metrics available for a GA4 property. It is distinguishable from ga4_list_custom_dimensions and ga4_list_custom_metrics, though it never says explicitly that it covers the built-in/all available set versus custom-only, which would have sharpened the sibling distinction.

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 when-to-use guidance or named alternatives. The metadata-lookup-before-reporting use case is only implied by the word 'available'. An agent must infer that this is for discovering valid dimension/metric 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?

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so safety is covered. The description adds the useful access-scope caveat that results are limited to what the current Google login can reach, but says nothing about pagination behavior despite exposing a page_size 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 first sentence is well-formed and front-loaded, but the trailing 'Tools revision: 5c9bea8f.' is internal bookkeeping that gives an agent nothing and dilutes the definition.

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 values need not be described. Still, for a list tool with a paging parameter the description should say whether results are paginated and how this differs from ga4_list_properties; both gaps remain.

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% for the single page_size parameter, so the schema provides no meaning at all. The description never mentions paging, the default of 200, or whether there is a next-page token, leaving the one parameter entirely unexplained.

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

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

States a specific verb and resource ('List GA4 accounts and their properties') plus a permission scope ('this Google login can reach'), which is much clearer than the title alone. It does not, however, explicitly distinguish itself from the sibling ga4_list_properties, which an agent could easily confuse it with.

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

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

Usage is only implied: the permission-scoped phrasing suggests this is the discovery/bootstrap call before property-specific tools like ga4_list_properties or ga4_run_report. There is no explicit statement of when to prefer this tool over those siblings and no 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so safety is fully covered. The description adds nothing beyond that — no pagination behavior, no note on what 'configured' events include (e.g., whether they're limited to Google Ads conversion imports).

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 core sentence is appropriately short and front-loaded, but the second line ('Tools revision: 5c9bea8f.') is internal noise that consumes space without helping an agent select or invoke the tool.

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

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

An output schema exists, so return values need not be explained. However, for a tool whose only parameter has zero schema documentation and whose purpose overlaps several conversion-event siblings, the description leaves real gaps an agent would need filled.

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 there is one required parameter ('property'). The description only echoes 'on a GA4 property' without giving the expected identifier format (e.g., 'properties/123456789'), so it fails to compensate for the undocumented schema.

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

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

States a specific verb and resource: listing conversion events configured on a GA4 property. An agent can tell what it does, but the description gives no cue to distinguish it from siblings like ga4_list_data_streams, ga4_create_conversion_event, or ga4_update_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?

No guidance on when to call this versus the related conversion-event tools (ga4_create_conversion_event, ga4_update_conversion_event, conversion_setup_audit). The agent must infer usage purely from the name.

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

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

Annotations already fully declare readOnlyHint, idempotentHint, and non-destructive behavior, so the description needs to add context it does not supply — no pagination behavior, no note on return shape, and the only extra sentence is a 'Tools revision' marker that carries no behavioral information.

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 first sentence is tight and front-loaded, but the second sentence ('Tools revision: 5c9bea8f.') is build metadata that adds no value for an agent and should not be in a tool description.

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

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

For a simple read-only listing tool with a full annotation set and an output schema, the description covers the essentials; the main missing piece is what form the 'property' argument takes, which the agent needs to call it correctly.

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

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

The single required parameter 'property' has 0% schema description coverage, and the description does nothing to clarify the expected format (numeric ID vs. 'properties/123' resource name). With low coverage the description should compensate but does not.

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

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

Clear verb + resource ("List the custom dimensions of a GA4 property") that is unambiguously distinct from siblings like ga4_list_custom_metrics and ga4_create_custom_dimension. It does not explicitly contrast with those siblings, but the name and phrasing make the scope obvious.

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 guidance on when to use this versus the related tools (create/update custom dimension, list custom metrics), and no prerequisites or exclusions stated beyond the implied 'I need to see existing dimensions' context.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds nothing beyond that—no mention of pagination, result size, or whether archived/created-in-UI metrics are included—and the 'Tools revision' line is noise rather than 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 core sentence is front-loaded and wastes no words. The trailing 'Tools revision: 5c9bea8f.' adds no decision-relevant information and could be dropped.

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 values needn't be described, and the read-only annotations are complete. But for a one-parameter call whose only parameter is undocumented in the schema, the description leaves the critical identifier format unstated, making the definition incomplete 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 for the single required 'property' parameter, but it never explains that this is a GA4 property identifier or what format (e.g., 'properties/123456789') to pass. Without that, agents are likely to pass a display name and fail.

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

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

States a specific verb and resource: list the custom metrics belonging to a GA4 property. It is clearly distinct from ga4_create_custom_metric and ga4_update_custom_metric by the 'list' verb, but the description never names those siblings or scoping conditions explicitly.

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

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

There is no guidance on when to use this versus ga4_list_custom_dimensions, ga4_get_metadata, or the create/update counterparts, and no prerequisites such as permissions or required property ID format. The agent must infer usage from the verb alone.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so safety is fully covered. The description adds only the property resource path convention; it says nothing about result ordering, pagination, or permissions beyond what annotations provide, and the 'Tools revision' line is inert metadata.

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

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

The core sentence is front-loaded and efficient. The trailing 'Tools revision: 5c9bea8f.' sentence conveys nothing to an agent and dilutes the signal, but total length is small.

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

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

A read-only single-parameter list tool with rich annotations and an output schema needs little prose; purpose plus the property path format is sufficient to call it correctly. Only the source of the property id (via ga4_list_properties) 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 coverage is 0%, so the description carries the burden for the single required parameter. It does compensate meaningfully by defining 'property' as a GA4 property in the form properties/<id>, which is the key detail the bare schema lacks, but it omits where to obtain that 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 verb and resource (list data streams of a GA4 property) and even names the resource path shape (properties/<id>). It is distinguishable from siblings like ga4_create_data_stream and ga4_update_data_stream, though it never explicitly contrasts itself with ga4_list_properties or 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 listing intent implies when to use it, and the property path hint supports invocation, but there is no explicit guidance on prerequisites (which property to pick, or that ga4_list_properties should be called first to obtain the id) and no named alternatives.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds only the domain gloss 'paid+organic join' and says nothing about return shape, pagination, or what happens when no links exist.

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

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

The purpose sentence is front-loaded and efficient, but the trailing 'Tools revision: 5c9bea8f.' is build metadata that adds no invocation value and dilutes an already thin description.

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 values need not be described, and annotations carry the safety profile. Still, for a tool whose only parameter is undocumented in both schema and description, the definition leaves a real gap on how to address the property.

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 single 'property' parameter has no description or format hint in the schema. The description only says 'of a GA4 property', leaving the agent to guess whether it takes a numeric ID, 'properties/123' resource name, or a display name.

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

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

Specific verb+resource: 'List the Google Ads links of a GA4 property', with a parenthetical clarifying the concept (paid+organic join). It is clearly the read counterpart to ga4_create_google_ads_link, though the description never names that sibling explicitly.

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

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

No when-to-use guidance, no prerequisites (e.g., that the property must exist and have a linked Google Ads account), and no mention of the create/alternatives. Usage is only inferable from the verb 'List'.

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