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

Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=true), and the description usefully adds the hard cap of 5 requests plus the cost/latency benefit. However, it says nothing about batch failure semantics — whether one malformed request aborts the whole call or returns partial results — which is the key behavioral unknown for a batch 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?

Two sentences with zero filler; the batching limit and the cost/latency benefit are front-loaded before the field-reference note. Nothing would be gained by lengthening it.

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 batch tool with no output schema, the description covers invocation well but leaves the return shape ambiguous: it doesn't say whether results come back as an ordered array of per-request reports or a merged payload, nor how partial failures surface. An agent can call it, but cannot reliably interpret or error-handle the response.

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

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

Top-level schema coverage is 50% (property documented, requests not), but the description compensates by stating 'Each request takes the same fields as run_report,' routing the agent to a known contract instead of guessing. The nested schema is also richly documented per field, so no additional description of metrics/dimensions/filters is needed.

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

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

States a specific verb and resource ('Run up to 5 reports for one property in a single API call') and explicitly positions itself against the sibling run_report. An agent can distinguish batch vs single-report behavior immediately.

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

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

Gives a clear selection rationale — 'cheaper and faster than separate run_report calls' — which tells the agent to prefer this when multiple reports target the same property. It does not state the inverse case (when run_report is still preferable, e.g. more than 5 reports or reports against different 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=true and openWorldHint=true, so safety is covered. The description adds genuine value beyond that: it discloses the return content (incompatible fields, if any) and its role as a pre-flight validation step rather than a data-fetching 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, entirely front-loaded: the capability first, then the return contract, then the usage trigger. No filler or restated metadata.

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, no-output-schema validation tool, the description supplies the essential pieces: what it validates, what it returns, and when to call it. The heavy nested filter parameters are documented in the schema, so nothing critical is missing from the description.

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?

At 60% schema description coverage, the schema carries most of it — property, metricFilter and dimensionFilter are richly documented there, while the metrics/dimensions arrays are not. The description only implicitly signals that dimensions and metrics are the inputs, adding no format, scoping, or filter semantics of its own.

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

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

States a specific verb (check), resource (dimensions and metrics), and outcome (whether they can be used together in one report, plus the incompatible fields returned). It is clearly distinguished from sibling run_report, which actually executes the 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?

Gives explicit sequencing guidance — 'Use before run_report when mixing scopes, e.g. item-scoped with session-scoped fields' — and names the tool it precedes. It does not state when the check is unnecessary (i.e. homogeneous scopes), so the when-not case is left implied rather than explicit.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds one genuinely useful behavioral note — the catalogue is large, so results should be narrowed with `search` — but says nothing about permissions, pagination, or result shape.

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

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

Two tight sentences: the capability and its scope come first, the `search` advice second. No filler, no restating the title or parameter names at length.

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

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

For a read-only catalogue listing with no output schema, the description tells the agent what comes back (API names, including custom ones) and how to keep the result manageable. It is nearly complete; only the meaning of `kind` values is left unaddressed.

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

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

Schema coverage is 60%, so the description must compensate somewhat. It explains the `search` parameter's purpose and shows a custom-definition naming example ('customEvent:plan_type'), but it never mentions the `kind` enum, `customOnly`, or `includeDescriptions`, leaving part of the parameter surface to the schema alone.

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

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

States a specific verb and resource: 'List the dimension and metric API names available for reports on a property,' and clarifies scope by including the property's custom definitions with a concrete example. It naturally separates itself from the narrower siblings list_custom_dimensions and list_custom_metrics because it covers the whole catalogue.

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 advises using `search` to narrow the large catalogue, which is practical guidance, but it never states when to prefer this tool over list_custom_dimensions/list_custom_metrics or the discovery workflow with run_report. Usage is implied rather than 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=true and openWorldHint=true, so the safety profile is covered and the description does not need to restate it. The description adds genuine value by naming the exact settings returned, but says nothing about auth requirements, whether the entity exists, or error behavior for an unknown property.

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 tightly written sentence, front-loaded with the verb and resource, with the returned fields packed into a colon list. Nothing extraneous.

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 getter with no output schema, enumerating the returned settings in the description is exactly the compensation needed. The only unaddressed element is what happens on failure/unknown property, which is minor here.

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

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

Schema coverage is 100% and the single 'property' parameter already documents the three accepted formats plus the GA4_DEFAULT_PROPERTY fallback. The description adds no parameter-level 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?

States a specific verb and resource ('Get a GA4 property's settings') and enumerates the exact fields returned (time zone, currency, industry category, service level, creation time, parent account), making the scope concrete. It does not explicitly name sibling tools like list_properties, so an agent must infer that this is the single-property fetch rather than a listing.

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 wording — you call this to read one property's configuration — but there is no explicit when-to-use/when-not guidance or pointer to alternatives such as list_properties or get_metadata. Minimum viable, with a clear gap.

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

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

Annotations already declare readOnlyHint and openWorldHint, so safety and scope are covered structurally. The description adds useful context by specifying the result is scoped to the authenticated user's accessible accounts and that each account nests its properties — meaningful beyond the annotations, though no pagination or result-size behavior is mentioned.

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 zero waste. The resource and scope lead, and the routing hint ("Start here...") is placed at the end where it is most actionable.

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 input parameters, no output schema, and safety already covered by annotations, the description supplies exactly what is missing: what the tool returns (accounts plus nested properties with ID and display name) and when to reach for it. Nothing needed to invoke it correctly is absent.

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

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

Zero parameters, so there is nothing to document; baseline for a parameterless tool is 4. The description correctly implies no filtering inputs are needed.

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

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

States a specific verb (List) and resource (Google Analytics accounts the authenticated user can access), and clarifies the returned payload includes GA4 properties with ID and display name. This clearly separates it from siblings like list_properties and get_property.

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

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

"Start here when you don't know the property ID" gives an explicit entry-point condition and implicitly contrasts with get_property for when the ID is known. It doesn't name the alternative tool explicitly or state exclusions, so it falls just short of a 5.

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

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

Annotations already declare readOnlyHint and openWorldHint, so safety is covered. The description adds real behavioral context beyond them: the backing API is versioned v1alpha Admin (a stability caveat), the default response is a summary, and includeDefinitions switches to full filter clauses - useful disclosure about return depth and when detail is needed.

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, zero filler. The core action is front-loaded and the default-vs-full return behavior follows immediately, so the most decision-relevant detail is not buried.

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

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

With no output schema, the description usefully characterizes what comes back (summary vs. full definitions) and notes the API surface. It omits pagination or result-size behavior, but for a read-only two-parameter lister whose annotations cover safety, that is a small omission.

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%: the property parameter is documented in the schema, but includeDefinitions has no description there. The description compensates by explaining that setting includeDefinitions yields full filter clauses rather than the default summary, adding meaning the schema does not supply.

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

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

The description uses a specific verb+resource ("List a property's audiences") and scopes it to a single property, so an agent can instantly tell it apart from list_accounts, list_properties, or the report tools. It stops short of explicitly naming a sibling or contrasting scope, but the resource is unique among the sibling set.

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

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

Usage is implied by the resource name - you call it when you need a property's audience list - but there is no explicit when-to-use, no prerequisites, and no named alternative tools. Since no sibling overlaps on audiences, the lack of routing guidance is a minor gap rather than a harmful one.

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 openWorldHint=true, so the safety profile is covered. The description adds genuinely useful context — the three backing field types (parameter name, display name, scope) and the customEvent:/customUser:/customItem: report reference syntax — but says nothing about pagination or result limits for an open-world listing.

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

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

Two tightly packed sentences, front-loaded with the listing purpose followed by the reference syntax. 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 single-optional-parameter read tool with annotations covering safety and a fully documented schema, the description covers purpose and return content adequately. Only the absence of any guidance on result volume/pagination for an open-world listing keeps it from a 5.

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

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

Schema coverage is 100% and the single property parameter is fully documented in the schema (ID, resource name, display name, default fallback), so the description need not compensate. Baseline 3 applies since the description adds no parameter detail beyond what the schema already provides.

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

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

States a specific verb+resource (list a property's custom dimensions) and even names the returned fields, so an agent knows exactly what it produces. It does not, however, explicitly distinguish itself from the sibling list_custom_metrics, which an agent might confuse it with.

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

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

Usage is only implied: the mention of how custom dimensions are referenced in reports hints this is a discovery step, but there is no explicit when-to-use or when-not-to-use guidance and no alternative named. Adequate minimum viability, not more.

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 openWorldHint=true, covering the safety profile. The description adds the notable fact that there is no output schema but enumerates the return fields (parameter name, display name, unit, scope), which is genuinely useful. It still says nothing about pagination or volume, so a 3 is apt.

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 verb and resource, with the return fields in a compact parenthetical. No filler whatsoever.

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 fields in the description does real work; the single optional parameter is fully documented in the schema and annotations cover safety. Only the absence of pagination/volume expectations keeps it from a 5.

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

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

Single parameter with 100% schema description coverage, including the default-property fallback, so the schema fully carries parameter meaning. The description adds nothing parameter-specific, which is the expected baseline 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?

States a specific verb (List) and resource (custom metrics) and even names the fields returned, so the agent knows exactly what it gets. It does not explicitly differentiate itself from the near-sibling list_custom_dimensions, which keeps it 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?

No when-to-use guidance and no mention of alternatives such as get_metadata or list_custom_dimensions. The purpose is implied by the name, but nothing tells the agent when this is the right tool versus those siblings.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety and scope are covered structurally. The description adds useful output context by naming the fields returned (measurement IDs, website URLs, app IDs), but says nothing about pagination, result limits, empty-property behavior, or auth needs.

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

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

A single front-loaded sentence with zero filler; the resource and the most useful returned fields are stated up front without redundancy.

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

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

For a simple one-optional-parameter read tool with annotations covering the safety profile, the description is nearly sufficient, and it usefully previews the returned fields in place of a missing output schema. Only the absence of any routing guidance to sibling list tools keeps it short of 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?

Only one optional parameter exists and schema coverage is 100%, so the schema fully documents the property formats and the GA4_DEFAULT_PROPERTY default. The description restates the property scoping ('a property's data streams') but adds no syntax or format 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?

States a specific verb (List) and resource (a property's data streams), and even enumerates the stream types (web, Android, iOS) and the key fields returned (measurement IDs like G-XXXX, URLs, app IDs). This distinguishes it from siblings like list_properties or list_accounts by resource, though it never explicitly names those alternatives.

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

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

The description says nothing about when to call this versus sibling list tools, nor about prerequisites (e.g., needing a property ID first) or how it relates to get_property. Usage is only inferable from the resource name.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds that results carry counting method and creation time, but says nothing about volume, pagination, or auth requirements beyond what annotations supply, so it only marginally exceeds the annotation baseline.

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 resource front-loaded and the legacy-name clarification immediately after. Nothing is wasted, though the trailing 'with counting method and creation time' phrasing is slightly vague about what is actually returned.

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

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

For a simple read-only list tool with a fully documented single parameter and no output schema, the description gives enough to call it correctly, and annotations cover the safety profile. Pagination and return-size behavior are the only unaddressed items, which is minor here.

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

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

There is one optional parameter with 100% schema description coverage, including the accepted ID formats and the GA4_DEFAULT_PROPERTY fallback. The description adds no parameter detail, which is the correct baseline when the schema fully documents the input.

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

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

States a specific verb and resource ('List a property's key events') and adds the useful synonym 'formerly called conversions' so an agent can map legacy terminology. It never names a sibling or explains how this differs from list_properties or run_report, so it is clear but undifferentiated.

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

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

The description gives no when-to-use guidance, no prerequisites, and no alternatives to consider. It relies entirely on the tool name to imply 'call this when you need the key events for a property,' which is minimal context.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds meaningful context beyond that: 'accessible' discloses permission-scoped results, and 'flat list' discloses that results are not nested by account. It does not mention pagination, result caps, or return shape, so it is useful but not rich.

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

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

Two sentences with zero filler; the core action and its scoping ('flat list') are front-loaded, followed by the optional filters. Every clause carries information.

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

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

For a simple read-only list with a 2-param, fully documented schema and no output schema, the description covers what an agent needs to select and invoke it. Minor omissions (pagination behavior, whether an empty result is possible) are the only 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 100%, so both parameters (search, account) are already fully documented in the schema, including ID-or-name and case-insensitive semantics. The description restates the same behavior without adding syntax, format, or edge-case detail, 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?

States a specific verb and resource ('List accessible GA4 properties') and adds scope detail ('as a flat list'), which implicitly contrasts with hierarchical or single-property siblings like get_property and list_accounts. However, it never names a sibling explicitly, so the 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?

The optional filters hint at usage context ('optionally filter by account... or by search'), implying this is the browse/discovery tool for properties. But there is no explicit when-to-use guidance versus list_accounts or get_property, and no stated prerequisites (e.g., which permissions surface which 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=true and openWorldHint=true, so the safety profile is covered. The description adds one genuine behavioral rule not present in the schema (each dimension must belong to exactly one pivot), but says nothing about the 3-pivot maximum, error behavior, or that the call hits the live GA4 API.

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

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

Three short sentences, front-loaded with the purpose and immediately followed by the key constraint and a worked example. No filler, though the example crowds out room for the missing routing guidance.

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

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

For a 9-parameter tool with nested objects and no output schema, the description covers only the pivots surface. Filtering, property resolution, date-range defaults and return shape are left entirely to the schema, which is adequate but thin for this complexity.

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

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

Schema coverage is 67%, and the description does add a non-schema rule about pivot fieldNames plus a concrete example with limits. It does not compensate for the uncovered parameters (property, currencyCode, keepEmptyRows, most of the nested pivot object), leaving the baseline level.

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 pair ('Run a pivot (cross-tab) report'), which is precise enough to distinguish it conceptually from run_report. However, it never explicitly names run_report as the alternative, so the 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 guidance on when to choose this over run_report or batch_run_reports, which are the obvious siblings for reporting. The constraint 'Every dimension must appear in exactly one pivot's fieldNames' is a validation rule for the pivots parameter rather than routing guidance.

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

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

Annotations declare readOnlyHint and openWorldHint, so safety is covered. The description adds genuinely useful behavioral context beyond that: the lookback window, the GA4 360 extension to 60 minutes, and the restricted field universe that will cause failures if ignored. It omits return shape and any quota/rate-limit notes, keeping it below a 5.

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

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

Two dense sentences with no filler; the time window is front-loaded and the field constraints follow. The field enumeration is a long run-on list but each item earns its place by preventing invalid-field calls.

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, no-output-schema tool with 9 params including nested filter expressions, the description covers the two things an agent cannot infer: the time window and the constrained field set. Remaining parameter details (minuteRanges defaults, filters, limit cap) are documented in the schema, so nothing critical is missing.

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

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

Schema coverage is 78%, so baseline is 3, but the description adds real value on the two hardest parameters: it enumerates valid realtime dimensions (country, city, deviceCategory, unifiedScreenName, eventName, minutesAgo) and metrics, which have no enums in the schema. It does not clarify limit/minuteRanges/includeTotals interaction, which the schema handles.

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 (report on events) plus a defining scope constraint: events from the last 30 minutes (60 for GA4 360). That window clearly separates it from the batch/historical run_report sibling in spirit, but it never names the sibling or says explicitly 'use run_report for historical data'.

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 30-minute window implicitly tells the agent when this tool applies (near-real-time monitoring), and the listed field set implies constraints. However, there is no explicit when-to-use/when-not-to-use guidance and no named alternative among the many run_report/batch_run_reports/run_pivot_report siblings.

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

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

Annotations already declare this is a safe read (readOnlyHint=true) against an open-world backend, so the safety profile is covered. The description adds genuine behavioral value by specifying the return shape (JSON records keyed by dimension/metric), which matters because there is no output schema. It says nothing about quotas, latency on large pulls, or error behavior for a 12-parameter query tool.

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

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

Three short sentences, with the what and the return format front-loaded and examples last. Every sentence earns its place and there is no filler.

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

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

For a complex 12-parameter query tool with nested filter objects and no output schema, the description covers the essentials: what it does, what it returns, and representative queries. It misses pagination behavior, failure modes, and routing to similar report tools, but nothing critical to making a correct call is absent.

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

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

Schema description coverage is 92%, so the schema already documents limit/offset/metrics/dimensions/dateRanges/filters in detail and the baseline of 3 applies. The description's only parameter-level contribution is an example of using dimension "date" for a daily trend, which adds little beyond what the schema's own examples provide.

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

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

States a specific verb and resource ('Run a Google Analytics 4 report'), names the underlying API call (Data API runReport), and describes the return shape (rows as JSON records keyed by dimension/metric name). It does not explicitly differentiate itself from close siblings like run_realtime_report, run_pivot_report, or batch_run_reports, which is the only thing keeping it out of the top tier.

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

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

The examples ('traffic by channel, top pages, conversions by campaign') imply the kind of query this tool is for, so usage is inferable. But there is no explicit when-to-use/when-not, no routing to run_realtime_report for live data or run_pivot_report for pivots, and no mention of prerequisites such as needing a property or metric names from get_metadata.

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