MetricPort

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered structurally. The description adds genuinely new behavioral context: this is a multi-check aggregation performed in a single call, and it returns a prioritized findings list rather than raw metrics. It still omits any note about latency/cost of fanning out across many checks or auth requirements.

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

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

Two tight sentences, front-loaded with the operation and then the output. The enumeration of checks is dense but each item earns its place by telling the agent what will be computed, and there is no filler or restatement of the 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 output schema, the description correctly takes on the job of stating the return shape ('prioritized findings list'). For a read-only two-parameter audit tool this is nearly complete; the only real gap is the undefined 'days' lookback window, which the agent must discover from the schema alone.

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%: 'property' is documented in the schema, but 'days' (min 7, max 90, default 30) has no description. The description never mentions either parameter or the lookback window, so it fails to compensate for the coverage gap on a parameter that materially changes every computed comparison.

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 composite operation and enumerates the exact checks it runs (campaign totals vs. prior period, wasted spend share, impression share lost to budget/rank, low quality score cost, budget pacing, open recommendations), so an agent can tell it is an aggregate audit rather than a single-metric tool. It does not explicitly state that it supersedes the individual sibling tools (ads_wasted_spend, ads_budget_pacing, ads_quality_score_audit, ads_recommendations), leaving that distinction 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?

"One call that runs the key checks" implies this is the consolidated overview option versus running the individual sibling tools separately, which is useful implied guidance. However, there is no explicit when-to-use statement, no exclusions (e.g. not for deep dives on one metric), and no mention of prerequisites such as obtaining the customer id from 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 readOnlyHint, idempotentHint, non-destructive, openWorld. The description adds the default date range and interpretation guidance, but does not disclose pagination, rate limits, cost-unit conventions, or what happens across time zones. Given annotations cover safety, a 3 is fair.

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 fragments with no filler. Slightly telegraphic, but every sentence 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 5 parameters at 20% schema coverage and no output schema, the description should explain the undocumented parameters and return shape. It supplies only a metrics list and a default window, which is insufficient for correct invocation.

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

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

Schema description coverage is only 20% – only the required 'property' parameter is documented. The description mentions no parameters beyond implying a date range ('last 30 days'), leaving limit, campaign, startDate, endDate, and their formats/behaviors 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?

Names the resource (responsive search ads) and the metrics it returns (ad strength, final URL, headlines count, CTR, cost, conversions). It is distinguishable from siblings like ads_keyword_performance or ads_campaign_performance, though it doesn't explicitly contrast with 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?

Provides a default time window (last 30 days) and an interpretive hint ('low ad strength and low CTR ads are rewrite candidates'), implying diagnostic use. However, it does not state when to use this tool versus ads_recommendations or other performance 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, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered structurally. The description does add behavioral substance by disclosing that it compares MTD actuals against an expected baseline and produces a month-end projection, but it says nothing about output shape, scope (all campaigns or filtered), or cost of the call.

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 core computation front-loaded ahead of the outcome it surfaces. Nothing is redundant with the title or schema.

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

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

With no output schema, the description carries the return-value burden, and it does tell the agent the result highlights campaigns at risk of overspending or underspending. That is sufficient for a read-only analytical tool, though it does not specify whether results cover all campaigns or only flagged ones, nor any ordering or pagination.

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%: 'property' is documented as a Google Ads customer id from list_properties, and 'monthlyBudget' documents its default as the sum of daily budgets × days in month. The description's phrase 'expected spend from its daily budget' lightly reinforces the monthlyBudget semantics but adds no format or constraint detail beyond the schema, so the 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?

The description names a specific analytical verb-and-resource: month-to-date spend per campaign versus expected spend from daily budgets, plus a month-end projection. It clearly distinguishes itself as a pacing/forecast tool rather than a raw performance report, though it never names the sibling it displaces (e.g. ads_campaign_performance or ads_wasted_spend).

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 closing line ('Finds campaigns that will overspend or leave budget unused') implies the use case of budget oversight, so an agent can infer when it is relevant. However, there is no explicit when-to-use or when-not-to-use guidance, and no mention of which sibling to prefer for related budget or performance questions.

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 the safe-read profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint), so the bar is low. The description adds the default 30-day window, which is genuinely useful behavioral context, but says nothing about result volume, pagination, or how status filtering affects output.

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 that puts the metric list and the default date window in one pass. It is efficient, though it sacrifices some explanatory depth for brevity.

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 does correctly enumerate the returned metrics, which covers the return-value burden. But aggregation grain (per campaign row?), how the status filter interacts with results, and date-range boundaries remain unstated, leaving gaps for a 4-parameter analytics 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 25%: only the property parameter is documented (customer id from list_properties). The description partially compensates for the date parameters by stating the default range, but the status enum (ENABLED/PAUSED/ALL) is described only as a returned field, not as a filter, so callers get no help on that parameter.

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

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

It names the entity (campaigns) and enumerates the exact metrics returned (cost, clicks, impressions, CTR, conversions, cost per conversion, ROAS, status), which is a clear resource definition rather than a tautology. However, it never differentiates itself from ad-, keyword-, or device-level siblings, so the agent must infer that this is the campaign grain.

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

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

There is no statement of when to reach for this tool versus ads_ad_performance or ads_keyword_performance, and no exclusions or prerequisites. The only guidance is the implied default date range, which is not framed as usage advice.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the returned data shape, which is genuinely useful, but the "max 30" cap merely repeats the schema's maximum=30 and it says nothing about pagination or the limit 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 clauses, front-loaded with the core capability before the diagnostic value. Only the redundant "(max 30)" is wasted given the schema already encodes that bound.

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 tool with no output schema, the description adequately conveys the returned dimensions and the time-window cap. Missing pagination/limit behavior is the main residual gap, which is minor given the safety annotations.

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 33% -- only 'property' is described -- so the description must compensate. It partially explains 'days' ("last N days") but says nothing about 'limit' (default 200, max 1000), leaving one parameter 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+resource: it surfaces who changed what in the account, and enumerates the returned fields (resource type, operation, user, timestamp). This is clearly distinct from every sibling, none of which cover change history, though it doesn't explicitly name the alternatives.

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

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

"Explains sudden performance shifts" implies a usage context for diagnosing anomalies, which is helpful. However, it gives no explicit when-to-use/when-not guidance or named alternatives, leaving the agent to infer when to reach for this versus ads_account_audit or ads_query.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so safety and repeatability are covered structurally. The description adds the diagnostic intent ('broken or double-counting tracking') but says nothing about volume, pagination, or how many conversion actions come back.

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 with the resource definition front-loaded and the diagnostic payoff second. Every clause carries information; the trailing benefit sentence is the only slightly loose element.

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

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

For a 3-param read-only tool with no output schema, the description adequately says what fields the response contains. It omits the required-property expectation and any date-window behavior, leaving an agent to infer call correctness from the schema alone.

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 'property' is documented, and startDate/endDate have no description at all. The phrase 'in the period' hints that a date window exists but gives no format, default, or guidance on whether the range is required, so the description does not 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?

The description names a specific resource (configured conversion actions) and enumerates the fields surfaced (status, category, counting type, attribution model, period conversions), which is more than a tautology. It does not, however, distinguish itself from diagnostic siblings like ads_account_audit or ads_quality_score_audit, despite overlapping framing ('catches broken tracking').

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

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

'Catches broken or double-counting tracking' implies a debugging/tracking-validation use case, which is real guidance. But it never states when to prefer this over ads_account_audit or ads_query, nor any prerequisites or exclusions.

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

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), so the description is free to add behavior — and it does, defining 'flagged' as ≥30% deviation vs. the prior 7 days and enumerating the returned metrics despite there being no output schema. It still omits granularity (one row per day?), aggregation level (account vs. campaign rows), and whether anomalies are always computed against a 7-day baseline regardless of the days parameter.

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

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

A single front-loaded sentence with no filler; the metric list and the anomaly rule both carry information. Slightly dense at the tail, 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 read-only 4-param tool with no output schema, the description usefully discloses the returned metrics and the anomaly convention, but leaves the time window, campaign filtering behavior, and result shape (rows, ordering, pagination) unstated. Adequate but with clear gaps.

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

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

Schema description coverage is only 25% — only 'property' is documented (as a Google Ads customer id from list_properties). The description does not explain 'days' (default 60, the window length), 'campaign' (does it restrict output to one campaign?), or 'thresholdPct' beyond the hardcoded '≥30%' figure, 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?

States a specific verb+resource: daily trend of cost, clicks, conversions and CPA for the account, plus the anomaly-flagging behavior that makes it distinctive. An agent can read the scope immediately, though it never names or contrasts a sibling (e.g. ads_campaign_performance, adsense_daily_trend) so differentiation is left 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?

There is no when-to-use guidance: nothing says when to pick this over ads_campaign_performance, ads_budget_pacing, or adsense_daily_trend, nor when an anomaly-focused view is the right lens. Usage is only implied by the phrase 'Daily ... trend'.

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

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

Annotations already declare readOnly/idempotent/openWorld, so safety is covered. Beyond that the description adds little: no note on date-range defaults, possible row volume (hours×weekdays), or auth requirements for the Google Ads customer id. It only states the metric set already implied by 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 compact sentences, front-loaded with the metric and grouping dimensions. Efficient, though the second sentence is somewhat thin rather than explanatory.

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

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

A read-only report tool with three undocumented parameters, no output schema, and no mention of return shape or date-range behavior. An agent knows what it reports but not how to scope the call correctly.

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

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

Schema coverage is 25% — only 'property' is documented. The description says nothing about campaign filtering, startDate/endDate semantics (format, default range, max window), or how campaign and dates interact, leaving three of four 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 specific metrics (cost, clicks, conversions, CPA) and the two dimensions (hour of day, day of week). Distinguishes itself from siblings like ads_device_performance or ads_geo_performance by dimension, though it doesn't name 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?

'Basis for ad schedules and bid adjustments' implies when the output is useful, but there's no explicit guidance on when to choose this over ads_campaign_performance or ads_daily_trend, no prerequisites, and no exclusions.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safe read-only profile is covered. The description adds the returned metrics and device granularity, but does not disclose date-range defaults, whether missing dates span all time, or any auth/rate-limit behavior—minor gaps given the annotation coverage.

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 returned metrics and granularity, followed by the intended use. No filler and every clause contributes to selection or invocation.

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

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

The description adequately conveys what the tool returns and its scope, and annotations cover the safety profile. However, with no output schema and low parameter coverage, more detail is needed on date handling and the campaign/property relationship 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 only 25% (only the required 'property' parameter is documented in the schema). The description does not compensate: it never explains the optional startDate/endDate format, defaults, or the campaign parameter other than implying one campaign may be selected. This leaves three of four parameters semantically underspecified.

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 set of metrics (Cost, clicks, CTR, conversions, CPA) and the exact dimension (per device: mobile, desktop, tablet) and scope (account or one campaign). This clearly distinguishes it from generic siblings like ads_campaign_performance or ads_geo_performance without needing to open the schema.

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

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

The phrase 'Basis for device bid adjustments' implies the intended use case, but there is no explicit when-to-use guidance, no alternatives named, and no exclusions. The agent must infer that this tool is chosen over other performance breakdowns when device-level optimization is needed.

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 a read-only, idempotent, non-destructive, open-world operation, so the safety profile is covered. The description adds the analytical intent (surfacing units to remove/resize/move) but says nothing about required date-range behavior, defaults, pagination, or result grouping that a performance report would need.

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, front-loaded fragments with zero filler — the metric list comes first and the action-oriented purpose second. It is efficient, though arguably undersized for a four-parameter reporting 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?

With four parameters, only 25% schema coverage, and no output schema, the description should carry more weight. It omits time-range semantics, result ordering/aggregation, and the limit cap, leaving real gaps for an agent trying to call it correctly.

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

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

Schema description coverage is only 25% — only 'property' is documented, while startDate, endDate, and limit are bare. The description does not compensate at all, never mentioning the date range, the limit/pagination cap, or how the property id is obtained.

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 the resource (ad units) and enumerates the exact metrics returned (earnings, impressions, RPM, CTR, viewability), so an agent knows what data this yields. However, it never distinguishes itself from close siblings such as adsense_ad_units, adsense_report, or adsense_top_pages, which an agent would need to choose between.

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?

"Identifies units to remove, resize or move" implies an optimization/diagnostic use case, which is genuine guidance. But there is no explicit when-to-use condition, no prerequisite (e.g., requires an AdSense account id and a date range), and no named alternative to prefer instead for simple ad unit listing.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is covered elsewhere. The description adds only the 'per ad client' grouping scope and says nothing about return shape, pagination, or result size for what is presumably an open-world listing call.

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, front-loaded sentence with no filler. It is appropriately sized for a trivial listing tool, though the brevity is partly under-specification rather than disciplined concision.

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 description should compensate by saying what a call returns (ad unit ids, names, sizes, status) and whether results are paginated. Neither is present, leaving an agent unable to predict the response for a one-parameter listing 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 a single parameter at 100% schema coverage, the schema already documents that property is the AdSense account id from list_properties. The description's 'in the AdSense account' phrasing loosely reinforces that, but adds no syntax, format, or example 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 names the resource (ad units) and its scope (per ad client in the AdSense account), so an agent can tell it is a listing tool. However, it never states the verb and does not distinguish itself from the closely named sibling adsense_ad_unit_performance, which an agent could easily confuse it with.

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

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

There is no guidance on when to use this tool versus adsense_ad_unit_performance or adsense_report, no prerequisites, and no exclusions. The agent must infer usage entirely from the name and the required property parameter.

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, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds nothing about return format, alert types, freshness, or pagination, providing no behavioral context beyond the resource name.

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?

It is a single short sentence with no filler and is front-loaded. However, it is arguably too terse for a tool that needs usage context, making it concise but under-specified rather than optimally structured.

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

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

No output schema exists, so the description should explain what an alert contains or how results are scoped. It does not, leaving the agent without return-value context or usage guidance for a read-only alert 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 100%, and the single property parameter is fully documented in the schema with an example. The description adds no parameter meaning beyond what the schema already provides, so the 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?

The description names the resource (policy and account alerts) and scope (AdSense account) but uses no verb and reads largely as a restatement of the title. It distinguishes from siblings only by topic, not by action, so the agent must infer that it retrieves alerts.

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 indication of when to use this tool versus list_properties or the many adsense_* report tools. No prerequisites, exclusions, or alternative routing is provided.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds no behavioral context beyond that — it says nothing about default date-range behavior when startDate/endDate are omitted, pagination via limit, or the scope of data returned. For a report tool with four parameters, this 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?

Two short sentences, no filler. The metric scope is front-loaded and the actionable insight (find high-traffic, low-RPM markets) follows immediately. 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?

With no output schema, the description does helpfully enumerate the returned metrics, which is genuinely useful. But it omits default date-range behavior, the pagination semantics of limit, and the dependency on a valid property id from list_properties — all of which an agent needs to invoke this 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 only 25% — only the required 'property' parameter is documented in the schema. The description compensates for none of the remaining parameters: it does not explain what limit caps, how startDate/endDate bound the query, or what happens when the date range is omitted. The metric list corresponds to output, not inputs.

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 the resource (country-level AdSense earnings) and the exact metrics returned — earnings, page views, RPM, CTR — which clearly separates it from siblings like adsense_platform_split or adsense_top_pages. It does not explicitly name those siblings, but the dimension (per country) 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 second sentence implies a use case ('Spot markets with high traffic but low RPM'), which gives a hint about when the tool is valuable. However, it never states when to prefer this over adsense_earnings, adsense_report, or gsc_device_country_breakdown, nor does it mention the required property prerequisite.

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 (readOnly, idempotent, non-destructive). The description adds the detection heuristic (≥30% vs. prior 7 days), which is genuine behavioral context, but gives no indication of output shape, series length, or how flags are surfaced.

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 dense sentence that front-loads the metrics and follows with the anomaly rule and diagnostic payoff. No filler, though the diagnostic clause compresses several ideas together.

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 does name the returned dimensions (earnings, page views, RPM, flags) and the flagging rule. It is reasonably complete for a read-only trend tool, with the days parameter being the main unexplained element.

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 33%, with days and thresholdPct undocumented in the schema. The description partially compensates by echoing the 30% threshold and 7-day baseline, but says nothing about the days window or its 60-day default.

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

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

States specific metrics (daily earnings, page views, RPM) plus the distinctive anomaly-flagging behavior, so the agent knows this is not a raw earnings pull like adsense_earnings. Siblings are not named explicitly, which is the only thing keeping it from 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 implies the diagnostic use case ('Catches policy limits, ad-serving issues and traffic loss') but never states when to choose this over adsense_earnings, adsense_report or ads_daily_trend. Usage is inferable but not spelled out.

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 read-only, idempotent, non-destructive profile, and the description adds real context on top: the default range (last 30 days), the output shape (totals + daily breakdown), and the exact effect of compare (adds previous period with percentage change). It still says nothing about account/property authorization requirements or result volume, but it clears the annotation-adjusted bar.

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 what is returned, then the optional compare behavior. No filler; each clause 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?

With no output schema, the description usefully describes the return shape (range totals plus daily breakdown) and the compare variant. Remaining gaps are minor: no mention of account scoping via list_properties or date-format expectations, both partly inferable from siblings and the schema pattern.

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 25% (property alone is documented), so the description must compensate; it does cover compare and the default date window that governs startDate/endDate. However, it adds nothing about the required property parameter, its list_properties source, or the YYYY-MM-DD date format, leaving date semantics thin.

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 (AdSense earnings) and precise scope: range totals plus a daily breakdown. An agent can tell it returns an earnings summary with daily granularity, though it never distinguishes itself from near-siblings like adsense_report, adsense_daily_trend, or adsense_monthly_report.

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

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

Usage is implied rather than stated: the default 30-day window and the compare=true period-over-period mode sketch the intended scenarios. No explicit when-not or alternative tool is named, so an agent facing the earnings/report/daily-trend cluster gets no routing help.

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

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

Annotations already declare readOnly, idempotent, non-destructive, open-world behavior, so the safety profile is covered. The description adds genuinely useful behavioral context beyond them: the comparison is calendar month to date against the same days of the previous month, which defines the semantics of the returned figures. It still omits auth/account scoping and whether the default date window is used when endDate is absent.

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 dense sentence with no padding, and the most important element (what the agent gets back) is front-loaded right after 'One call'. The 'One call:' opener is slightly gimmicky but costs little.

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 sections (earnings, page views, RPM, top 10 pages, top 5 countries, platform split, alerts, anomalies), which is exactly what an agent needs to judge output fit. The remaining gap is operational: how endDate is interpreted and that a property id 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 only 50%: property is documented in the schema but endDate carries only a regex pattern with no meaning or default. The description says nothing about either parameter, so it does not compensate for the undocumented endDate or clarify that property is mandatory and must come from list_properties.

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 resource (AdSense monthly report) and enumerates exactly what the bundle contains, so an agent understands this is a composite month-over-month report rather than a single-metric pull. It does not, however, differentiate itself from the many overlapping siblings such as adsense_report, adsense_earnings, or adsense_daily_trend.

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 named alternative, despite a crowded sibling set (adsense_report, adsense_earnings, adsense_daily_trend, adsense_top_pages, adsense_by_country) whose individual data this tool aggregates. The phrase 'One call' hints at the convenience motivation but never states when the bundled report should be preferred over the narrower 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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the useful content scope (unpaid balance plus payment history), but says nothing about auth requirements, time-range defaults, pagination, or result 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?

A single front-loaded sentence with no filler; the resource and scope come first. It is efficient, though it is terse enough that some needed context is absent.

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 does briefly indicate what is returned (unpaid balance and payment history), which is the minimum. For a financial read tool it should also say whether results are account-wide or time-scoped and how it relates to adsense_earnings.

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 'property' parameter is fully documented in the schema, including its format and where to get it (list_properties). The description adds nothing about the parameter, so the 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?

The description states a specific resource and scope ('unpaid balance and payment history') for the AdSense account, clearly a retrieval of payment data. It is clear on its own but does not distinguish itself from the closely related sibling adsense_earnings, which an agent could easily confuse with payments.

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 named alternatives. The agent is not told how this differs from adsense_earnings or adsense_monthly_report, so selection between the AdSense financial tools 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 readOnly, idempotent, non-destructive and open-world, so the safety profile is covered. The description adds no behavioral context beyond the annotations — nothing about date-range defaults, timezone handling, required property scoping, or result granularity for what is otherwise a fixed-shape report.

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 metric list and followed by the insight framing. No padding, though the second sentence is slightly promotional rather than informative.

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 report with no output schema, stating metrics and breakdown dimension is a reasonable minimum. However, with no date-range behavior, no property-format reminder, and no result shape, an agent still needs the schema to call it correctly.

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

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

Three parameters with only 33% schema description coverage, and the description says nothing about any of them. It never mentions the required property id or the startDate/endDate range, so the two date parameters are 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 specific metric outputs (earnings, page views, RPM, CTR) and the breakdown dimension (desktop, high-end mobile, tablet), which cleanly distinguishes it from siblings like ads_device_performance and gsc_device_country_breakdown. The verb is implicit but the resource and scope are 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 phrase 'Reveals mobile monetization gaps' hints at when the report is useful, but no alternative tool is named and no condition for choosing this over adsense_report, adsense_daily_trend, or ads_device_performance is given. Guidance is left entirely 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 readOnly/idempotent/non-destructive/openWorld, so the safety profile is covered. The description adds the meaningful default of 'last 30 days' for the date range, but says nothing about pagination, result size, or rate limits for what is effectively an analytics query.

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: a definition followed by a concrete example. It is front-loaded and every clause carries information, with only minor room to tighten.

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 8-parameter, low-coverage, no-output-schema analytics tool, the description gives a helpful example and the date default but doesn't cover the full parameter surface or what the report returns, leaving meaningful gaps for an agent to resolve.

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 low (38%), so the description should compensate. It does partially: it introduces the dimensions/metrics model and gives a concrete example, and it clarifies the date-range default. However, it is silent on limit, orderBy, filters, and the required property parameter, leaving those halves unexplained 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?

The description states a specific verb and resource ('custom report with chosen dimensions and metrics for a date range') and the word 'custom' implicitly contrasts with the many preset sibling reports (adsense_earnings, adsense_by_country, adsense_top_pages). It's clear what the tool does, though it never explicitly routes the agent away from those presets.

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. The agent is left to infer that this tool is for ad-hoc dimension/metric combinations versus the ten-plus sibling report tools, and no conditions or prerequisites (e.g. needing a property id) 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 declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds only 'with approval state' and says nothing about pagination, result size, or the account-reference requirement, so it contributes little beyond the 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?

It is only six words with zero filler and the resource is front-loaded, which is efficient. But the fragmentary structure and missing verb make it under-specified rather than genuinely crisp, so it sits at adequate rather than exemplary.

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, single-parameter list tool whose annotations and 100% schema coverage carry the safety and input burden, the description is marginally sufficient. It omits any indication of what a site record contains, ordering, or pagination behavior, which a list endpoint would normally benefit from.

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 100% schema description coverage on the single 'property' parameter, the schema already documents the account-id format and its origin from list_properties. The description adds no parameter meaning, 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?

The phrase names the resource ('Sites') and its scope ('in the AdSense account') and hints at returned data ('approval state'), which separates it from siblings like adsense_ad_units or adsense_payments. However, it is a verbless noun fragment that never says whether it lists, retrieves, or filters sites, leaving the core action vague.

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 prerequisite (e.g. that list_properties must be called first), and no differentiation from the many other adsense_* siblings. The agent must infer the use case entirely.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description contributes useful, non-annotation context by naming the returned dimensions (views, RPM, earnings) in the absence of an output schema, but says nothing about date-range requirements, result limits, or ordering.

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, with the resource and metrics front-loaded and the interpretation guidance second. Every phrase 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?

With five parameters, no output schema, and thin schema descriptions, the definition does cover what the tool returns but omits the required 'property' argument, the meaning of the date window (required for a ranking?), and how many pages come back. Adequate for a read-only report tool but with visible gaps for correct invocation.

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

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

Schema description coverage is only 20% — just the 'property' field — so the description is expected to compensate, and it mentions no parameters at all. startDate/endDate, limit and domain must be inferred purely from their names, with no guidance on defaults, ranges, or how they scope the ranking.

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 (pages) and the metrics returned (estimated earnings, page views, RPM), so an agent knows exactly what the tool produces. It does not differentiate itself from close siblings like gsc_top_pages or adsense_earnings, leaving the agent to infer the boundary from the word 'earnings'.

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 second sentence implies an analytical use case ('shows which content monetizes best and which high-traffic pages have weak RPM'), which hints at when to reach for it. However, it never names alternatives such as gsc_top_pages for pure traffic data or adsense_report for aggregate earnings, and states no 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 readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, covering the safety profile, so the bar is lower. The description is consistent with those hints but adds little new behavioral context (no pagination/limit behavior, no auth or quota notes, no result-shape detail).

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

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

Two tight sentences with no filler, and the core capability (metrics by geography) is front-loaded before the analytical use case. Every phrase 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 five-parameter analytics tool with no output schema and 20% schema coverage, the description names the returned metrics but omits any mention of date-range semantics, result limiting, or how widely results can be grouped. Adequate but with clear gaps.

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

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

Schema coverage is only 20%, so the description is expected to compensate. It does explain the most semantically interesting parameter by spelling out the region/city options for 'level', but leaves limit, startDate and endDate undocumented in prose. Partial compensation for a low-coverage 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 specific metrics (cost, clicks, conversions, CPA) and the exact grouping dimension (country/region/city via level). This clearly differentiates it from the other *_performance siblings such as ads_device_performance or ads_campaign_performance. It stops short of naming which sibling to prefer for wasted-spend analysis, but the resource 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 phrase 'Finds locations that burn budget without converting' implies a use case (wasted-spend localization), which is real guidance. However it gives no explicit when-to-use vs alternatives, no exclusion relative to the overlapping ads_wasted_spend sibling, and no stated prerequisites for date ranges.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered. The description adds useful context about which metric families come back, but says nothing about auth requirements, rate limits, or whether data is fresh/aggregated.

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, metric list front-loaded, no filler. Every clause adds 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 description usefully enumerates the returned metric families, but for a report tool it omits date-range behavior (defaults, timezone, max span) and any sense of output granularity, leaving real gaps for correct invocation.

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

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

Schema coverage is only 33% – property is documented (with a pointer to list_properties) but startDate and endDate carry no description beyond a date regex. The description mentions no parameters at all, so it does not compensate for the uncovered date-range inputs or their defaults.

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

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

States a specific verb+resource (search impression share per campaign) and enumerates the exact metrics returned (lost to budget, lost to rank, top-of-page, absolute-top). This is far more precise than generic siblings like ads_campaign_performance, though it never names an alternative to route against.

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 closing clause 'Shows where more budget or better ads would unlock volume' implies the diagnostic use case, but there is no explicit when-to-use versus ads_budget_pacing or ads_campaign_performance, and no stated prerequisites or exclusions.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint, so the safety profile is covered. The description usefully adds the default time window (last 30 days) and sort order (by cost), which are behavioral traits not in the annotations, but omits pagination behavior for limit and any auth/permission notes.

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 with the metric list front-loaded and defaults trailing. There is minimal waste, though the bare column enumeration leans toward inventory rather than instruction.

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, listing the returned metrics is genuinely helpful, and the default window/sort add context. But for a 5-parameter tool with 20% schema coverage, the description leaves the campaign filter, limit cap, and date format unexplained, and gives no alternative-tool guidance.

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% (just 'property'), leaving limit, startDate, endDate, and campaign undocumented. The description touches date defaults ('last 30 days') but adds no meaning for limit, campaign filtering, or the date pattern, so it does not compensate for the low coverage.

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

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

The description names the resource (keywords) and enumerates the returned metrics (match type, quality score, cost, clicks, conversions, CPA, impression share), so an agent knows this is a keyword-level performance report. However, there is no explicit verb and no differentiation from closely related siblings like ads_search_terms, ads_quality_score_audit, or ads_campaign_performance.

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-relevant statement is 'Default last 30 days, sorted by cost,' which describes default behavior rather than when to choose this tool over alternatives. No when-to-use, when-not-to-use, or sibling routing guidance is provided despite many overlapping ads_* 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, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds nothing behavioral beyond that: no mention of how far back data goes, whether results are paginated (limit defaults to 100, max 500), or that a Google Ads customer id/property is required.

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 resource and its metrics. The second sentence is arguably advice rather than definition, but it is brief and does not bloat the entry.

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 metric list partially substitutes for the absent output schema, which is useful. But with low schema coverage, no output schema, and no date-range or pagination guidance, an agent still cannot tell from the description how wide a query this returns or where the required property value comes from.

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 25% – just the property parameter is documented. The description does not compensate: it never mentions property, the startDate/endDate range, or the limit cap, so three of four parameters carry their meaning only in the raw schema.

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

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

The description names the resource (landing pages) and enumerates the metrics returned: cost, clicks, conversions, CPA and mobile-friendly click rate. That is enough for an agent to know it is a performance-reporting tool, but it never differs from the sibling landing_page_overview, so the boundary between the two is left 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 second sentence ("Pages with high cost and no conversions need work or should be swapped") is post-hoc interpretation advice, not usage guidance. There is no statement of when to call this tool, when not to, or how it relates to landing_page_overview or gsc_top_pages.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is fully covered structurally. The description adds useful scope context about MCC/child hierarchy, but says nothing about ordering, pagination, or whether the full account tree is always returned.

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 tight sentence with the key scope qualifier (MCC and children) front-loaded. It is a noun phrase rather than a verb-led statement, which is slightly less directive than ideal, but 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 zero-parameter list tool with no output schema, the description adequately conveys what the call returns (the connected account set, including manager accounts and their children). Minor gaps remain around ordering and pagination, but nothing essential for 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?

The tool takes zero parameters, so the baseline is 4; there is no parameter syntax for the description to clarify. No credit or penalty beyond that baseline applies here.

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 the specific resource (connected Google Ads customer accounts) and clarifies scope by including manager (MCC) accounts and their direct children, which is meaningful detail beyond the bare name. It does not, however, explicitly distinguish itself from siblings like ads_account_audit or ads_metadata, so the agent must infer that this is the enumeration/discovery entry point.

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 statement of prerequisites, and no mention of alternatives. The agent can infer this is a discovery tool (list accounts before running per-account reports), but that inference is not supported by any text in the 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 readOnly, idempotent, openWorld, and non-destructive, so the safety profile is covered and the bar is lower. The description adds essentially nothing beyond that and the schema – it does not describe the return shape (e.g. field names, types, whether selectable/compatible flags are included), which would be the useful behavioral context for a metadata 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?

One sentence, front-loaded with the verb and resource, with zero filler. Example resources are embedded compactly rather than listed separately.

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 carries the burden of explaining what is returned, and it only says 'selectable fields' without describing the response structure an agent would need to consume. For a simple two-parameter read-only lookup this is minimally adequate, but it leaves the return contract underspecified.

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 both parameters are already documented, and the schema even provides examples for each. The description merely echoes example resource names (campaign, ad_group, keyword_view, search_term_view) without clarifying value formats, id requirements, or constraints beyond what the schema states.

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 ('Describes selectable fields of a Google Ads resource') and ties it to GAQL query building, which is distinct from the reporting siblings. It does not explicitly name the complementary tool (ads_query) that would run such a query, so sibling differentiation is implied rather than stated.

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

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

The phrase 'to help build GAQL queries' implies the general usage context, but there is no explicit when-to-use statement, no call out of the alternative (ads_query), and no preconditions mentioned. Usage 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 already declare readOnly=true, idempotent=true, non-destructive, and openWorld, so safety is covered. The description adds that this is the only per-group visibility PMax offers, a useful behavioral constraint, but says nothing about date-range behavior, default ranges, or required property 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?

Two short sentences, front-loaded with the resource and metrics, with no filler. It is efficient, though slightly terse on context.

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, low schema coverage, and no annotations about behavior beyond safety, the description should explain date-range handling and the required customer ID property, and possibly the return shape. It leaves too much implicit for a 3-parameter analytics query 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 only 33%; only the property parameter has a schema description, and startDate/endDate have patterns but no semantic description. The tool description adds no parameter guidance (e.g., date range defaults or required property), so the 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?

Names the specific resource (asset groups) and lists the metrics returned (ad strength, cost, conversions, value), plus the scope (Performance Max campaigns). It doesn't explicitly differentiate from siblings like ads_campaign_performance, but the resource is distinct enough to be identifiable.

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

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

No statement of when to use this tool versus alternatives such as ads_campaign_performance or ads_query, and no prerequisites or exclusions are given. The 'only per-group visibility PMax offers' line hints at uniqueness but is not framed as usage guidance.

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

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

The readOnlyHint confirms it's safe, but the description adds real value by explaining outputs are impression-weighted and that the result set is threshold-bounded via maxScore. It doesn't say what happens to keywords above threshold or how 'money spent' is computed.

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 dense sentence with no filler, front-loaded on what the tool returns. Slightly hard to parse due to nested clauses, but nothing wasteful.

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

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

Output shape is described well for a tool with no output schema, but the limit parameter and date-range scoping aren't explained, so an agent isn't fully equipped to call it correctly.

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

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

Schema coverage is only 20%, so the description must compensate. It explains maxScore as the threshold filter, and implies startDate/endDate scope the spend, though it never mentions 'limit' (capping keywords returned) or the required customer id beyond what the schema states.

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 specific outputs: impression-weighted quality score, a 1-10 distribution, and keywords at/below threshold with weakest component and wasted spend. Clearer than a bare name, though it doesn't contrast against siblings like ads_keyword_performance or ads_wasted_spend.

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 or when-not guidance, and no mention of alternatives such as ads_keyword_performance or ads_wasted_spend, which overlap on keyword and spend analysis.

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

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

Annotations already declare readOnly, idempotent, non-destructive and open-world, so safety is covered. The description adds useful context about micros money units and query shape, but says nothing about the account binding or result 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?

Three sentences: intent first, example second, unit caveat last. No filler, and the most operationally important caveat (micros) is included.

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 general-purpose query tool with a thin two-param schema, the description gives enough for correct invocation: the query language, an example, and the money-unit gotcha. It could note row limits or the customer id source (which the schema already covers).

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 'property' parameter is described in the schema as a customer id from list_properties, and the description supplies a full example GAQL query clarifying 'query' even though schema coverage is only 50%. Together they leave little ambiguity.

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: runs a GAQL SELECT against a customer account, and gives a concrete example query. This clearly distinguishes it from the sibling analytical tools like ads_campaign_performance, which are fixed-purpose reports.

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?

Implies usage for arbitrary GAQL queries but gives no explicit when-to-use vs when to prefer the many purpose-built sibling tools such as ads_campaign_performance or ads_device_performance.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful context beyond that: recommendations are Google-sourced rather than tool-computed, impact estimates may be missing, and applying changes must happen outside this tool. It stops short of noting whether recommendations are fetched live or cached.

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

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

Two dense sentences: the first says what the data is and its shape, the second says what you can't do with it. Nothing is repeated from the title or annotations unnecessarily, and the key constraint 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 one-parameter read tool with full annotation coverage and no output schema, the description gives enough — content categories, impact estimates, and the apply-elsewhere constraint. A brief hint at response structure or freshness would close the remaining 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 100% for the single required 'property' parameter, and the description adds nothing about it. With the schema fully documenting the customer id format and its link to list_properties, the 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 resource — Google's own optimization recommendations — and enumerates the categories (keywords, budgets, ad suggestions, bidding) so an agent knows what comes back. The phrase "Google's own" distinguishes it from tool-derived diagnostics such as ads_account_audit or ads_wasted_spend, though no sibling is named 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 implied: consult this to see Google-generated suggestions, and the tool cannot apply them — "apply them in the Ads UI" states that constraint. However, it never says when to prefer this over ads_account_audit or ads_wasted_spend, or what prerequisite exists beyond a property id.

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

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

Annotations already declare readOnly, idempotent, non-destructive and open-world, so the safety profile is covered. The description adds the default lookback window and the cost-based ranking, but says nothing about pagination, result caps, or how limits interact with the ranking.

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 padding, and the metric list and defaults are front-loaded so the agent sees scope and default behavior 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 does list the returned metrics and defaults, but with 5 parameters, 40% schema coverage and no success/limit behavior documented, an agent still lacks guidance on filtering and result volume for a genuinely complex 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 coverage is 40%: campaign and property are documented in the schema while startDate/endDate and limit are not. The description partially compensates by revealing the date default and that results are ordered by cost, which the schema does not state, but it adds nothing about the campaign filter or the interaction between limit and date range.

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

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

States a specific resource (actual search terms that triggered ads) plus the metrics returned, which separates it from sibling keyword/keyword-target reports like ads_keyword_performance. It stops short of explicitly naming the sibling it differs from, so an agent must 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 description gives defaults (last 30 days, top 200 by cost) but never says when to use this report versus alternatives such as ads_keyword_performance, ads_query, or ads_wasted_spend. No prerequisites or exclusions 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 declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful behavior beyond that: the 30-day default window, cross-campaign aggregation, and the phrase-vs-exact negative keyword suggestion strategy, but says nothing about pagination/limit behavior or result size.

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 dense sentence that front-loads the core concept (wasted-spend search terms) and appends the output detail. Nothing is wasted, though the parenthetical about phrase/exact keywords slightly overloads the 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 7-parameter, no-output-schema tool, the description conveys the analysis and its output well but leaves most filter parameters (limit, campaign, minCost/minClicks defaults) for the agent to infer from the schema. Adequate but with clear gaps.

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

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

Schema description coverage is only 14% (just the property field), leaving six of seven parameters undocumented in structured data. The description partially compensates by implying a period default and cost/click thresholds ('cost money or clicks', 'default 30 days'), but never explains limit, campaign, or the startDate/endDate formats.

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

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

The description gives a specific verb+resource: search terms that spent money/clicks without converting, aggregated across campaigns, plus negative keyword suggestions. This distinguishes it functionally from generic siblings like ads_search_terms and ads_keyword_performance, though it never names an alternative to route between 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?

It supplies the default window (30 days) and the aggregation scope, which implies the intended use case, but there is no explicit when-to-use vs ads_search_terms / ads_keyword_performance guidance and no stated prerequisites such as needing a property id from 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 already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds useful output context (earnings per organic click, high-traffic/low-earning pages, strong earners), but says nothing about how unmatched URLs are handled, aggregation granularity, or the effect of the days/limit windows.

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 the join operation front-loaded and the payoff (three analyzable page classes) immediately after. No filler, though the second sentence is a comma list rather than a structured breakdown.

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 does the right thing by enumerating what is returned, and annotations cover safety. It remains incomplete on parameter semantics (days/limit), on the prerequisite of resolving property ids via list_properties, and on time-window 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 only 50%: the two required property ids are documented in-schema, but 'days' and 'limit' have no descriptions at all. The description text mentions no parameter, format, or range, so it does nothing 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?

The description names a specific verb ('Joins') and two concrete resources (Search Console clicks per page, AdSense earnings per page URL), so the operation is unambiguous. It is functionally distinguishable from gsc_top_pages and adsense_top_pages by being a cross-source join, but it never names or contrasts 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?

There is no when-to-use guidance, no statement of prerequisites (both a GSC property and an AdSense account id must be obtained from list_properties), and no exclusion pointing the agent to gsc_top_pages, adsense_top_pages, or paid_vs_organic for single-source views. Usage must be inferred entirely from the returned-metric list.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered. The description adds genuine behavioral detail beyond that by disclosing the return shape (totals, click share, top non-brand queries), which matters because 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 short sentences with zero filler; the core operation is front-loaded and the regex example and return summary follow in order of usefulness.

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, idempotent analysis tool with no output schema, the description covers the operation and the main return values adequately. The only notable gap is the undocumented days and compare parameters, which the agent must infer.

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%: property and brandPattern are documented, but days and compare are described in neither schema nor description. The inline regex example ('metric ?port|metricport') usefully clarifies the brandPattern format, so the description adds real value even though it leaves two 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 ('splits queries into brand and non-brand') and is clearly distinct from siblings like gsc_top_queries, gsc_query_clusters, or gsc_search_analytics, none of which perform a brand/non-brand segmentation. An agent can identify the tool's job without opening the schema.

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

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

The description never says when to reach for this tool versus the other GSC query tools, nor any prerequisites or exclusions. The line 'Non-brand is the real SEO performance' hints at motivation but is framing, not actionable when-to-use guidance.

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

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

Annotations already establish read-only, idempotent, non-destructive, open-world behavior. The description adds genuinely new context by disclosing the shape of the result set (leader page, click share, competing pages), which matters since there is no output schema. It does not mention thresholds, pagination, or sample-size 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?

Two tight sentences with zero filler; the definition of the dataset is front-loaded and the actionable takeaway closes it. 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 four-parameter read-only tool with no output schema, the description adequately conveys what comes back but leaves the time-window, result-limit, and impression-threshold parameters entirely unexplained in both schema and description. Adding default behaviors (90 days, 50 rows, 30 impressions) would close the 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 only 25% — just the property id is documented. The description says nothing about days, limit, or minImpressions, leaving the agent to infer their meaning purely from names and defaults. With low coverage the description is expected to compensate and it does not.

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

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

Names a specific analytical resource (queries where 2+ pages compete) and the exact output it produces (leader, click share, competing pages). It is distinguishable from near-neighbors like gsc_page_queries or gsc_query_clusters, 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 via the outcome clause 'so you can consolidate or differentiate' — it tells the agent what to do with results but never states when to pick this tool over gsc_page_queries, gsc_query_clusters, or gsc_quick_wins. 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 and destructiveHint=false, so safety is covered. The description adds that results include both losers and winners, and hints at comparison semantics, but does not cover the minPreviousClicks filtering, limit behavior, or output 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?

Three tight sentences: definition, actionability, and secondary output. No filler and the key comparison option 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?

No output schema exists, and the description does not explain the returned fields (e.g., click loss, winning pages) or the role of minPreviousClicks. For a 5-parameter analytics tool with low schema coverage, this leaves gaps an agent may not fill.

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 20%, so the description must compensate. It clarifies that compareTo can be 'year' (same period last year), which is the most consequential parameter meaning. Other params (days, limit, minPreviousClicks) remain undocumented in both places, keeping it below 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-plus-resource: pages that lost the most clicks versus a comparison period. It also distinguishes itself from siblings like gsc_top_pages or gsc_quick_wins by naming the decay framing, and clarifies the winning-pages side output.

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?

Implies when the tool is useful ('fastest SEO win') and names compareTo=year as an option, but gives no explicit when-not-to-use or sibling routing (e.g., use gsc_quick_wins for opportunities). 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 cover read-only, idempotent, open-world, and non-destructive safety. The description adds behavioral context beyond that: it defines the qualifying condition (page one, CTR far below expected) and states what is returned (expected CTR and missed clicks), which is valuable without 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?

Three tight sentences, front-loaded with the core definition, followed by diagnostic interpretation and return values. No filler; every sentence contributes.

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-parameter query tool with no output schema, the description gives a good conceptual overview and return fields but omits guidance on time window (days), result count (limit), and when to choose this over sibling GSC tools. It is adequate but leaves clear gaps.

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

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

Schema description coverage is only 20% (only 'property' is documented), so the description must compensate. It implicitly maps 'page one' to maxPosition and 'lots of impressions' to minImpressions, but does not name or explain the 'days' and 'limit' parameters, leaving meaning partially 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 purpose: finding page-one queries with CTR far below expected, and explains what that means (title/meta problems). Clearly identifies the resource and filter logic. However, it does not explicitly distinguish itself from close siblings like gsc_quick_wins or gsc_zero_click_pages.

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?

Implies usage by framing results as 'title and meta description problems', suggesting the tool is for diagnosing and fixing underperforming titles/meta. But it gives no explicit when-to-use or when-not-to-use guidance, and no alternatives are named.

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 (readOnly, idempotent, non-destructive, open-world). The description adds meaningful behavioral detail beyond annotations: a 7-day moving average, anomaly flags at ≥30% vs the prior week, and gap detection for 3+ consecutive days without data.

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 operation and then the intended use cases. Every sentence adds value with no repetition 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?

Explains what the tool returns and how anomalies are detected, which is useful given no output schema. However, it omits how page and query parameters filter results, and does not clarify the days parameter behavior, leaving invocation details incomplete.

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

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

Schema description coverage is only 20%, so the description must compensate, but it does not explain days, page, query, or thresholdPct beyond an implied 30% default. Page and query filters are entirely unmentioned, leaving key scoping parameters unclear.

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

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

States a specific resource (daily clicks/impressions) and analysis (7-day moving average with anomaly flags), distinguishing it as a trend/anomaly tool. It does not explicitly differentiate from siblings like gsc_search_analytics, so it falls short of a 5.

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

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

Gives clear usage context: 'Spot Google updates, outages and seasonality.' This tells the agent when the tool is useful, but it does not name alternatives or 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 readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds no behavioral context beyond output content - no mention of how long a 480-day scan takes, pagination, or data-freshness caveats for GSC data.

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

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

Two compact sentences, front-loaded with the metric/dimension scope followed by the analytical use case. No wasted words.

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

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

For a read-only analytics tool with annotations covering safety and no output schema, the description is adequate on output content but leaves the two numeric parameters and any scoping/limitation context 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 coverage is only 33% (only 'property' is documented), and the description adds no parameter meaning at all - it never explains 'days' or the 'countries' count cap of 100. With a coverage gap this large, the description should compensate but does not.

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

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

The description names specific metrics (clicks, impressions, CTR, position) and the two grouping dimensions (device, country), plus the mobile-vs-desktop CTR gap. That is far more concrete than a generic 'search analytics' sibling, though it never explicitly contrasts itself with gsc_search_analytics or ads_geo_performance.

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 closing sentence 'Finds markets and devices that underperform' implies the use case, but there is no explicit when-to-use/when-not guidance and no named alternative for country-only or device-only analysis.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds the net-new fact that results come back as a compact table with specific columns, but says nothing about quota consumption (URL Inspection is metered), latency, or permission requirements for a batch live-check.

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 tight sentence that front-loads the operation and then lists outputs. No filler, though the return-column enumeration makes it denser than strictly necessary for an invocation-time description.

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

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

For a batch read tool with no output schema, the return-field list is a useful addition that compensates somewhat for the missing output contract. Still absent are the property prerequisite, quota/latency expectations, and any behavior when only some URLs fail, which matter for an open-world batch check.

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%: 'property' is documented in the schema while 'urls' is not described there. The description partially compensates by stating the 10-URL ceiling, but that cap is already enforced by maxItems and it says nothing about the property id format or per-URL failure 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?

States a specific verb and resource ('Inspects up to 10 URLs') and enumerates the returned fields, so the intent is unambiguous. It implicitly separates itself from the single-URL sibling gsc_inspect_url via the batch cap, but never names or contrasts with that sibling, so differentiation must be inferred.

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 (e.g. needing a verified property), and no routing advice versus gsc_inspect_url, gsc_sitemaps or gsc_search_analytics. Usage can only be guessed 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 declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds the return-field inventory, which is genuinely useful, but says nothing about quota limits, auth scopes, or rate constraints for a live URL-inspection call.

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 compact sentence, front-loaded with the purpose and then the returned fields. No filler, no restatement of the title, every token 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 description does the right thing by listing the return fields, which is sufficient for the response side. However, it leaves the gsc_index_check overlap unresolved and omits any auth or eligibility context for a tool that requires a specific Search Console property.

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

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

Schema description coverage is 50% (only 'property' is documented; 'url' relies on format=uri). The description adds no parameter-level meaning, neither explaining how 'property' relates to the URL's domain nor what form the URL must take, so it neither compensates for nor worsens the coverage gap. Baseline 3.

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 ('Google index status for one URL') and enumerates the fields returned (verdict, coverage state, last crawl, canonical, mobile usability, rich results). It is clear what the tool does, but it does not differentiate itself from the close sibling gsc_index_check, which an agent will likely confuse it with.

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

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

There is no when-to-use guidance, no mention of prerequisites, and no routing to alternatives such as gsc_index_check or gsc_search_analytics. The only contextual link (property comes from list_properties) lives in the schema, not the 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?

The annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered and the bar is lower. The description adds the comparative-window concept (this period vs. previous), which is genuine behavioral context, but stays silent on how the comparison windows are derived, whether results are ranked or capped, and how the minImpressions threshold affects which queries count as new/lost.

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 no waste: the definition of the metric is front-loaded and the usage cue follows. Sizing is appropriate for a single-purpose analytical 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?

Annotations cover the safety profile so the description needn't restate them, and no output schema exists so return-shape explanation would help but is arguably optional. However, for a 4-parameter tool with 25% schema coverage, the description omits the comparison-window mechanics and the effect of minImpressions, which an agent needs to interpret 'new' and 'lost' 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 only 25% (only 'property' is documented), so the description carries a real burden here — and it contributes nothing about days, limit, or minImpressions. 'This period but not the previous one' hints that a lookback window exists but never states how the days parameter defines it or that minImpressions gates inclusion, leaving three undocumented parameters entirely 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?

Names a specific analytical resource and precisely defines both halves of the output: queries that appeared this period but not the previous, and queries that disappeared. An agent can grasp the concept without opening the schema, though it never contrasts itself with adjacent siblings such as gsc_content_decay or gsc_query_clusters that also do period-over-period analysis.

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?

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=true, idempotentHint=true, destructiveHint=false, openWorldHint=true), so the bar is lower. The description adds the return metrics, which is useful given no output schema, but says nothing about the time window actually queried, row capping, or ordering.

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, zero filler. The return content is front-loaded and the use case follows, each earning 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?

With no output schema, listing the returned metrics is necessary and present. However, for a time-windowed analytics read, the absence of any statement about the default 90-day range and the 200-row cap leaves gaps an agent would need to infer from the schema defaults.

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

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

Schema description coverage is only 50%: 'days' and 'limit' have defaults and bounds but no description, and the description supplies no parameter guidance at all. Saying 'All queries' is faintly at odds with a default limit of 200, and the 90-day default window is never surfaced.

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: 'All queries a single URL ranks for, with clicks, impressions, CTR and position' tells the agent exactly what is returned and the scope ('a single URL'). That scope implicitly separates it from gsc_top_queries and gsc_top_pages, though no sibling is named 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?

Gives a clear use case: understanding what a page is known for and which secondary keywords to strengthen. It stops short of naming alternatives (e.g. gsc_top_queries for site-wide queries) or stating when this is the wrong choice.

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

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

Annotations already declare readOnly=true, idempotent=true, destructive=false, so the safety profile is covered. The description usefully discloses the shape of the result (clusters with total clicks, impressions, example queries), which matters since there is no output schema, but says nothing about the clustering method or the default 90-day window.

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

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

Two tightly written sentences with the core action front-loaded and no filler. Nothing is wasted, though it is arguably too terse given the undocumented parameters.

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

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

For a 4-parameter read tool with no output schema and 25% coverage, the description covers purpose and output shape but leaves three parameters unexplained. Adequate but with clear gaps an agent would have to guess at.

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

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

Schema description coverage is only 25% – just 'property' is documented. The description adds no meaning for days, limit, or minQueries, and notably never explains that minQueries controls the minimum cluster size. With low coverage the description should compensate, and it does not.

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

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

States a specific verb and resource ('groups queries by shared terms into topic clusters') and even names the return contents (clicks, impressions, example queries). It distinguishes itself from the top-query listers by being a clustering tool, though it never explicitly contrasts with siblings like gsc_top_queries or gsc_question_queries.

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 closing clause ('where a hub page or new content would pay off') implies a content-strategy use case but gives no explicit when-to-use, when-not-to-use, or named alternative. An agent must infer selection from the purpose 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 cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower. The description adds genuinely new behavioral context: results are sorted by impressions and question detection is multilingual (the German examples wie/was/warum), which tells the agent the filter is not English-only.

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, zero filler, with the filtering rule and sort order front-loaded before the downstream use cases. 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?

With no output schema, the description should carry more weight, and it omits the time window and result cap entirely. The purpose and multilingual filtering are clear, but an agent cannot predict result size or recency from this text alone.

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% — just the required property field is documented. The description never mentions the days window (default 90, max 480) or the limit (default 50, max 500), so it fails to compensate for the two undocumented 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 names a specific resource (queries phrased as questions) and a scope modifier (sorted by impressions), which implicitly separates it from gsc_top_queries and gsc_page_queries. It stops short of naming those siblings, so an agent must infer the boundary rather than being told it.

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?

"Direct input for FAQ sections, featured snippets and new articles" describes what to do with the output, which implies the tool's use case, but it gives no when-to-use versus when-not guidance and never names an alternative sibling 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 readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description goes further by explaining the ranking heuristic (~3 position lift estimate), the default position window, and that the ranking page is returned — genuinely useful behavioral context 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 dense sentences with zero filler. The core purpose (striking-distance queries) leads, followed by the ranking method and the payload content — a well front-loaded structure.

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

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

There is no output schema, yet the description explicitly characterizes the return set (queries with real impressions, ranked, with ranking page). That covers the output gap well for a read-only analytics tool, leaving only the under-documented input parameters as a residual 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 29% (7 params, only property and excludePattern documented), so the description must carry more weight. It partially compensates by specifying the default position window (5-20), the impressions requirement, and the position-lift heuristic, but days, limit, and the minImpressions threshold semantics remain 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?

The description states a specific concept (queries in striking distance, default positions 5-20), the ranking basis (estimated extra clicks if pushed ~3 positions), and what is included (the ranking page). It is clearly distinct from gsc_top_queries or gsc_search_analytics, though it never names the closest sibling (gsc_ctr_opportunities) to sharpen the boundary.

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 concept itself — an agent can infer this is for finding optimizable queries. However, there is no explicit when-to-use, when-not-to-use, or alternative (e.g. gsc_ctr_opportunities) named, so the guidance remains inferential 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 cover read-only, idempotent, non-destructive nature. The description adds valuable context beyond that: the data lag (~2-3 days) and the resulting default range, plus the compare-period behavior. It doesn't describe row limit/pagination behavior, but the lag and compare semantics are meaningful additions.

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

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

Two compact sentences, front-loaded with what the tool returns, followed by the key default behavior. 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 flexible 9-parameter analytics tool with no output schema and poor schema coverage, the description covers the metrics and date defaults but omits what the response looks like (rows per dimension combination) and how pagination works. It's adequate but leaves clear gaps given the 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 description coverage is only 11%, so the description needs to compensate but doesn't. It mentions dimensions, filters and compare semantically, but does not explain 'type' (web/image/video/news), startRow/rowLimit pagination, or the filter operators, leaving most of the 9 parameters undocumented by 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?

States a specific verb ('grouped by dimensions'), the metrics (clicks, impressions, CTR, position) and filter capability. It doesn't explicitly distinguish itself from siblings like gsc_top_queries or gsc_top_pages, but the generic dimensional grouping concept is clear.

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 generic analytics tool versus the many specialized siblings (gsc_top_queries, gsc_device_country_breakdown, etc.). The only usage hint is the default date range and compare flag, not selection criteria.

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

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, so the safety profile is covered. The description adds a useful scope fact — that it spans Discover and Google News, not just Search — but says nothing about the default lookback window, freshness, or output granularity.

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. It is efficient, though it spends its brevity on enumeration ('rich results, video, AMP…') instead of the parameter it leaves undocumented.

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 and only one of two parameters documented, the description should carry more weight. It never explains what the returned performance metrics are (clicks, impressions, CTR, position?) or how appearance/Discover/News segments are broken out, leaving the agent guessing at the return 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 coverage is only 50%: 'property' is documented in the schema, but 'days' (integer, default 28, range 7–480) has no description anywhere. The description does not explain the period parameter at all, so the agent cannot tell whether the range is configurable.

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 reporting resource (search appearance plus Discover and News traffic) with examples of appearance types (rich results, video, AMP). It is distinguishable from plain gsc_search_analytics by naming the appearance/Discover/NEWS surfaces, though it never explicitly contrasts with that 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?

No when-to-use guidance, no prerequisites, and no mention of the obvious alternative (gsc_search_analytics) in a family of ~20 gsc_* siblings. The agent must infer that this tool is for appearance/Discover breakdowns rather than general search performance.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds useful return-shape information (status, errors, warnings, URL counts), which matters since there is no output schema, but it omits pagination, sitemap URL listing, and any auth/scope detail.

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

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

A single tight sentence with no filler. It is efficient, though it is a noun phrase fragment rather than a complete action statement, which slightly limits front-loading of intent.

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

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

For a simple one-parameter read tool with no output schema, the description conveys the returned fields, which is the key missing piece. However, it omits any usage context or verb, leaving the agent to infer that this is a passive retrieval of sitemap diagnostics.

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% for the single property parameter, and the schema already explains its format and source (list_properties). The description adds nothing about the parameter, so the baseline of 3 is appropriate.

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

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

The description names the specific resource (submitted sitemaps) and enumerates the data returned (status, errors, warnings, URL counts), so an agent knows exactly what this tool yields. It lacks an explicit verb like 'Retrieve', but as the only sitemap-related tool among the siblings there is no ambiguity about 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?

There is no when-to-use guidance, no mention of prerequisites, and no alternatives named. The only routing hint (fetching the property id from list_properties) lives in the schema, not the 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, idempotentHint=true, openWorldHint=true, destructiveHint=false, so the safety profile is covered. The description adds the default window (28 days) and the non-obvious semantics of the query filter (it restricts pages to those with matching queries), but says nothing about ranking basis beyond clicks, result caps, 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?

Two compact clauses, front-loaded with the resource and metric, followed immediately by the filter caveat. No filler 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?

With no output schema, the description should say what a 'page' row contains (clicks only? impressions, CTR, position?) and that results are capped by limit. It covers the input side adequately for a simple analytics read but leaves the return shape undefined.

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 25% — only 'property' is documented in the schema. The description clarifies the query filter's meaning, which the schema leaves bare, but 'limit' is undocumented in both and the 28-day default is merely repeated from the schema default.

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

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

States a specific verb+resource ('Top pages by clicks') with the ranking metric named, which is more than a tautology. It doesn't explicitly distinguish itself from near-neighbours like gsc_top_queries or gsc_page_queries, but the 'pages' resource makes the target clear.

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

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

No when-to-use or when-not-to-use guidance, and no alternatives named despite many overlapping siblings (gsc_top_queries, gsc_page_queries, landing_page_overview, ads_landing_pages). The only usage hint is the query filter's behavior, which is a parameter note rather than tool-selection 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, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety and repeatability profile is fully covered. Beyond that the description adds the default window (28 days) and, more valuably, that the page filter is a URL substring match rather than an exact match — but says nothing about result ordering, result count behavior, or data freshness. Modest additional value over 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 short sentences, zero filler, with the ranking metric and time window front-loaded before the optional filter. Every clause carries information the caller 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?

With no output schema, the description carries the burden of describing what comes back, and it does not — an agent cannot tell whether results include impressions, CTR, or average position alongside clicks, nor how 'limit' shapes the response. For a four-parameter analytics retrieval tool, this is adequate but leaves a clear 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 25% (only 'property' is documented), so the description should compensate. It does explain 'days' (last N days, default 28) and the substring semantics of 'page', but 'limit' (default 50, max 1000) is never mentioned in either place, leaving one of four parameters semantically 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+resource combination — top search queries ranked by clicks over a configurable window — which is unambiguous on its own. It implicitly separates itself from gsc_top_pages (pages vs queries) but never names or contrasts with siblings like gsc_search_analytics or gsc_query_clusters, so an agent must infer the boundary.

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 context is implied: it is for ranked query performance over a recent window, optionally scoped by page. There is no explicit when-to-use vs when-not, no mention of alternatives for related needs (page-level breakdown, query clusters, brand split), and no prerequisites stated beyond the schema's hint about 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 already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. With no output schema, the description usefully carries the return-content burden by naming the report sections, and it discloses that brandPattern changes the output shape (adds a brand/non-brand split). It does not state how the reporting window is derived or any data-freshness/rate-limit caveats.

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, front-loaded with the core promise ('One call for a client-ready weekly summary') followed by the content list. No filler or redundancy.

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

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

For a read-only, annotation-covered report tool with no output schema, the description is nearly complete: it tells the agent what comes back and the optional brand split. The remaining gap is the endDate/reporting-window semantics, which neither the schema nor the description explains.

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 33% (only 'property' is documented). The description partially compensates by explaining brandPattern's effect ('Optional brandPattern adds a brand/non-brand split'), but endDate is left entirely unexplained in both schema and description, so how the weekly window is anchored is never stated.

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 ('client-ready weekly summary') and then enumerates exactly what it aggregates: totals vs. previous week, winners/losers for pages and queries, new queries, quick wins, anomalies. That content list implicitly maps to and distinguishes it from the atomic siblings (gsc_top_pages, gsc_quick_wins, gsc_new_and_lost_queries, gsc_brand_split), so an agent can tell this is the consolidated report rather than a single-metric tool.

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?

'One call for a client-ready weekly summary' implies the reporting use case, but the description never states when to prefer this over the granular sibling tools, nor any exclusions or prerequisites (e.g. needing a valid property first). Usage is inferable but not spelled out.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so safety is covered. The description adds a definitional trait of the result set (impressions with zero clicks), but omits consequential behavior such as the minImpressions threshold (default 100) that gates what counts as a 'zero-click page'.

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

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

Two sentences with no filler, and the core definition is front-loaded ahead of the use-case. It is arguably too terse for a four-parameter tool, but nothing written 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 output schema, an agent gets no idea what fields come back (page, impressions, clicks, CTR, position), and with 25% parameter coverage the defaults for days/limit/minImpressions are undocumented in prose. For a filtered analytics tool this leaves 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?

Schema description coverage is only 25% (only 'property' is documented), and the description contributes nothing about days, limit, or minImpressions. The only faint linkage is that 'impressions but no clicks' gestures at the minImpressions filter, but the agent gets no guidance on defaults or ranges from prose.

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 analytical result set ('Pages that get impressions but no clicks'), which an agent can distinguish from gsc_top_pages or gsc_search_analytics. It stops short of naming a verb or explicitly contrasting with the closest siblings gsc_ctr_opportunities and gsc_quick_wins, which also target low-CTR improvement.

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?

'Candidates for title rewrites, better snippets or deindexing thin content' implies the intent behind using it, giving an agent a usable mental model. However, it never states when this tool should be chosen over gsc_ctr_opportunities or gsc_quick_wins, nor any prerequisite such as needing a property id first.

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 that this is a read-only, idempotent, open-world operation. The description adds useful behavioral context by explaining that it joins two data sources by URL and surfaces specific opportunity categories, though it does not discuss date alignment, matching behavior, or result 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 two tight sentences with no wasted language. The core join is front-loaded, followed immediately by the analytical value of the output.

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

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

The description explains the data sources and the types of pages returned, which helps because there is no output schema. Still, it leaves important details unstated, including the default 30-day window, the result limit, and how the two sources are matched over time.

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%, with gsc_property and ads_property documented but days and limit lacking descriptions. The description does not clarify whether the time window applies to Ads, Search Console, or both, nor does it explain the result limit, so it only partially compensates 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?

The description states a specific operation: joining Google Ads landing-page spend/conversions with Search Console clicks for the same URLs. It clearly defines the resource and output focus, but it does not explicitly distinguish itself from closely related siblings such as paid_vs_organic or ads_landing_pages.

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 second sentence implies the analytical use case by naming the kinds of pages surfaced, such as paid traffic replaceable by organic and converting paid pages with no organic presence. However, it gives no explicit when-to-use guidance or alternatives, which matters given overlapping sibling 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, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds useful context about the return scope (accounts plus their sites/accounts and property ids) but no rate-limit, auth or pagination details, which is acceptable given the annotation coverage.

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 zero filler. The primary purpose is front-loaded and the return-value note follows naturally, so every sentence earns its place.

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

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

With no output schema, the description carries the burden of explaining return values, and it does name the key return (property ids) along with what entities are listed. It could be marginally richer about the shape of the response, but for a 0-param discovery tool it is essentially complete.

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

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

The tool takes zero parameters, so there is nothing to document and schema coverage is 100%. The baseline for a parameter-less tool is a 4; the description correctly adds no redundant parameter 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?

States a specific verb and resource: it lists every connected Google account and their Search Console sites, Ads customer accounts and AdSense accounts. It clarifies its role as the discovery/index tool by noting it returns the property ids the other tools consume, distinguishing it from the many reporting siblings.

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

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

The description makes the use case clear: it supplies the property ids that the Search Console, Ads and AdSense tools require as input, so an agent infers it should run this to discover valid ids. It stops short of an explicit 'call this first' instruction and does not differentiate from the sibling ads_list_accounts, which may overlap.

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