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

Annotations already declare destructiveHint=true and openWorldHint=true, so the bar is lower, yet the description adds nothing about the notable behaviors: the `confirm` flag (default false) that almost certainly gates the actual write, GA4's per-property custom-dimension cardinality limits, and the auth/PHP scope needed. None of these are disclosed, leaving the agent to discover the confirmation flow only from the schema.

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

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

One front-loaded sentence with zero filler; the purpose and its payoff are packed into a single clause. 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?

For a destructive, open-world mutation with six undocumented parameters and a confirmation gate, one sentence is not sufficient. An output schema exists so return values needn't be covered, but the write semantics, confirmation requirement, and quota implications are all missing.

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

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

Schema description coverage is 0% with six parameters, so the description carries the full burden and delivers almost nothing. "event or user parameter" loosely gestures at `scope`/`parameter_name`, but `confirm`, `description`, and `property_id` — including how the required property ID is obtained — are completely 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+resource ("Register ... as a custom dimension") and the downstream effect ("used in reports"), which is far clearer than the name alone. It does not explicitly contrast with the nearest sibling, ga4_create_key_event, but the resource noun is distinctive enough that an agent can separate them.

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 "so it can be used in reports" implies why an agent would call it, but there is no explicit when/when-not guidance, no stated prerequisite (the parameter must already be collected in the property), and no reference to alternatives. Usage must be inferred.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=true and openWorldHint=true, so the description carries a lighter burden, yet it adds nothing beyond them: no mention of reversibility, idempotency, or what the 'confirm' flag actually gates. Nothing in the text contradicts the annotations, but a mutation tool with a destructive hint and an unexplained confirm gate deserves more behavioral disclosure.

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

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

A single front-loaded sentence with no filler and no repetition of the tool name. It is efficient; the shortfall is missing content rather than wasted content.

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

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

An output schema exists so return values need no explanation, but for a destructive write with three undocumented parameters and a non-trivial 'confirm' flag, the description omits what an agent needs to invoke it safely.

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

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

Schema description coverage is 0% across three parameters, so the description must compensate. It gives useful example event names ('generate_lead', 'purchase'), but never explains property_id format or, more critically, what the boolean 'confirm' parameter does, even though it defaults to false and likely gates the mutation.

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 ('Mark ... as a key event') and resource, and immediately clarifies the domain concept with '(conversion) in GA4'. No sibling tool in the list operates on key events, so an agent can route to it unambiguously.

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, when-not-to-use, or prerequisite context (e.g. required permissions, whether the event must already exist). Usage is only implied by the one-line 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 declare this is a read-only, non-destructive, open-world operation, so the safety profile is covered. The description adds the useful scope that only dimension and metric API names are returned, but it does not disclose pagination behavior, result volume, or whether search matches API names versus display names. With annotations carrying safety, the added behavioral context is modest.

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 sentence that front-loads the operation, resource, and optional filter. There is no redundant or boilerplate 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?

The output schema exists, so return values need not be explained. For a simple two-parameter read-only metadata tool, the description covers the core purpose but omits parameter format details and search semantics, which matter because schema coverage is zero. It is adequate but not complete.

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

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

Schema description coverage is 0%, so the description must supply parameter meaning. It does identify both parameters indirectly: a property and an optional search term. However, it does not explain the expected property_id format or what fields the search term matches against, leaving meaningful gaps for an agent relying solely on this text.

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

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

The description uses a specific verb and resource: 'List the dimension and metric API names available for a property.' This clearly distinguishes metadata discovery from sibling tools like ga4_run_report or ga4_realtime_report, which retrieve data rather than schema metadata. It stops short of explicitly naming those siblings, so a 4 rather than 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 mention of an optional search filter implies how to narrow results, and the word 'metadata' implies pre-report discovery, but the description never states when to use this tool versus ga4_run_report or why an agent would need API names. No exclusions or prerequisites 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 the meaningful detail that results are scoped to the authenticated user's permissions, but says nothing about result size, pagination, or latency for what may be a large enumeration.

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 sentence with no filler, and the resource and scope are front-loaded. Nothing is redundant with the tool name.

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

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

With no parameters, full annotation coverage, and an output schema documenting the return shape, the description is essentially sufficient. The only residual gap is that it does not hint at the account-to-property hierarchy an agent will encounter in the response.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. The description correctly implies no filtering options exist, consistent with the empty 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 ('List') and resource ('every GA4 account and property'), with the scope qualifier 'the authenticated user can access'. The GA4 prefix in the name already distinguishes it from google_ads_list_accounts and meta_list_ad_accounts, but the description itself never acknowledges 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?

Usage is only implied: it is a discovery/enumeration call, so an agent can infer it should be called before report or configuration tools. There is no explicit statement of when to prefer it over the platform-specific list siblings, nor any prerequisite or ordering 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, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful behavior context — the 30-minute realtime window and that results default to activeUsers by country — but says nothing about rate limits, property permissions, or how defaults are overridden. Adequate but not rich.

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

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

Two short sentences with the scope front-loaded and no filler; nothing is wasted. The terseness is efficient, though it leaves the definition thin rather than tight.

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

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

An output schema exists, so return values need not be explained, and annotations cover safety. What is missing for a 3-parameter analytics query tool is guidance on valid metric/dimension values, the meaning of property_id, and how this differs from ga4_run_report.

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

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

Schema description coverage is 0% for all three parameters, so the description must carry the meaning and largely does not. It partially documents the defaults for metrics and dimensions ('activeUsers by country') but never explains property_id, nor what metric/dimension names are valid GA4 values.

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

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

States a specific resource and scope ('Users active in the last 30 minutes'), which is clearly a GA4 realtime report and implicitly distinguishes it from the historical ga4_run_report sibling. It never uses a verb like 'report'/'query' and never names the sibling it differs from, so differentiation relies on inference from the 30-minute window.

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 and no mention of the obvious alternative, ga4_run_report, which is the main routing decision an agent faces here. The realtime scope only weakly implies the use case; nothing states when NOT to use it or what prerequisites (e.g. property access) apply.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. Beyond that the description adds nothing behavioral: no mention of GA4 Data API quota/rate limits, sampling, row-limit semantics, or the fact that property_id must be a valid GA4 property. For an open-world external API call, that is a meaningful 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?

Front-loaded one-line purpose followed by dense, example-driven bullets with zero filler. The only weak spot is the bare opening sentence, which is near-tautological and could have carried the sibling differentiation instead.

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

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

An output schema exists, so return values needn't be described, and the query-shaping parameters are well covered. However, for an 8-parameter external-API tool with no schema descriptions, the missing property_id sourcing, limit behavior, and absence of any routing guidance leave it only adequate.

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

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

Schema description coverage is 0%, so the description carries the full burden and mostly does: it gives date literal formats (YYYY-MM-DD, today, yesterday, NdaysAgo), the filter object shape with match operators, AND semantics for multiple filters, and sort direction for order_by_metric. property_id and limit remain unexplained, which keeps it from a 5.

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 report") and immediately grounds it with example metrics and dimensions, so an agent knows this is the general analytics query tool. It does not explicitly distinguish itself from siblings like ga4_realtime_report, but the standard-report framing is clear enough to infer the split.

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 shows how to shape arguments but never says when to use this versus ga4_realtime_report, ga4_get_metadata, or google_ads_query. There are no prerequisites, no exclusions, and no note about property_id being required (e.g., obtained from ga4_list_properties).

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

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

Annotations declare destructiveHint=true and openWorldHint=true, and the schema contains a 'confirm' boolean defaulting to false, implying a two-step confirmation gate — but the description never mentions confirmation, reversibility, or that keywords persist until removed. For a destructive mutation, the description adds essentially nothing 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?

A single front-loaded sentence with no filler; nothing is wasted. Its brevity is appropriate in form, though it leaves the substantive gaps flagged in other dimensions.

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

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

This is a destructive, open-world mutation with 6 parameters, an undocumented confirm gate, and 0% schema description coverage. An output schema exists so return values need not be explained, but the description is not complete enough for an agent to invoke this safely and correctly.

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

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

Schema description coverage is 0% across 6 parameters. The description only gestures at 'keywords' and the campaign-level scope; it says nothing about match_type semantics (enum, default PHRASE), the confirm flag, or login_customer_id for MCC access, so it fails to compensate 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?

Names a specific verb+resource ('Add campaign-level negative keywords'), and the 'campaign-level' qualifier distinguishes it from ad-group-level negative keyword work. It does not name any sibling tool, but the scope is precise enough for an agent to tell what it does.

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

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

The parenthetical 'e.g. wasteful search terms found in a search-term report' implies the workflow that triggers this tool, which is useful context. However, there is no guidance on when not to use it, when to prefer ad-group-level negatives, or how to choose between this and a query/mutation sibling.

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

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

The annotations already declare this as a read-only, non-destructive, open-world operation. The description adds useful context about exactly which metrics are returned and the GAQL date-range semantics. It does not explain the effect of `include_paused` or how `customer_id` versus `login_customer_id` is used, leaving some behavioral gaps for a reporting tool.

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

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

The description is two concise sentences: the first front-loads what the tool returns, and the second provides concrete date-range examples. It is efficient and appropriately sized, though it could briefly mention the other parameters.

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

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

An output schema exists, so return values need not be explained, and annotations cover safety. However, three of four parameters lack any explanation, and the description does not cover how account selection or paused campaigns affect results. It is minimally complete but has clear gaps for an agent to call 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?

Schema description coverage is 0%, so the description must carry the burden for all four parameters. It only explains `date_range` (with helpful GAQL values), while `customer_id` (required), `include_paused`, and `login_customer_id` are left completely undocumented. This is a significant gap given four parameters and no schema descriptions.

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

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

The description clearly states it returns campaign-level performance metrics (spend, clicks, impressions, conversions, CPA, ROAS) over a date range. The resource and scope are specific. It does not explicitly differentiate itself from the generic `google_ads_query` sibling, but the metric-focused framing makes its purpose distinguishable.

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 date_range examples (TODAY, LAST_7_DAYS, etc.) provide implied usage guidance for that parameter. However, there is no explicit guidance on when to use this tool versus `google_ads_query` or other reporting siblings, nor any note on prerequisites such as account access.

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

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

With annotations already indicating a safe read-only operation (readOnlyHint: true, destructiveHint: false), the description adds some value by specifying the returned fields. However, it does not disclose other behavioral traits such as pagination, rate limits, or authentication requirements beyond what the 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?

The description is a single, efficient sentence that front-loads the key information about what is listed and what data is returned. Every part earns its place with no redundancy.

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

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

An output schema exists, so the description need not explain return values. However, the lack of any explanation for the single parameter 'login_customer_id' leaves a notable gap in completeness, especially given the 0% schema description 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 single parameter 'login_customer_id' has no description in the schema (0% coverage), and the tool description does not mention it at all. This leaves the parameter's purpose and usage completely undocumented, which is a significant gap for an agent to correctly invoke the 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?

The description states a specific verb 'List' and resource 'Google Ads account', and clarifies the scope as 'every Google Ads account the authenticated user can access'. It also details the returned fields (name, currency, manager status). However, it does not explicitly differentiate from the sibling tool google_ads_list_client_accounts, which may cause confusion.

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

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or any conditions that would help an agent decide between this and related tools like google_ads_list_client_accounts.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so safety is covered. The description adds only the parent/child relationship between the MCC and its client accounts, and says nothing about result volume, pagination, or what fields come back beyond what the output schema already provides.

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

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

A single front-loaded sentence with no filler, and the scoping detail ('under a manager (MCC) account') leads the sentence. It is efficient, though its brevity leaves the gaps noted elsewhere.

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

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

An output schema exists, so return values need not be described. But for a listing tool, the description omits ID format, whether results are paginated or filtered, and how it relates to the sibling google_ads_list_accounts — too thin given 0% parameter coverage and multiple look-alike siblings.

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

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

Schema description coverage is 0% and there is one required parameter, manager_customer_id, whose expected format (bare digits vs. dashed formatting, 10-digit MCC ID) is not explained anywhere. The description does not compensate for this gap at all.

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

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

The description uses a specific verb and resource ('List the client accounts') and scopes it to accounts under a manager (MCC) account, which is more precise than the tool name alone. However, it does not distinguish itself from the sibling google_ads_list_accounts, leaving ambiguity about which listing tool applies.

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

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

No guidance is given on when to use this versus google_ads_list_accounts or google_ads_query, nor any stated prerequisites (e.g., that the caller must hold MCC credentials for the manager_customer_id). The agent must infer the selection criteria from the name alone.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the description's 'read-only' framing is largely redundant. It does add real value with the note that costs are in micros and must be divided by 1,000,000 – a behavioral fact not in the annotations. It says nothing about pagination or how the 'limit' interacts with results, so it stops short of a 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?

The purpose is stated in the first sentence, followed by one example and one unit caveat – no filler. The example spans several lines but earns its place by demonstrating the required query dialect.

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

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

An output schema exists, so return values need not be described, and annotations cover the safety profile. However, for a tool with 0% schema description coverage and two required identifiers including the MCC login header, the description leaves an agent without enough to fill arguments correctly.

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

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

Schema description coverage is 0% across four parameters, so the description must carry the burden and it does not. The example illustrates the shape of 'gaql' only; 'customer_id', 'login_customer_id' (a notoriously error-prone MCC-manager field) and 'limit' are entirely unexplained in both schema and description.

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

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

The description states a specific verb and resource (run a read-only GAQL query) and scopes it as unrestricted ('any'), which is genuinely distinct from the operation-specific siblings like google_ads_campaign_performance or google_ads_set_campaign_budget. It does not, however, explicitly say when this generic tool is preferred over those specialized tools, leaving the boundary to inference.

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 example query implies how the tool is used (select fields, from a resource, with a date segment filter), which is useful implied guidance. But there is no statement of when to reach for this versus the several google_ads_* siblings, no exclusions, and no prerequisites such as needing a customer account context.

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

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

Annotations already disclose destructiveHint=true, readOnlyHint=false, and openWorldHint=true, so the safety profile is covered. The description adds useful domain context that the bid is in account currency and only works for manual CPC bidding, but it does not clarify the confirm parameter or other mutation behavior.

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

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

The description is two short clauses with no wasted words, and the core action is front-loaded before the applicability constraint.

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

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

This is a destructive mutation with five parameters and zero schema description coverage. Although an output schema exists and annotations cover safety, the description leaves key operational details such as the role of confirm and login_customer_id 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 0%, so the description must carry parameter meaning. It only clarifies cpc_bid as a max CPC bid in account currency; it does not explain customer_id, ad_group_id, login_customer_id, or confirm.

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

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

The description states a specific verb and resource: setting an ad group's max CPC bid. It is clear what the tool does, but it does not explicitly distinguish this tool from sibling mutation tools such as google_ads_set_campaign_budget.

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 'Only applies to manual CPC bidding' gives an important validity condition, but the description does not say when to choose this tool over alternatives or what to do for non-manual bidding.

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 openWorldHint=true, so the mutation risk profile is covered. The description adds genuine context by defining the budget unit and currency (50 = $50/day), which annotations cannot express. It stops short of saying the previous budget is overwritten, whether the change is immediate/irreversible, or what confirm does.

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 the core meaning and the unit example in parentheses; nothing is wasted. It is arguably under-specified rather than verbose, but structurally it is clean.

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 with five undocumented parameters and a confirm gate, this is thin. There is an output schema, so return values need not be described, but confirmation behavior, currency-mismatch risk and per-account scoping (login_customer_id) are all absent.

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

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

Schema description coverage is 0%, so the description carries the full burden, yet it only clarifies daily_budget's unit and example. customer_id, campaign_id, login_customer_id and especially confirm – the only non-required, non-obvious parameter – are left entirely unexplained.

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

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

States a specific verb and resource ("Change a campaign's daily budget") and adds the unit convention, so an agent immediately knows what the tool does. It does not, however, name or distinguish itself from the nearby siblings (meta_set_budget, google_ads_set_ad_group_cpc_bid), so scope differentiation is left to the tool name alone.

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

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

There is no when-to-use / when-not-to-use guidance and no mention of prerequisites or the sibling alternatives that also set budgets or bids. Critically, the confirm parameter is never mentioned, so the agent gets no guidance on that gate.

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, so the safety profile is known. The description adds a useful behavioral detail about entity_id composition for nested entities, but omits that a 'confirm' parameter exists and likely gates the mutation — a significant behavioral fact for a destructive operation.

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

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

Two compact sentences, purpose first, entity format second — no wasted words. The second line could be formatted more cleanly, but 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?

For a destructive, open-world mutation with 6 params at 0% schema coverage and an undocumented confirm gate, the description is thin. An output schema exists so return values need no explanation, but input behavior is largely unexplained.

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 only 6 params, so the description must carry the load. It explains entity_id format well (including the composite '~' syntax), but says nothing about customer_id, login_customer_id, level, status values, or the confirm flag.

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 pair (pause/enable) and enumerates the exact resource types it acts on (campaign, ad group, ad, keyword). It doesn't explicitly differentiate from siblings like meta_set_status, but the Google Ads scope is clear from the tool name.

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

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

No guidance on when to use this versus alternatives, no mention of prerequisites, and crucially no explanation of when the 'confirm' flag must be set. The agent is left to infer everything about invocation context.

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

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

Annotations already declare destructiveHint=true and openWorldHint=true, so the safety profile is covered. The description adds genuinely useful behavior beyond that: the campaign is always created PAUSED so no spend occurs until activation. It does not explain the `confirm` gate despite this being a flagged mutation, which is the main 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?

Three tight sentences, front-loaded with the action and the safety-relevant paused default. No filler. Formatting is slightly scattered (parameter notes appear as loose lines), but every sentence carries information an agent needs.

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

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

An output schema exists, so return values need not be described. The description covers creation semantics, the paused default, and two parameters — adequate for a six-parameter create. But for a tool flagged destructive, the unexplained `confirm` boolean and missing required-parameter notes leave the agent under-informed.

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

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

Schema description coverage is 0%, so the description must carry the parameter burden. It clarifies two of six well — daily_budget is in major units and toggles campaign budget optimization, and special_ad_categories accepts [] or values like HOUSING/EMPLOYMENT/FINANCIAL_PRODUCTS_SERVICES. It says nothing about `confirm`, `ad_account_id`, or `name`, leaving a meaningful hole for a destructive operation.

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 new campaign." Clear enough that an agent knows exactly what it produces. However, it does not distinguish itself from adjacent siblings such as meta_update_entity or meta_set_status, which an agent could plausibly confuse with campaign creation/configuration.

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 concrete decision guidance for the budget parameters: set daily_budget for campaign budget optimization, or omit it to budget at the ad set level. It also implies the follow-up workflow (activate later) by noting the campaign starts PAUSED. No explicit when-not to use or named alternative tools, which keeps it below 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 a non-destructive read operation, so the description's main added value is the interaction note that date_preset is ignored when since/until are supplied. It does not mention pagination behavior, limit semantics, or what the output contains beyond the existence of an 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?

Front-loaded with the core purpose and then compact parameter hints; no filler sentences. It is appropriately brief for a tool definition, though the terse parameter lines could be slightly more structured.

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

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

This is a 9-parameter read tool with zero schema descriptions, and the description only explains a subset of parameters. An agent can infer some usage from examples, but key parameters such as level, limit, and fields remain undocumented anywhere in the definition.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It partially documents date_preset values, breakdown examples, and time_increment, but leaves level's enum meaning, limit, fields, since/until formats, and object_id format largely 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+resource: 'Performance insights' for an ad account/campaign/ad set/ad. An agent can tell this is Meta insights rather than a listing or mutation tool, though no sibling is explicitly named or contrasted.

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 through parameter guidance (date_preset values, breakdown examples, time_increment for daily rows), but there is no explicit when-to-use vs alternatives such as meta_list_entities or google_ads_campaign_performance, and no stated exclusions.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds one genuinely useful behavioral fact — results include Business Manager-owned accounts, not just directly owned ones — but says nothing about pagination, truncation at the default limit of 200, or rate limits.

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

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

One sentence, front-loaded with the verb and resource, with the scope qualifier in parentheses. Nothing is wasted and nothing is buried.

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

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

An output schema exists, so return-value shape need not be described, and with a single optional parameter the tool is simple. Still, for a paginated, permission-dependent listing tool the description omits result-cap behavior and any routing to sibling listing tools, leaving real gaps.

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

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

The single parameter 'limit' has 0% schema description coverage, so the description is the only place it could be explained — and it is not. Worse, 'List every Meta ad account' implies a complete enumeration while the default limit of 200 silently caps results, so the description actively creates a misleading expectation about result completeness.

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

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

Names a specific verb and resource (list Meta ad accounts) and adds scope that matters: 'every ... the token can access (including via Business Managers)'. This distinguishes it in substance from meta_list_entities and google_ads_list_accounts, though it never names those siblings explicitly.

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

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

Usage is only implied — an agent can infer this is a discovery/enumeration step, but the description gives no explicit when-to-use, when-not, or pointer to meta_list_entities for other object types. No prerequisites (token scope, Business Manager permissions) are stated.

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

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

Annotations already state readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description usefully adds that budgets are returned in minor units and shows the effective_status array format, but it does not mention pagination, ordering, permissions, or rate limits.

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

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

The description is short and front-loads the core operation, then adds filter syntax and budget units. There is no filler, though the separate filter sentence is slightly less integrated than it could be.

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

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

Given the annotations, input schema, and output schema, the description provides enough context for a read-only listing call: what entities are listed, what status and budget data are returned, and how to filter status. It is not fully complete on pagination or limit behavior, but the remaining gaps are minor.

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

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

Schema description coverage is 0%, so the description must compensate. It explains the entity_type values through 'campaigns, ad sets or ads' and gives effective_status examples, but leaves ad_account_id and limit undocumented.

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

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

The description states a specific verb and resource: list campaigns, ad sets, or ads in an ad account, including status and budgets. It is clear enough to distinguish this from a generic account listing, though it does not explicitly name sibling tools such as meta_get_insights or meta_list_ad_accounts.

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

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

Usage is implied by the listing language and the effective_status filter example, but the description gives no explicit when-to-use or when-not-to-use guidance versus alternatives like meta_get_insights or meta_list_ad_accounts. There are no exclusions or prerequisite notes.

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 flag destructiveHint=true and openWorldHint=true, so the safety bar is partly met, but the description says nothing about irreversibility, the meaning of the `confirm` flag, or what happens if confirm is false. The only added context is the currency-units convention (50 = $50), which is useful but leaves the destructive-confirmation flow undisclosed.

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, and the unit convention is stated inline where it is most needed.

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

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

Output schema exists so return values need not be described, but for a destructive mutation with an explicit `confirm` gate and zero schema coverage, the definition is too thin to call safely. It should explain the confirm requirement and what object_id accepts.

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

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

Schema description coverage is 0% across 4 parameters, so the description must carry the burden. It only clarifies `amount` units; `object_id`, `confirm`, and `budget_type` (despite having an enum) are entirely undocumented in both schema and description.

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

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

States a specific verb and resource: 'Change the budget of a campaign (CBO) or ad set', and clarifies the CBO scope. It does not distinguish itself from the sibling google_ads_set_campaign_budget, but the Meta-vs-Google context makes the target surface reasonably inferable.

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

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

No guidance on when to use this versus meta_update_entity or the Google Ads budget siblings, and no mention of prerequisites or the conditions under which a budget can be changed. The agent must infer everything about selection and preconditions.

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 adds nothing beyond them: it doesn't explain that pausing halts delivery/spend, whether the change is reversible, or what the undocumented 'confirm' flag does — a critical omission for a destructive mutation.

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

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

One short sentence with the action and resource front-loaded and no wasted words. Its brevity is efficient rather than padded, though it comes at the cost of missing details rather than being over-long.

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

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

An output schema exists, so return values needn't be described. However, for a destructive, open-world mutation tool with an unexplained 'confirm' parameter and 0% schema coverage, the description omits the confirmation semantics, reversibility, and permission requirements an agent needs before invoking it.

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

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

Schema description coverage is 0%, so the description must carry the parameter burden, but it only implicitly maps object_id ('by id') and status. The 'confirm' boolean — which likely gates execution — is never mentioned, leaving a required safety parameter fully opaque.

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 pair (pause/activate) and a concrete resource (Meta campaign, ad set, or ad) addressed by id. It is distinguishable from siblings such as google_ads_set_status by platform and by resource scope, though it doesn't clarify how it relates to the more general meta_update_entity.

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 meta_update_entity or meta_set_budget, and no prerequisites or exclusions are stated. The agent must infer the usage context entirely from the tool name and the single sentence.

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 openWorldHint=true, so the safety profile is covered. The description usefully adds that budget/bid/spend_cap must be in minor units — non-obvious context not in any annotation. However, it never explains the `confirm` gate, the mutability of budgets, or that unspecified fields are left untouched, which is a real gap for a flagged-destructive write.

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 operation and field list, followed by the format constraint and the sibling pointer. No filler; the only waste is that the minor-units caveat could be folded into the field enumeration.

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

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

Output schema exists so return values need no explanation, and the annotations cover the risk profile. Still, a destructive write with a required `object_id`, a free-form `fields` bag, and an unexplained `confirm` flag needs more than three sentences before an agent can 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?

Schema coverage is 0%, so the description must carry the load, and it does document the allowed keys of `fields` plus the minor-units convention for the numeric ones — meaningful compensation. But `object_id` and especially `confirm` (a boolean gating a destructive write) get no explanation at all, leaving a third of the parameters opaque.

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 (update allowed fields on a campaign, ad set or ad) and even enumerates the mutable fields, so the agent knows exactly what class of operation this is. The enum-of-fields is loose because the actual `fields` parameter is a free-form object, but the intent is unmistakable.

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

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

"Prefer meta_set_budget for budgets" is a genuine routing hint with an explicit alternative, which is more than most. But `status` is one of the listed allowed fields and the sibling `meta_set_status` exists — the description gives no guidance on which one to use, and it never says when this tool should not be used.

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