Caybl

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

Annotations cover the safety profile (readOnlyHint=false, destructiveHint=false), so the bar is lower, and the description adds genuine behavioral context by spelling out blast radius: the change affects only one ad group and explicitly not the campaign. It stops short of disclosing what happens on duplicate keywords (idempotentHint=false suggests duplicates accumulate) or what the call returns.

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

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

Two sentences, zero filler, with the scope constraint front-loaded and the alternative-routing sentence placed second. Every clause earns its place.

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

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

For a 5-param mutation tool with nested objects, no output schema and full annotation coverage, the description handles the routing and scope questions well. It is slightly thin on post-call expectations (e.g. whether duplicates are deduped, what errors look like), which validateOnly partially mitigates in the schema.

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 60%: customerId, extraFields and validateOnly are well documented inline, while adGroupId, keywords and matchType carry no description. The description adds nothing about parameters, but the undocumented fields are largely self-explanatory, so this sits at the moderate-coverage baseline.

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 (add) and resource (negative keywords) plus a precise scope constraint ('scoped to a single ad group, not the whole campaign'), which cleanly separates it from the sibling add_negative_keywords. No schema opening is needed to tell the two apart.

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 gives the when-to-use condition ('a search term is wasteful for one ad group's theme but still relevant to another') and names the alternative for the opposite case (add_negative_keywords at campaign level, with the reason: fewer calls). This is exactly the routing guidance an agent needs.

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

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

Beyond the annotations (readOnlyHint=false, destructiveHint=false, non-idempotent), the description adds real behavioral context: the operation is free, creates the assets and links them in one atomic mutate, and mirrors add_sitelinks. Atomicity is a useful trait not captured by the annotations. It does not mention idempotency/re-run behavior, so it falls 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?

Three sentences, front-loaded with the definition before the value proposition and mechanics. Efficient overall, though the sitelinks analogy is stated twice ('the same way sitelinks do' and 'same as add_sitelinks'), a slight redundancy that could be tightened.

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 campaign-level mutation with no output schema, the description covers what it does, its atomic nature, and its cost/benefit. Combined with the annotation safety profile and the richly documented schema (validateOnly, extraFields, customerId), an agent has what it needs. Return values and permissions are not addressed, keeping it short of 5.

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

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

Schema description coverage is 80%, so the schema already carries most parameter meaning (including the 25-char/20-item limits and the detailed customerId and extraFields docs). The description adds no parameter-specific detail, which is acceptable at this coverage but earns no bonus.

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 (add) and resource (callouts) and defines what callouts are with concrete examples ('Read-only access', 'No card required'). It also anchors the concept against a known sibling ('same way sitelinks do', 'same as add_sitelinks'), so an agent can place it precisely 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?

Usage is implied: this is the tool to add callout extensions at the campaign level, and it is framed as parallel to add_sitelinks. However, there is no explicit when-to-use/when-not statement or a directive telling the agent to prefer this over a sibling for a given goal, so routing is left to 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?

Annotations cover the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false) and the description adds a genuinely useful behavioral fact not in the annotations: keywords are created PAUSED by default, so nothing starts spending immediately. It omits idempotency behavior (duplicates on retry) and the 500-keyword batch ceiling, which would have completed the picture for a non-idempotent write tool.

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

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

Three short sentences, all front-loaded: the action first, then the key decision (match type), then the critical default. No filler. It is slightly terse on the operational constraints (limits, validation) rather than bloated.

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

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

For a nested-object, non-idempotent mutation with no output schema, the description covers the action, match-type trade-off, and the PAUSED default, which is a solid minimum. It leaves out what the call returns, how duplicate keywords are handled, and the 500-item batch limit — gaps an agent would want before issuing a bulk write.

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 50%, and the schema itself already carries defaults for status (PAUSED) and matchType (EXACT) as well as prose for customerId, extraFields, cpcBid, and validateOnly. The description's match-type elaboration adds real meaning to the matchType enum but does not cover the undocumented half, so this sits at the baseline.

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

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

States a specific verb+resource ('Add positive keywords to an ad group') and the word 'positive' explicitly separates it from the sibling negative-keyword tools (add_negative_keywords, add_ad_group_negative_keywords). An agent can pick the right tool from the name and first sentence 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?

The description gives clear context for choosing between match types (BROAD widest/fastest spend, PHRASE narrower, EXACT tightest), which is the main decision an agent faces here. It does not, however, name the negative-keyword siblings as the alternative when negatives are needed, nor mention validateOnly as a prerequisite step; those are left to 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?

Annotations already declare destructiveHint=false and the mutation nature, but the description adds real value by clarifying the direction of effect: it 'only ever reduces reach and spend,' which lets an agent reason about blast radius. It omits reversibility/permissions detail, but the safety signal is genuinely additive beyond the annotations.

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

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

Two sentences, front-loaded with the core action and effect, with no filler. 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?

For a write tool whose annotations and schema already carry the safety profile and the tricky parameters (customerId, extraFields, validateOnly), the description covers purpose, effect direction, and use context. Given no output schema, it need not document returns; only matchType semantics are left unaddressed.

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

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

The description says nothing about any of the five parameters, while schema description coverage sits at only 60%: keywords, its matchType enum, and campaignId carry no descriptions anywhere. The description does not compensate for that gap, so it adds no parameter meaning.

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

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

States a specific verb and resource ('Add campaign-level negative keywords') and immediately explains the effect ('stop ads showing for those searches'). The 'campaign-level' qualifier explicitly distinguishes it from the sibling add_ad_group_negative_keywords.

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

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

Gives clear context for use ('the usual first response to wasteful search terms found via get_search_terms'), naming both the triggering situation and the sibling tool that surfaces it. It does not state when NOT to use it (e.g. ad-group-level negatives), so it falls just short of a 5.

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

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

Annotations only give the safety profile (not read-only, not idempotent, not destructive, open world). The description adds substantial context beyond that: it discloses the atomic mutate that creates assets and links in one operation, the failure mode (no orphaned unlinked asset), and the cost behavior (free). It omits a warning that, being non-idempotent, re-runs may create duplicate sitelinks, which is a notable gap.

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

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

Three tightly written sentences, front-loaded with the definition of sitelinks before the benefit and atomicity details. Every clause carries information; there is no filler or repetition of the title.

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 mutation with nested objects and no output schema, the description covers the key behavioral essentials (atomicity, cost, validateOnly scope). It could be stronger by noting what the tool returns or how re-invocation behaves for a non-idempotent create, but nothing critical to correct invocation is missing.

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

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

Schema description coverage is 60%, so the description must partly compensate. It reinforces validateOnly semantics (validates the whole atomic operation) but adds little on the sitelinks array shape or the extraFields escape hatch beyond what the schema already documents. Baseline 3 is appropriate given the schema does most of the work.

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 ('Add sitelinks ... to a campaign') and disambiguates what sitelinks are with concrete examples (/pricing, /security). It is clearly distinguishable from siblings like add_callouts or add_keywords. No ambiguity about the operation.

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

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

The description motivates use (raises CTR/Quality Score, lowers CPC) and mentions that validateOnly checks the whole operation, which implies a dry-run-first workflow. However, it never states when NOT to use it or names an alternative sibling (e.g. add_callouts), so usage guidance is implied rather than explicit.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=false, destructiveHint=false, and openWorldHint=true, so the mutation/safety profile is largely covered. The description adds that the object is created PAUSED by default and clarifies what cpcBid governs, which is useful context, though the PAUSED state is also encoded in the schema's status default. No auth or rate-limit detail is added.

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 short sentences, front-loaded with the core action and followed by two high-value defaults. Nothing is wasted, though the cpcBid sentence is largely redundant with the schema and the whole thing could be tightened to two 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 7-parameter mutation tool with no output schema and rich annotation coverage, the description covers purpose and the key default state. The schema's unusually thorough extraFields and validateOnly descriptions carry the remaining detail, so the description is adequate without duplicating them.

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

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

Schema description coverage is high (86%), so the schema already documents name, cpcBid, status, campaignId, customerId, extraFields, and validateOnly. The description only lightly reinforces cpcBid's role as the default max CPC for keywords in the group, adding little beyond the schema. Baseline 3 is appropriate.

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

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

States a specific verb+resource+scope: 'Create a Search ad group inside a campaign.' An agent can distinguish it from create_campaign and update_ad_group by the 'Create' verb and 'ad group' resource. It does not name a sibling alternative, but the purpose is unambiguous.

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

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

No explicit when-to-use, when-not-to-use, or prerequisite guidance is given. The PAUSED-by-default note is behavioral, not routing guidance. The agent must infer that a campaign must already exist and that this is the create-vs-update path 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 only declare the generic profile (not read-only, open-world, non-idempotent). The description adds what they cannot: the campaign is created PAUSED as a safety default so it cannot spend before human review, and the extraFields escape hatch can never override status or other safety defaults. That is exactly the mutation-safety context an agent needs before spending money.

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 short sentences, front-loaded with the action, then the safety default, then the prerequisite. No filler, and the riskiest piece of information (ENABLED is opt-in) is stated early.

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

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

For an 11-parameter mutation tool with no output schema, the description covers purpose, prerequisite, and safety defaults well. It does not say what a successful call returns (e.g. the new campaign id), which an agent chaining into update_campaign would want, but the schema and annotations otherwise carry the load.

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

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

Schema description coverage is 100%, so baselines to 3, and the schema already explains status defaults, extraFields, validateOnly, and customerId resolution in depth. The description restates the status default rather than adding syntax or new parameter meaning, so it does not exceed the schema baseline.

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 Search campaign') plus a key constraint ('against an existing budget'), which implicitly separates it from budget-creation siblings. It explicitly names create_campaign_budget, so an agent can route correctly without opening either schema.

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

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

Gives an explicit prerequisite ('Create the budget first with create_campaign_budget') and an explicit when-to-use condition for the risky path ('pass status=ENABLED only when that is intended'). The default-PAUSED guidance tells the agent which behavior to expect when it says nothing.

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

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

Annotations already establish this is a non-read-only, non-idempotent, non-destructive write, and the description adds the prerequisite relationship to campaigns plus a unit caveat on amount. It does not warn about the practical consequence of idempotentHint=false (retrying on an ambiguous failure can create a duplicate budget), which is the main behavioral risk here.

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

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

Two short sentences, front-loaded with the action and immediately followed by the workflow constraint. No filler, and the amount-unit note is a brief, high-value caveat.

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

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

For a 6-param write tool with full schema coverage and no output schema, the description supplies the key missing context (prerequisite ordering, units). It omits what a created budget looks like in the response and whether the shared-budget flag changes behavior for future campaigns, but those are secondary.

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

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

Schema description coverage is 100% and each parameter (including validateOnly, extraFields, explicitlyShared) is well documented inline, so the baseline is 3. The description only restates the 'account currency, not micros' point already present in the amount schema, adding no new semantics.

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

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

States a specific verb and resource ('Create a shared daily campaign budget') and immediately clarifies its position among siblings: it is a prerequisite for create_campaign and distinct from update_campaign_budget. An agent can place it in the workflow 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 explicit sequencing guidance ('a campaign cannot be created without one, so this is normally the first write call'), which routes the agent correctly relative to create_campaign and update_campaign_budget. It stops short of naming alternatives or stating when not to call it (e.g., if a budget already exists).

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

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

Annotations only declare a generic non-read-only open-world mutation; the description adds real behavioral detail the annotations cannot express: the duplicate-pair error condition, the required analytics scope, and that a pre-scope connection will refuse until reconnected (needsReconsent). This is substantive context beyond structured fields.

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 action and the duplicate-check caveat, then adds workflow and scope context. Three dense sentences with no filler, though the third sentence is run-on and could be split.

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

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

For a mutation tool with no output schema, the description covers the error condition, prerequisite scope, reconnection requirement, and adjacent workflow steps. An agent has everything needed to call it and handle failures.

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 67%: customerId and adsPersonalizationEnabled are documented in the schema, but 'property' has no description in either place. The description adds no parameter-level meaning, so it neither compensates for the gap nor documents the format expectations for property.

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

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

States a specific verb (Link) and both resources (GA4 property, Google Ads customer account), which immediately distinguishes it from delete_google_ads_link and list_google_ads_links in the sibling set.

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

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

Explicitly routes the agent to list_google_ads_links as a pre-check and warns that this errors if a link already exists. It also names the downstream workflow (mark_key_event, then update_ga4_conversion_action), so when-to-use and what-comes-next are both covered.

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 (openWorldHint, non-idempotent, non-destructive), the description discloses genuinely useful behavior: Google's headline/description limits are enforced before the API call for fail-fast validation, and the ad is created PAUSED by default. That 'enforced here so a bad draft fails fast rather than as an opaque API error' detail is real added context.

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

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

Three front-loaded sentences: purpose first, then the enforcement/limits rationale, then the safety default. Tight overall, though the limits sentence partially duplicates schema constraints and could be trimmed.

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 tool with no output schema, the description covers the essential safety default (PAUSED) and the validation behavior. Parameter-level detail and the customerId/extraFields semantics are left to the schema (80% coverage), which is acceptable, so little is missing.

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

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

Schema description coverage is high (80%), so the schema already documents most parameters, including the headline/description counts and character limits and the PAUSED status default. The description restates those limits but adds no syntax or meaning beyond the schema; baseline 3 is appropriate.

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

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

States a specific verb and resource — 'Create a responsive search ad in an ad group' — so the agent knows exactly what the tool does. It distinguishes itself from sibling create_* tools by resource type (responsive search ad vs campaign, ad group, budget), but doesn't explicitly name or contrast any 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?

Usage is only implied: the agent infers you use this to build a new RSA rather than calling an update or get tool. There is no explicit when/when-not guidance and no named alternative (though there happens to be no other ad-creation sibling to route to).

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 and openWorldHint=true, but the description adds genuinely new behavioral context: the required analytics scope, the needsReconsent/reconnect failure mode for older connections, and the error when no matching link exists. It does not state whether the removal is reversible or what is returned, 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 action and resource, followed by the reason, the sibling to consult, the error condition, and the auth caveat — each sentence carries information. The parenthetical example and the needsReconsent aside are slightly dense, but nothing is wasted.

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

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

For a destructive, open-world tool with no output schema, the description covers the essential prerequisites (analytics scope, reconsent), the pre-check step, and the failure mode. It leaves the return value and the required-vs-optional status of `property` unaddressed, but an agent has enough 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 coverage is 50%: customerId is documented in the schema, but `property` has no description anywhere. The description implies the two parameters form the property/account pair being removed but adds no format or validity detail for `property`, so it only marginally compensates for the coverage gap.

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

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

States a specific verb+resource ('Remove the Google Ads link between a GA4 property and a customer account') and clearly distinguishes itself from create_google_ads_link and list_google_ads_links in the sibling set. An agent can identify the target object of the operation 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?

Names the alternative (list_google_ads_links) and the condition that selects it ('check what's currently linked first'), and gives a concrete motivating scenario (fixing a link to the wrong account). It also states the failure condition ('errors if no link exists for that pair'), which is exactly the routing information an agent needs.

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, non-destructive, openWorld). The description adds genuine behavioral context beyond them: it queries Search Console impressions, requires a caller-supplied URL list because Caybl tracks none, and normalizes scheme (http/https) and trailing-slash variants automatically. It omits return shape and rate/pagination limits, but those are secondary here.

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 the first sentence and each following clause carries information (why `urls` is required, URL-variant matching). It is somewhat dense and long-winded, but little of it is filler, so it stays efficient despite the length.

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

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

With no output schema, the description usefully states what is returned (which supplied URLs got zero impressions). It justifies the required parameter and the loose URL matching, which are the non-obvious details for correct invocation. Date-window semantics are left to the schema, which is acceptable at this complexity.

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

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

Schema coverage is 75%, so the schema already documents the main parameters. The description adds real meaning for `urls` (the caller's tracked page list, matched loosely against Search Console forms), but says nothing about startDate/endDate/siteUrl beyond what the schema provides. Baseline 3 is appropriate given the schema does most of the lifting.

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

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

The description names a specific verb (find/return which) and resource (tracked pages with zero Search Console impressions over a window), so an agent can tell what it produces. It stops short of naming a sibling alternative (e.g. inspect_url, run_search_analytics_report) to distinguish itself explicitly, so it lands just below the top tier.

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: diagnosing a suspected indexing problem ('manual indexing check... rather than assuming it's simply low demand'). It also explains why the caller must supply URLs. No explicit when-not or named alternative is provided, keeping it at 4 rather than 5.

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

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

Annotations already declare readOnly/openWorld/non-destructive, so the safety bar is low, yet the description adds genuine value: the output shape (volume, competition, bid estimates) and the important caveat that volume is bucketed by Google rather than exact. That bucketing note is the kind of trait annotations cannot 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 compact clauses, front-loaded with the tool's identity and outputs, no filler. Every sentence carries information, though the final bucketing note could be folded in slightly tighter.

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?

No output schema exists, and the description compensates by naming what is returned. For a read-only ideation tool with non-required params this is close to sufficient, with only the customerId/limit and pagination behavior left unaddressed.

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 67%, so the schema already documents pageUrl, keywords, languageId and geoTargetIds. The description adds the useful 'and/or' relationship between keywords and pageUrl, but says nothing about the undocumented customerId or limit 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?

States a specific verb+resource ('Keyword Planner ideas for seed keywords and/or a URL') and enumerates the returned metrics (volume, competition score, top-of-page bid estimates). This is clearly distinguishable from mutation siblings like add_keywords and update_keyword, though it never names a 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?

The phrase 'Works pre-spend' implies it can be used before a campaign exists, which is real context, but there is no explicit when-to-use guidance, no prerequisites (e.g. whether a customerId is required), and no alternatives named despite many sibling research/report tools.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so safety and scope are covered. The description adds only the permission-scoping detail ('this connection can access') and says nothing about result shape or pagination for a listing tool with no output schema.

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

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

A single front-loaded sentence with no filler or repetition. It is slightly terse for the role it plays as the entry-point discovery call, but nothing in it is wasted.

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

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

With no parameters, no output schema, and annotations covering the safety profile, the description states the one thing an agent needs: that this returns the accounts/properties available to the connection. Return-field detail is not described but the tool is simple enough that this is a minor gap.

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

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

The tool takes zero parameters, so the baseline of 4 applies. There is nothing for the description to disambiguate, and it correctly does not invent parameter behavior.

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 (List) plus resources (GA accounts and properties), with the scope qualifier 'this connection can access'. The agent can tell it apart from list_accessible_customers and list_sites by resource type, though the description never explicitly contrasts with those 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?

No statement of when to call this versus alternatives such as run_gaql_report, get_property_details, or list_sites, and no prerequisites. The only hint of context is the phrase 'this connection can access', which implies scoped discovery but is not framed as 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=true, non-destructive, and openWorld, so the safety profile is covered. The description adds that it returns id/name/status/type and parent campaign, which is useful, but says nothing about pagination, result limits, or what includeRemoved does to the result set.

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 compact sentence that front-loads the action and scope, then lists the output fields. No filler, no redundancy with the title.

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

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

With no output schema, the description helpfully lists the returned fields, which covers the return-value gap. But for a three-parameter read tool it omits the meaning of includeRemoved (the only parameter that changes result scope) and any pagination or result-size expectations.

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 only 33%: campaignId is documented in the schema, and the description restates that filter, but customerId and includeRemoved have no schema description and the description never mentions them. With low coverage the description needed to compensate and largely does not, leaving two of three parameters unexplained.

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

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

States a specific verb and resource ('List ad groups') plus the scoping dimension ('for an account, optionally filtered to one campaign') and enumerates the returned fields. This distinguishes it reasonably from write-oriented siblings like create_ad_group/update_ad_group, though it never names a read sibling such as get_campaigns to contrast 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?

The parenthetical 'optionally filtered to one campaign' implies when the campaignId path is appropriate, so usage is inferable. However there is no explicit when-to-use/when-not guidance and no mention of the alternative read tools (get_campaigns, get_ad_performance) an agent should consider 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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so safety is covered. The description adds genuinely useful behavior beyond that: the default 30-day date window and the fact that results can be scoped by campaign or ad group id, neither of which the schema states for startDate/endDate defaults.

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 front-loaded sentences with no filler; the ad-vs-campaign distinction leads and the default window trails. The parenthetical about headlines/descriptions earns its place by clarifying what the breakdown exposes, though the em-dash clause makes the opener slightly heavy.

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 six optional parameters, no required params, no output schema, and low schema coverage, the description supplies the key operating context (granularity, default window, scoping filters). Remaining gaps are limit default and customerId semantics, which are minor for a read-only report tool.

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

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

Schema description coverage is only 33% (only campaignId and adGroupId are annotated). The description partially compensates by explaining the campaign/ad-group filter intent and implying the default date range, but leaves limit, customerId, and the date format for startDate/endDate undocumented in both places.

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 ('performance broken down by individual ad'), and sharply distinguishes itself from the sibling get_campaign_performance, which it names explicitly as campaign-level only. An agent can pick between the two without opening either schema.

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

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

Explicitly routes the agent: use this for per-ad (responsive search ad) granularity, use get_campaign_performance for campaign-level roll-ups. It also states the default window (last 30 days) and the optional narrowing via campaign/ad group ids, so invocation conditions are covered.

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, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds genuine domain behavior beyond that: the trap that a campaign lacking location targeting defaults to Google's broadest reach rather than 'no targeting'. It stops short of describing the return shape/format, which matters given there is no output schema.

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

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

Three sentences, front-loaded with what is retrieved, then the contrast with the sibling, then the actionable recommendation. Every sentence earns its place with no redundancy or filler.

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

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

For a read-only tool whose annotations carry the safety profile and with no output schema to explain, the description is nearly complete: it covers scope, sibling contrast, and a critical default-behavior warning. The only gap is the undocumented customerId parameter and any indication of the returned structure.

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 50%: campaignId is documented ('Campaign id from get_campaigns') but customerId has no description in either schema or prose. The description adds no parameter-level meaning at all, so it fails to compensate for the undocumented half of the parameters.

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

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

The description states a precise verb+resource: it returns the targeting controls (location, excluded devices, ad schedule, negative keywords) for a campaign. It explicitly distinguishes itself from get_campaigns by contrasting the structural fields that tool covers. An agent can tell exactly what this tool fetches versus the 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?

It names the alternative (get_campaigns) and its scope, then gives a concrete trigger: 'Check this before enabling any campaign meant for specific markets or hours.' It also explains the failure mode of skipping it (missing location targeting defaults to broadest reach). This is explicit when-to-use guidance tied to a real risk.

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, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description goes beyond them with genuinely useful behavior: costs are in account currency converted from micros, and the range defaults to the last 30 days. It stops short of describing aggregation granularity or return shape.

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

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

Two tight sentences that front-load the returned metrics and append the currency/default-window caveats. No filler, 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?

With no output schema, the metric list usefully compensates for the missing return documentation, and the zero-required-parameter design is partly addressed by the default-range note. It still omits customerId resolution, aggregation granularity (per campaign per day vs. aggregate), and any pagination or result-size limits.

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 67%, and the description reinforces the date semantics (last-30-day default) rather than extending them. The undocumented customerId parameter gets no explanation in either place, and no date-format or requiredness detail is added beyond the schema's own notes.

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+resource and enumerates the exact metrics returned (impressions, clicks, cost, conversions, CTR, avg CPC), which is more than a tautology. It does not, however, differentiate itself from near-siblings like get_ad_performance or get_campaigns, leaving the agent to 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?

The only usage signal is the default window (last 30 days). There is no statement of when to choose this over get_ad_performance, get_campaigns, or run_report, and no prerequisites or exclusions are given.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds useful behavioral scope beyond the annotations: it returns structural fields only and intentionally excludes performance metrics. It doesn't discuss pagination or result volume, which is the remaining gap.

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

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

Two sentences, no filler, and the scope constraint plus the alternative tool are front-loaded so the routing decision is made immediately.

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

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

There is no output schema, so the enumeration of returned fields carries real weight and compensates well. It is nearly complete for a two-parameter read tool, lacking only minor details such as whether results are paginated or how removed campaigns appear.

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

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

Schema description coverage is 100%, so both customerId and includeRemoved are already documented in the schema, including the important multi-account error behavior. The description mentions returned fields rather than parameters and adds no parameter syntax beyond the schema — baseline 3 is appropriate.

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

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

States a specific verb+resource ('List campaigns for an account') and enumerates the returned structure (id, name, status, channel type, bidding strategy, daily budget). It also explicitly differentiates itself from the sibling get_campaign_performance, so an agent can route without opening either schema.

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

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

Names the alternative tool (get_campaign_performance) and the exact condition that selects it ('for spend/results'), and clarifies the scope boundary of this tool ('Structure only (no performance metrics)'). This is explicit when-to-use/when-to-use-something-else 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=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds only the scoping detail that results are the definitions on a GA4 property; it says nothing about return shape, pagination, or authorization needs.

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

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

A single efficient sentence with no filler, front-loaded with the verb and resource. It is appropriately sized, though its brevity is partly under-specification rather than tightness.

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 no output schema, the description is minimally adequate, but it leaves the one required parameter's semantics undocumented and gives no hint about the structure or volume of returned definitions.

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 is undocumented everywhere. The description mentions a GA4 property but gives no expected identifier format (e.g. properties/1234), so it fails to compensate for the schema gap.

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

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

States a specific verb (List) and specific resources (custom dimensions and custom metrics) scoped to a GA4 property. It is unambiguous and no sibling overlaps with this resource, though it does not explicitly differentiate itself from sibling 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?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as run_gaql_report or get_property_details for related metadata. The agent must infer usage entirely from the purpose statement.

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

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

Annotations already establish readOnly/non-destructive/openWorld safety. Beyond that, the description discloses two genuinely useful behaviors: the API-level limitation on competitor data and the default 30-day window. It stops short of describing pagination, granularity options, or return shape.

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 resource and metrics, then the disambiguating NOTE, then the default window. Three tight clauses, 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?

No output schema exists, yet the description names the metric family returned, which is the key informational need. The remaining gap is parameter documentation and return structure, minor for a simple read-only metrics 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% for 3 parameters. The description only covers the date-range default ('last 30 days'), leaving startDate/endDate format and customerId entirely undocumented in both schema and description. It partially compensates but far from fully.

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

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

States a specific verb/resource ('search impression-share metrics per campaign') and enumerates the exact metrics returned (share, top, absolute-top, lost to rank vs budget). The caveat that this is your account's share and not the competitor-domain Auction Insights report cleanly separates it from any competitor-comparison 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?

Usage is implied by the metric list and the NOTE clarifies what the tool cannot do (no competitor Auction Insights), which is a useful when-not. However, it never routes the agent among sibling reporting tools (e.g. get_campaign_performance, run_report) or states prerequisites such as needed customerId/permissions.

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, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful return-content context by listing name, timezone, currency, and type, but it does not disclose behavioral details such as auth requirements, error behavior, or pagination.

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

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

The description is a single efficient sentence with the action and resource front-loaded. It contains no redundant or filler 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?

For a simple read-only lookup with one well-documented parameter and no output schema, the description is mostly complete because it names the resource and gives examples of returned fields. It could be slightly stronger by clarifying the expected property ID format or explicitly noting that the property is required despite required-parameter count being zero.

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

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

Schema description coverage is 100%, and the single 'property' parameter is already documented in the schema as a GA property ID like 'properties/123'. The description only says 'specific GA4 property' and adds no syntax, format, or optionality information beyond the schema.

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

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

The description uses a specific verb ('Return details') and resource ('a specific GA4 property'), and lists example fields returned. It distinguishes this tool from sibling property-detail tools such as get_search_console_property_details by explicitly naming GA4.

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, no prerequisites, and no alternatives named. The purpose implies that this is used when property details are needed, but the description does not help an agent choose between this and related lookup tools like get_resource_metadata or get_account_summaries.

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 (readOnlyHint=true, openWorldHint=true, destructiveHint=false), and the description goes further by naming the returned payload fields (category, metrics, segments, related resources). With no output schema, that content disclosure is genuinely additive, though it omits anything about lookup failure behavior for unknown resources.

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 tightly packed sentences: the first defines the operation and payload, the second states the downstream purpose. No filler, and the core purpose is front-loaded.

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

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

For a read-only metadata lookup with no output schema, the description adequately covers what the tool returns and why it exists. The only shortfall is silence on the optional `customerId` and on behavior for invalid resource names.

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

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

Schema coverage is 50%: `resource` is documented in the schema with its own examples, and the description merely repeats example values ('campaign', 'ad_group'), adding no new format or nesting guidance. The undocumented `customerId` is not explained in the description either, so the coverage gap is not compensated.

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

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

States a specific verb ('Describe') and resource ('a Google Ads API resource type') with concrete examples, and enumerates exactly what the response contains: category, selectable metrics/segments, related resources. This sharply distinguishes it from run_gaql_report, which consumes its output rather than producing metadata.

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 ties the tool to a downstream purpose ('Helps construct GAQL for run_gaql_report'), which tells the agent when to reach for it. It does not state when NOT to use it (e.g. skip it if you already know the resource schema), but the context is clear enough to route correctly.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds the useful behavioral detail that the return is a permission level rather than full property metadata, but says nothing about failure behavior when the property is inaccessible.

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 short sentence with the core verb and result front-loaded; every word earns its place and there is no filler.

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

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

With no output schema, the description must carry return-value semantics; it states the return is a permission level, which is the essential point, but omits the possible permission values (e.g. siteOwner/siteFullUser) and any error conditions. Adequate but with clear gaps for a tool whose whole output is the described value.

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

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

Schema coverage is 100% and the single siteUrl parameter is fully documented with format examples in the schema. The description only alludes to 'a single Search Console property' without adding syntax or format detail beyond what the schema already provides, so the baseline of 3 applies.

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

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

States a specific verb ('Return') and resource ('your permission level for a single Search Console property'), which an agent can distinguish from siblings like get_property_details or list_sites. It does not explicitly name those siblings, but the resource is specific enough to be actionable.

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

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

There is no guidance on when to use this tool versus alternatives such as get_property_details or list_sites, nor any stated prerequisites (e.g. that the property must be one the user has access to). The agent must infer usage entirely from the name and description.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful return-field context (impressions/clicks/cost/conversions) and a default 30-day window, but omits auth needs, rate limits, and pagination behavior.

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

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

Two tight sentences front-load what the tool returns, then add a use case and a default behavior. Every sentence earns its place with no wasted wording.

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

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

The description covers purpose, use case, returned metrics, and a default date range, which is helpful because annotations cover safety. But for a 4-parameter tool with zero schema descriptions and no output schema, it is thin on parameter guidance and does not fully compensate for the missing structured documentation.

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

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

With 4 parameters and 0% schema description coverage, the description must carry the burden of explaining parameters. It only hints at the date default ('last 30 days') and says nothing about limit, customerId, or date formats, leaving most 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?

States the specific resource (actual search queries that triggered ads) and the metrics returned, so the agent knows what the tool produces. However, it does not differentiate this report from sibling report tools such as run_report or get_ad_performance, which limits it to a 4.

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

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

Gives a clear use context—spotting wasted spend and finding negative-keyword candidates—which tells the agent when the tool is valuable. It does not name alternative tools or specify when not to use it, so it falls short of a 5.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description goes beyond that by naming the concrete data returned (download status, errors/warnings, submission vs. index counts), which is valuable given there is no output schema.

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

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

A single front-loaded sentence that delivers purpose and return content with zero filler. Nothing to trim.

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

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

With no output schema, the description usefully summarizes the return payload, but it leaves the siteUrl parameter's role unexplained and gives no pagination or error-handling context. Adequate but with a clear parameter gap.

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

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

Schema description coverage is only 50%: feedpath is documented in the schema, but siteUrl has no description anywhere. The description mentions no parameters at all, so it does not compensate for the undocumented optional siteUrl (e.g., when it is required vs. defaulted).

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 (get) and resource (sitemap) plus the scope 'one specific sitemap,' which distinguishes it from the sibling list_sitemaps. It also enumerates exactly what status is returned: last downloaded, errors/warnings, URLs submitted vs. indexed.

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 'one specific sitemap' implies this is the single-sitemap counterpart to list_sitemaps, but no explicit when-to-use guidance or named alternative is given. Usage is only inferable.

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, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds that the data is 'live' and names the reported categories, which is useful context, but says nothing about rate limits, auth requirements, or whether inspecting a non-indexed URL 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?

Two tight sentences with zero waste. The concrete capability list is front-loaded and the use-case framing follows immediately.

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

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

With no output schema, the description usefully enumerates the returned fields, which is the main thing an agent needs. The only gap is the undocumented siteUrl parameter and no indication of what happens for a non-indexed or invalid URL.

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 67%: url and languageCode are documented in the schema, siteUrl is not. The description adds no parameter detail beyond reinforcing the single-URL scope, so it neither compensates for the gap nor adds meaning over 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?

States a specific verb and resource ('Live index status for one URL') and enumerates exactly what it reports: indexed status, Google-selected canonical, mobile usability, rich results. The framing sentence ('why isn't this page performing') further distinguishes it from the create/update/report 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?

Gives a clear situational trigger: use it diagnostically before deciding what to change on a page. However, it names no alternative — notably find_zero_visibility_pages, the closest sibling, is not mentioned, so the agent must infer the boundary itself.

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, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuinely non-obvious cross-tool behavior — that downstream tools self-select when only one account is reachable — which is not derivable from annotations or schema.

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

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

Two sentences, front-loaded with the action and result, followed by the exact downstream usage. No filler or restatement of the title.

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

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

With no output schema, the description usefully signals that the return value is a set of customer ids, and it explains when the tool must actually be called. Minor gap: it does not state what happens on zero reachable accounts, but that is a small omission for a zero-param list tool.

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

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

This tool takes zero parameters, so the baseline is 4. The mention of customerId adds useful framing about how the output feeds other tools, though it is not a parameter of this tool.

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

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

States a specific verb and resource — 'List the Google Ads accounts (customer ids) this connection can access' — and clarifies the return type as customer ids. It is trivially distinguishable from siblings like get_account_summaries or create_google_ads_link.

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

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

Explicitly tells the agent what to do with the result ('Pass one as customerId for the other tools') and the condition under which it matters ('only required when more than one account is reachable'). It also pre-empts a needless call by explaining that other tools auto-pick a single account.

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, destructiveHint=false, and openWorldHint=true, covering the safety profile. The description adds only the scoping fact that links are per-GA4-property; it says nothing about pagination, result volume, or auth requirements beyond what annotations imply.

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

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

A single front-loaded sentence with no filler; the scope qualifier follows the verb+resource immediately.

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

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

For a simple read-only list tool with no output schema and one undocumented parameter, the description is adequate but thin: it neither explains the return shape (no output schema exists to cover it) nor the property identifier format.

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 'property' parameter has 0% schema description coverage, so the description must compensate. Mentioning 'configured on a GA4 property' ties the parameter to its meaning, but gives no format (e.g. properties/12345) and, notably, the schema marks it non-required while the description implies it is needed.

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

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

States a specific verb ('List') and resource ('Google Ads account links') scoped to a GA4 property. This clearly separates it from the create_google_ads_link and delete_google_ads_link siblings, though it doesn't name them 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 explicit when-to-use guidance, prerequisites, or alternatives. Usage is only implied by the verb 'List' and the mention of a GA4 property; the agent must infer it's the read-side counterpart to create/delete_google_ads_link.

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, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds useful context that last-read status is returned, but says nothing about pagination, empty results, or auth requirements beyond what annotations imply.

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

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

A single front-loaded sentence with zero filler words; the resource and its returned status are both stated efficiently.

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

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

For a simple single-parameter read tool this covers the core intent, and no output schema exists so return values need only minimal mention (it names last-read status). It falls short on documenting the sole parameter and any result-shape or pagination behavior.

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

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

Schema description coverage is 0% for the single siteUrl parameter, so the schema provides no help. The description compensates only partially by implying a property/property-scoped lookup, but never names the parameter or states its expected format (e.g. a URL).

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

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

The description states a specific verb (List), resource (sitemaps), and scope (for a property), plus the returned attribute (last-read status). It does not, however, distinguish itself from the sibling get_sitemap (singular), so an agent must infer the list-vs-single difference.

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, no mention of prerequisites (a verified property), and no reference to alternatives such as get_sitemap or submit_sitemap. Usage is only implied by the verb.

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, openWorldHint=true, destructiveHint=false, so safety is covered. The description adds genuine context beyond them: the response includes the caller's permission level per property, and the auto-pick behavior of sibling tools that determines whether siteUrl is needed. No return envelope or pagination details, but meaningful added value.

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

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

Three compact sentences: what is listed, what it returns, and how to use the result. Front-loaded with the core purpose and no wasted 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 zero-parameter discovery tool with no output schema, the description covers what is returned (properties plus permission level) and the cross-tool contract for siteUrl. Nothing an agent needs to invoke 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?

Zero parameters, so the baseline is 4. The description also adds semantic context about the `siteUrl` value produced here and consumed by other tools, tying the output to a parameter elsewhere in the toolset.

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

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

States a specific verb (List) and resource (Search Console properties), names the two property forms (domain or URL-prefix), and specifies the returned detail (permission level). This clearly separates it from siblings like get_search_console_property_details and get_property_details, which return details for a single known property.

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

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

Explicitly explains the downstream purpose of the result: 'Pass one as `siteUrl` for the other tools', and clarifies the conditional requirement ('only required when more than one property is reachable; the other tools auto-pick a single reachable property'). It tells the agent how this tool fits the workflow, though it does not state when *not* to call it or name a direct alternative lister.

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 context beyond the annotations: it requires the analytics scope, can hard-fail on stale connections pending reconsent, and clarifies there is no API call to trigger the sync (it happens implicitly once both resources exist). Annotations only cover read/write and open-world hints.

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 the first clause, and the remaining sentences carry prerequisites and downstream steps rather than filler. It is dense with nested parentheticals, which slightly taxes readability but each part earns its place.

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

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

For a mutation tool with no output schema, it covers the key operational context: required scope, reconsent failure mode, implicit sync behavior, and downstream tooling. It stops short of describing what the call returns or how to confirm success.

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 67%: eventName and countingMethod are already documented in the schema, and the description only adds illustrative example values for eventName. The 'property' parameter remains undocumented in both schema and description, so the description does not fully compensate.

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

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

States a specific verb and resource: marking a GA4 custom event as a key event, with concrete event-name examples. It also situates itself relative to siblings (create_google_ads_link, update_ga4_conversion_action) so an agent can identify it 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?

Spells out when to use it: together with create_google_ads_link as the prerequisite for Google Ads conversion sync, plus the follow-on step via update_ga4_conversion_action. It also names the exclusion condition — a connection made before the analytics scope was requested will refuse until reconnected.

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, readOnlyHint=false, and idempotentHint=false, so the safety profile is partly covered. The description adds a genuine behavioral trait beyond that: criteria have no paused state, so this removes them outright rather than disabling them. It stops short of describing permission requirements or what happens if the criterion no longer exists.

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

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

Two sentences, front-loaded with the action, then a clarifying constraint. The example and the no-paused-state note both earn their place by preventing a mistaken pause-then-remove attempt; 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 destructive mutation with no output schema, the description covers what it removes, the source tools, and the permanence nuance, while the schema richly documents parameters including the validateOnly dry run. Missing only edge-case behavior (criterion already gone, permission needs), which is minor given annotation and schema coverage.

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

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

The description says nothing about any of the 5 parameters. Schema description coverage is 80% (criterionId, customerId, extraFields, validateOnly are all documented in-schema), so the schema carries the load and the baseline of 3 applies. No extra syntax or format guidance is added beyond what the schema provides.

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

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

States a specific verb+resource (undo/remove a campaign-level criterion) and enumerates exactly which criterion kinds it covers (location, device exclusion, ad schedule block, negative keyword). Naming set_campaign_targeting and add_negative_keywords as the creators lets an agent distinguish this from the sibling add/get tools 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?

Explicitly states when to reach for it — undoing a criterion created by set_campaign_targeting or add_negative_keywords — and gives a concrete trigger example ('actually don't exclude mobile after all'). It also explains that criteria lack a paused state, so removal is the only disable path, which resolves the obvious alternative (why not just pause it?).

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

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

Annotations already declare the safe read-only profile, so the description is free to add value — and it does: it discloses the Exploration schema constraint, that pagePath is mapped to unifiedPagePathScreen, and that eventName should be used to match events. These are non-obvious behavioral caveats not captured in structured fields.

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 keeps the caveats in a compact NOTE clause; every sentence carries usable information. Slightly 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?

No output schema exists, so the description needn't cover return values, and annotations handle safety. For a moderate 5-param read tool it covers the distinctive funnel semantics well, though date-range and property parameters remain unaddressed.

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 only 20%, so the description must compensate. It does well for funnelSteps (spelling out the simple {name, dimension, matchValue} shape) and for funnel overriding funnelSteps, but startDate, endDate, and property are left 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+resource ('Run a GA4 funnel report') and pins the API version (Data API v1alpha). It distinguishes itself from the sibling run_report by noting the funnel-specific Exploration schema, so an agent can tell the two apart 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?

Explains the two ways to supply funnel structure (ordered funnelSteps vs raw funnel object) and warns that pagePath is invalid here, but never states the condition under which an agent should choose this tool over run_report or run_gaql_report. Usage context 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 readOnlyHint=true, destructiveHint=false, and openWorldHint=true, covering the safety profile. The description reinforces read-only behavior and adds 'only SELECT is allowed' and 'return the raw rows,' but does not disclose other operational traits like rate limits, pagination, or error handling. With annotations carrying the main behavioral load, this is a modest addition.

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 short sentences with no filler, and the core purpose and fallback guidance are front-loaded. It is appropriately sized for a tool description, with detailed parameter constraints correctly delegated to the schema.

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

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

For an arbitrary-query tool, the description covers the basic contract: read-only, SELECT-only, raw rows, and fallback role. However, it does not explain the customerId parameter, and without an output schema or annotations describing return shape beyond 'raw rows,' more context would help an agent invoke it confidently.

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

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

The description adds no parameter meaning; schema description coverage is only 50% because the required gaql parameter is richly documented in the schema while customerId has no description anywhere. The description does not compensate for the undocumented customerId or explain parameter formats, leaving a clear gap.

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

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

The description states a specific verb, resource, and scope: 'Run an arbitrary read-only GAQL SELECT against an account and return the raw rows.' It explicitly positions itself against siblings as 'the power tool for anything the structured tools don't cover,' so an agent can distinguish it from structured report tools without opening schemas.

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

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

It gives clear usage context: use this when structured tools do not cover the need, and it notes the SELECT-only restriction. However, it does not explicitly name alternatives or say when not to use it, so it falls short of the full when/when-not/alternatives 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=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds genuine behavioral context beyond that: the Realtime API enforces a small fixed schema and many run_report fields (e.g. pagePath, sessionSource) are invalid here, which tells the agent what will error. It doesn't mention rate limits or quotas, so it falls 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-loads the purpose before the field lists, and the long enumeration is necessary given zero schema coverage. It is dense but every clause earns its place; the only minor cost is the parenthetical that interrupts the opening sentence.

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

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

For a read-only report tool with no output schema, nothing an agent needs to invoke it correctly is missing, including the routing rule to run_report. The annotation and output-schema picture means no further return-value explanation is required.

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 dimension/metric arrays are bare strings with no enums, so the description carries the full burden. It compensates well by enumerating the complete valid set of dimensions (including the `customUser:<parameter_name>` pattern) and metrics, which is exactly what the schema lacks. It says nothing about `limit` or `property`, leaving those two params 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 ('Run a GA4 realtime report') and immediately defines the scope ('active users right now, by dimension'). It explicitly distinguishes itself from the similar-sounding sibling run_report, so an agent can pick the right tool without opening either schema.

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

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

Gives an explicit when and when-not: use this for realtime/active-user reporting, and 'use run_report instead for anything outside this list.' The condition selecting the alternative is spelled out rather than inferred, which is exactly the routing guidance the sibling set needs.

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

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

Annotations only cover the safety profile (readOnly/openWorld/destructive), leaving behavioral disclosure to the text, which delivers strongly: GA4's 4-dateRange ceiling with instructions to split calls, the 9-dimension nested-request accounting for filter dimensions, and the specific trap that a bare numericFilter value validates locally but is rejected at request time. These are exactly the runtime constraints an agent cannot get from structured fields.

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 and a concrete example before the constraint list, and nearly every sentence carries actionable content. The numericFilter explanation runs long with a restated GA4 error string, which is slightly redundant but justified by the severity of the pitfall.

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 12-parameter read-only report tool with no output schema, the description covers the tricky behavioral edges (date-range limits, dimension accounting, filter value typing) that would otherwise cause failed calls. Return-shape details are unnecessary absent an output schema, and the remaining minor gap is response/pagination shape.

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 only 58%, so the description must compensate, and it does for the complex parameters: it identifies dimensionFilter/metricFilter as GA4 FilterExpression objects, explains dateRanges override startDate/endDate and support multiple ranges, and gives a full worked numericFilter shape. It leaves the simpler fields (limit, keepEmptyRows, property) untouched, but the gap is minor.

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

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

The description names a specific verb and resource ('Run a GA4 report via the Data API') and describes the core shape (dimensions × metrics over a date range) with a concrete example. It does not, however, explicitly differentiate itself from adjacent report siblings like run_realtime_report, run_funnel_report, or run_gaql_report, so an agent must infer the routing.

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 substantial 'how-to-use' guidance (4-dateRange cap, 9-dimension limit, filter pass-through types, pagination via offset), and the worked example implies usage context. But there is no explicit when-to-use vs when-not or any statement naming an alternative report tool, so usage guidance remains 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?

Annotations only cover the read-only/non-destructive profile, but the description adds substantial behavior: internal 5000-row batching, early stop with nextStartRow for continuation, filter chunking under Google's undocumented filter-size ceiling possibly requiring multiple upstream calls, and collapseVariants recomputing ctr/position across merged rows.

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 before the option-by-option detail, and the dense sentences each carry distinct guidance about filtering, paging, or derived fields. It is long and near the upper bound of what is useful, but almost nothing is redundant.

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?

No output schema exists, so the description must carry the return-value burden; it names the metric fields, the nextStartRow continuation mechanism, and the brandedVsNonbranded derived field. It never details a full row shape or how dimensions map to row keys, leaving a small gap for a 10-parameter reporting tool.

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

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

With 60% schema coverage, the description supplies meaning beyond the schema for the hardest parameters: `discover`/`googleNews` semantics, searchAppearance as the AI-Overview proxy, the `in` versus regex tradeoff, and the derived brandedVsNonbranded field. A few parameters (siteUrl, rowLimit, endDate) remain unelaborated, but the complex ones are well covered.

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

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

States a specific verb and resource — organic search performance for a property — and enumerates the exact metrics (clicks, impressions, CTR, average position) and dimensions. An agent can distinguish this from GA4-oriented siblings like run_report or get_search_terms 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 clear operational context: default 28-day window, server-side filtering via pageFilters instead of client-side filtering on a maxed rowLimit, and `in` for allowlists vs regex. It does not explicitly compare against sibling tools (e.g. get_search_terms), so it stops short of full when/when-not routing.

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

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

Adds substantial non-obvious behavior beyond the annotations: device 'exclusion' is actually a 0 bid modifier because the API rejects `negative: true` on DEVICE criteria, and Google auto-creates MOBILE/TABLET/DESKTOP criteria so exclusion updates existing criteria while CONNECTED_TV gets created new. It also clarifies the additive nature of location targeting. No contradiction with destructiveHint=false or 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?

Front-loads the purpose in the first sentence, then spends space on genuinely non-obvious mechanics. It is long and partially duplicates the excludeDevices schema description, which is a minor redundancy, but every sentence carries information an agent would otherwise lack.

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 tool with no output schema and openWorldHint=true, the definition covers defaults, the broadest-reach trap, and the device-criterion mechanism. It does not describe the return payload or confirm what a successful call reports, leaving a modest gap.

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

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

Schema coverage is already 86%, so the baseline is 3; the description goes further by explaining the mechanism behind excludeDevices and clarifying that geoTargetIds is additive to existing criteria. It does not add new meaning for adSchedule or validateOnly beyond the schema.

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

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

States a specific verb+resource set: 'Add positive location targeting, device exclusions, and/or an ad schedule (day-parting) to a campaign.' It precisely enumerates the three capability areas and is distinguishable from siblings like update_campaign, get_campaign_criteria, and remove_campaign_criterion.

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

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

Gives clear conditional guidance: 'set this before enabling any campaign meant for specific markets,' and warns that omitting location criteria defaults to Google's broadest reach. It does not name alternative tools (e.g., when to prefer update_campaign) or state exclusions, so it stops short of a 5.

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

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

Annotations already declare readOnly=false, idempotent=true, destructive=false, openWorld=true. The description adds non-structured context the annotations don't cover: write-access requirement, a pointer to auth/scopes.ts, and the graceful-failure behavior when the property has changes disabled. Return/confirmation behavior is still unspecified, keeping it at 4.

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

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

Two sentences, front-loaded with the core action before the usage rationale and the auth caveat. Density is high and every clause carries information, though the em-dash parentheticals make it slightly harder to scan than a 5 would warrant.

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 2-parameter, no-output-schema tool with annotations already covering the safety profile, the description supplies the missing pieces: when to use it, the write-scope requirement, and failure behavior. The only real gap is parameter-level detail (the undocumented siteUrl) and any success response semantics.

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

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

Schema description coverage is only 50% — feedpath is documented but siteUrl is not. The description says nothing about either parameter, so it fails to compensate for the undocumented siteUrl and does not clarify how the two relate (e.g., whether siteUrl defaults). It adds no meaning beyond the schema.

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

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

States a specific verb and resource — 'Tell Google to (re)fetch a sitemap' — and the parenthetical '(re)fetch' clarifies that this both submits and resubmits. This distinguishes it implicitly from read-only siblings like get_sitemap and list_sitemaps, which the agent can separate 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 clear when-to-use context: it's 'the natural next step after editing pages based on performance data, so the change is picked up rather than waiting for the next crawl.' It also names a when-not condition (refuses when the connection/property has changes switched off). No explicit alternative tool is named, so it stops short of a 5.

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

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

Annotations already declare destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the safety profile is covered. The description usefully adds that REMOVED is permanent and that raising the bid raises cost-per-click, which is real behavioral context beyond the annotations, but it omits idempotency, permissions, and rate-limit context.

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

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

Three short, front-loaded sentences with the core action first. The middle sentence about bid cost is mildly self-evident but serves as a spend caution, so it earns its place; no true waste.

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

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

For a 6-parameter mutation with a rich parameter-level schema and annotations covering safety, the description covers the purpose and the key permanence/spend warnings. No output schema exists, so return values need not be explained. It is essentially complete, though validateOnly/extraFields usage is left entirely to the schema.

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 83%, so the schema already documents cpcBid, status, customerId, extraFields, and validateOnly in depth. The description only names 'status' and 'default max CPC' at a high level, adding little beyond what the schema provides; baseline 3 applies.

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

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

States a specific verb+resource: changing an ad group's status and/or default max CPC. An agent can distinguish it from siblings like update_campaign or update_keyword by the ad-group resource. It stops short of explicitly naming which sibling to use for related tasks, so it is not 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 description gives no when-to-use vs alternatives guidance, no prerequisites, and no sibling routing (e.g., vs update_ad_status or update_campaign_status). The 'REMOVED is permanent' note is a caution, not usage guidance. Nothing tells the agent the conditions under which to pick this tool.

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

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

Annotations already declare destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the safety profile is largely covered. The description adds one useful fact beyond them — 'REMOVED is permanent' — but says nothing about spend implications of pausing, whether re-enabling restores prior state, or the interaction with validateOnly.

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 tightly written sentences with the scope stated first and the key permanence warning second; nothing is padded. It is arguably too terse for the complexity, but every sentence earns its place and it is front-loaded.

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

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

For a destructive, open-world mutation taking 6 parameters, the description is thin: it omits the dry-run workflow, the customerId account-selection rule, and the extraFields escape hatch, all of which live only in the schema. Minimal but not fully adequate for the tool's complexity.

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

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

Schema coverage is only 50%: customerId, extraFields, and validateOnly are well documented in the schema, while adId, status, and adGroupId have none. The description adds no parameter meaning at all, so it fails to compensate for the undocumented half.

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 (change status) and resource (a single ad within its ad group), which cleanly separates it from update_ad_group and update_campaign_status siblings. The title further enumerates the three operations (enable, pause, remove). It stops short of explicitly naming a sibling, but the scope is unambiguous.

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

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

The description implies when to use it (changing one ad's status) and the title enumerates the enum values, but there is no explicit guidance on when to prefer this over update_ad_group or update_campaign_status, nor any prerequisite framing. Usage must be inferred from 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 cover the mutation profile (readOnlyHint=false, destructiveHint=true, idempotentHint=false), so the description is not obligated to restate safety. It nevertheless adds real behavioral context: the PAUSED-by-default safety state, the fact that extraFields can only add fields and can never override status or bypass validation, and the free dry-run path. It does not discuss live spend impact or reversibility, leaving a small gap against the destructiveHint.

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

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

Two sentences, front-loaded with the scope statement and the sibling exclusion before the workflow aside. The second sentence is long and slightly digressive (the MANUAL_CPC story), but it earns its place by motivating the tool. 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 tool with nested objects and no output schema, the description covers routing, the escape hatch semantics, the validateOnly dry-run, and the status exclusion. Nothing an agent needs to invoke it correctly is missing.

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

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

Schema description coverage is 100%, so the baseline is 3; the description exceeds it by giving the biddingStrategy parameter operational meaning (MAXIMIZE_CONVERSIONS requires working conversion tracking) and framing the MANUAL_CPC-to-automated transition as the reason to change it. It still does not add format or constraint detail for name/budgetId beyond the schema.

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

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

States a precise verb and resource ('Change a campaign's name, reassign it to a different budget, or switch its bidding strategy') and explicitly carves out the boundary: 'everything about a campaign except status (use update_campaign_status for that).' An agent can distinguish this from update_campaign_status and update_campaign_budget 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?

Names the excluded case and its alternative tool directly, and supplies a concrete usage pattern (start on MANUAL_CPC, then move to an automated strategy once data exists) that tells the agent when this tool is the right choice. Both when-to-use and when-not-to-use are present.

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, idempotentHint=false and openWorldHint=true, so the safety profile is covered. The description adds value beyond that by stating the real-world consequence (which campaigns can spend how much per day) and pointing at the dry-run path, though it says nothing about permissions or propagation timing.

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

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

Two short sentences, the effect front-loaded before the safety advice, with zero filler. Every clause earns its place.

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

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

For a destructive five-parameter mutation with full schema coverage, no output schema, and annotations covering the safety hints, the description supplies the impact and validation guidance an agent needs. It leaves open only secondary details such as permission requirements and whether extraFields carries hidden risk.

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

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

Schema description coverage is 100%, including detailed docs for amount, customerId, extraFields and validateOnly, so the schema already carries the parameter burden. The description only echoes the 'daily amount' and dry-run concepts, adding no syntax or format detail beyond the schema's baseline.

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: changing the daily amount on an existing campaign budget. This implicitly separates it from create_campaign_budget and from update_campaign, but it never names a sibling or the boundary explicitly, so it falls just short of 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?

"Dry-run it first if you are unsure" gives a concrete precondition tied to validateOnly, which is real guidance. However, there is no routing advice against alternatives such as update_campaign or create_campaign_budget, so usage is only partially covered.

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 and idempotentHint=false, but the description adds concrete consequences the annotations cannot convey: ENABLED begins spending, PAUSED stops delivery and is reversible, REMOVED is permanent and not undoable via API or the Ads UI. That spend and reversibility detail is genuinely additive.

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

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

Two sentences, zero filler, and the operation is front-loaded with the destructive case (REMOVED) clearly distinguished. Every clause earns its place.

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

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

For a destructive mutation with no output schema, the description covers the key risks (irreversibility, spend impact) and the schema covers parameters thoroughly. It slightly under-delivers on permission/auth requirements and what the response returns, but nothing critical to a correct call 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 100%, so the baseline is 3, but the description meaningfully expands the most important enum beyond the schema's terse "REMOVED is irreversible" by spelling out spend behavior for ENABLED and reversibility for PAUSED. The other params (campaignId, customerId, extraFields, validateOnly) are left entirely to the schema, which documents them well.

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?

"Change a campaign's status" is a specific verb+resource, and the title plus enum values make the three operations explicit. It is distinguishable from update_campaign (broader edits) and update_ad_status (different resource) by scope, though it never names those siblings directly.

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

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

The description explains what each status means but gives no explicit guidance on when to prefer this over update_campaign or update_ad_status, nor any prerequisites. Usage is implied by the enum semantics 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 annotations: discloses that includeInConversionsMetric is immutable on GA4-synced actions and will produce an IMMUTABLE_FIELD error, while primaryForGoal and status remain changeable. Also notes status has no PAUSED state and that extraFields can only add fields, never override this tool's own arguments or safety defaults. This is rich behavioral context annotations alone do not 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?

Dense but front-loaded, with the core purpose and the key primaryForGoal instruction leading. Some deeply nested parentheticals (the GAQL enum caveat, the extraFields example) stretch sentences, but each piece of information earns its place for a behaviorally tricky mutation 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 mutation tool with no output schema, the description covers the id-discovery path, the immutability trap, error expectations, and the validateOnly safety route. Everything an agent needs to invoke this correctly is present and no return-value explanation is required.

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

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

Schema coverage is 100%, so the baseline is 3; the description still adds value by explaining why primaryForGoal matters (it enables MAXIMIZE_CONVERSIONS bidding), why status lacks a PAUSED option, and how extraFields behaves (add-only escape hatch with a concrete example). It enriches meaning rather than merely restating 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?

States a precise verb+resource ('Update settings on a Google Ads conversion action that Google has already synced from a linked GA4 property's key event') and distinguishes it from sibling actions (create_google_ads_link, mark_key_event, run_gaql_report). An agent can identify exactly what this tool mutates and why it exists (setting primaryForGoal for MAXIMIZE_CONVERSIONS).

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 routes the agent: use run_gaql_report with a concrete query to find the conversion action id, and clarifies that creation/import is handled elsewhere ('there is no Ads API call to create or trigger that import'). It also recommends validateOnly as a free dry run 'whenever you are unsure'.

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 and readOnlyHint=false, so the safety profile is covered. The description reinforces that REMOVED is a permanent delete, adding useful context beyond the enum, but says little about irreversibility of bids or idempotency beyond what annotations and schema provide.

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

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

Two tight sentences, front-loaded with the core action and followed by the sibling routing. 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 destructive mutation tool, the safety semantics are carried by annotations, all seven parameters are documented at 100% coverage, and the description supplies the routing and permanence caveat. No output schema is needed and nothing an agent requires to call correctly is missing.

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

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

Schema description coverage is 100%, so every parameter (including validateOnly, extraFields, customerId) is already fully documented in the schema. The description only echoes the status/bid fields, adding no syntax or constraint detail beyond 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?

Specific verb+resource ('Change an existing keyword's status...and/or its max CPC bid') with the exact mutation fields named. It explicitly distinguishes itself from the sibling add_keywords by stating add_keywords only adds while this acts on existing keywords.

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

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

Routes the agent precisely: it names add_keywords as the alternative for creation and supplies a concrete when-to-use scenario ('pausing an underperformer found via get_search_terms'). Nothing about selecting this tool vs. siblings is left to inference.

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