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

Annotations cover read-only and open-world hints. The description adds meaningful behavioral detail beyond annotations: the 5-report limit, atomic execution, quota-call efficiency, and property_id inference. It does not describe failure modes, but the read-only annotation and output schema reduce the need for that.

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

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

The description is compact and front-loaded with the core purpose. The request-shape explanation is structured as a list, and every sentence provides necessary invocation or selection guidance without filler.

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

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

Given the minimal schema, the description provides enough detail to construct valid batch requests and choose the tool appropriately. It covers request shape, accepted fields, top-level property_id, limits, and the atomic/quota benefit, while an output schema exists for return values.

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

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

Schema description coverage is 0%, and the requests item schema is just an open object. The description fully compensates by explaining that each request is run_report-shaped, listing all accepted parameters, and clarifying that property_id is inferred from the batch rather than repeated per request.

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 ('Run'), a bounded resource ('up to 5 GA4 reports'), and a clear distinguishing mechanism ('in a single round-trip'). It also references ga4_run_report, making the relationship to sibling tools obvious.

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

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

It clearly says when to use it: when the agent needs paired views for the same window and wants them atomically under one quota call. It does not explicitly say 'use ga4_run_report for a single report,' but the batch framing and reference to the single-report tool make the intended division of labor clear.

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?

readOnlyHint already covers safety; the description adds behavioral value by saying it is a cheap pre-flight, by documenting that compatibility_filter returns only working or conflicting fields, and by framing it as a guard against expensive failures. No contradiction.

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?

Every sentence earns its place: purpose first, then the one non-obvious parameter, then usage context. The formatting is scannable and free of filler.

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

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

With readOnlyHint, openWorldHint, and an output schema, the description covers the main invocation context and the compatibility_filter semantics. It is only slightly incomplete on the exact interpretation of the filter/parameter fields for an agent unfamiliar with GA4.

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

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

Schema description coverage is 0%, so the description must compensate. It fully explains compatibility_filter and references metrics/dimensions, but metric_filter, dimension_filter, and property_id are left to be inferred from names and schema, which is only partial compensation.

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?

Opening states a specific verb-resource pair: 'Validate whether a dim/metric combo can be queried together.' The phrase 'Cheap pre-flight' and comparison to run_report make its purpose distinct from the 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?

Explicitly instructs when to use it: 'Use before run_report when composing exploratory queries.' It also gives the alternative (run_report) and the cost-based rationale, so an agent can decide without guessing.

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

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

Beyond the readOnlyHint annotation, the description explains the key behavioral difference between omitting and passing property_id, what kind of fields appear in each case, and the general response shape. This is exactly the information an agent needs to decide how to invoke the tool.

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

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

The description is front-loaded with the core purpose, then gives parameter behavior, response shape, and usage guidance in a compact, efficient way. Every sentence adds value and no fluff is present.

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

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

For a read-only metadata tool with one optional parameter and an output schema, the description covers the purpose, parameter semantics, response entry shape, and when to use it before running reports. Nothing essential 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 input schema provides no description for property_id, and schema coverage is 0%. The description fully compensates by explaining that omitting it returns the universal catalog and passing it includes property-specific custom dimensions and metrics, with concrete examples.

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: 'Fetch the full GA4 dimension + metric catalog for a property.' It clearly differentiates itself from report tools and sibling list tools by emphasizing the full catalog, including custom fields when a property_id is supplied.

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

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

It gives clear, actionable guidance: call this before run_report when uncertain about field names, and explains when to include property_id. It does not explicitly rule out alternatives like ga4_list_custom_dimensions, but the context is clear enough for an agent to select it appropriately.

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, so no safety concerns are hidden. The description adds behavioral transparency by enumerating the returned metadata fields and explicitly accepting both numeric and resource ID formats, which goes beyond the bare 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?

The description is front-loaded with the core purpose, followed by a compact return-field list and the parameter format note. Every sentence adds useful information 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 single-property read tool with a read-only annotation and an available output schema, the description covers the purpose, return content, and accepted input formats. Sibling tools are clearly distinct from this focused metadata operation, so no additional disambiguation is needed.

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 input schema only says property_id is a string, with no description. The tool description compensates by explaining that property_id can be either a numeric string or a full resource name, with concrete examples, giving the agent the needed format guidance.

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 'Full metadata for a single GA4 property' with a clear resource and scope, and lists the exact fields returned. This distinguishes it from sibling list/report tools, which target multiple items or aggregated metrics.

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 clearly implies this is for retrieving metadata about one property, and the singular scope separates it from list tools. However, it does not explicitly state when to prefer this over alternatives or mention any exclusions, leaving usage guidance mostly implicit.

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 mark this as read-only and open-world, but the description goes further by explaining the access boundary (explicit email grant required) and showing the exact response shape. It adds meaningful behavioral context beyond the structured annotations without contradicting them.

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

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

The description is compact, well-organized, and every sentence earns its place: the main purpose, the when-to-call guidance, the access caveat, and the response format. The response example is useful and not padded with irrelevant detail.

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

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

For a zero-parameter discovery tool, the description is fully complete. It explains what the tool returns, how the response is structured, the access model, and how it fits into the workflow. Nothing needed 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 accepts zero parameters, so there is nothing for the description to explain about parameter meaning. The baseline for zero-parameter tools is 4, and the description appropriately focuses instead on the response shape, which is the semantically relevant part 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 states a specific verb ('List') and a specific resource ('every GA4 account and its child properties accessible to this service account'). It clearly positions itself as a discovery tool for finding property_id values, which distinguishes it from the property-scoped sibling list tools like ga4_list_custom_metrics and ga4_list_data_streams.

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

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

Explicitly instructs 'CALL THIS FIRST' and explains the purpose: to discover which property_id to pass into other tools. It also provides a crucial constraint: the service account only sees accounts/properties where its email has been explicitly added. This is strong, actionable usage guidance.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds useful behavioral context by listing the fields returned for each audience and by noting that it 'Uses Admin v1alpha since audiences are still alpha in April 2026,' which helps the agent set expectations about API stability.

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

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

The description is compact and front-loaded with the purpose. The field list is useful, and the note about the alpha Admin API is relevant without bloating the text. Every sentence contributes something meaningful.

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 one simple required parameter, an output schema available, and clear scope, the description is largely complete. Minor gaps like pagination behavior and authentication requirements are not mentioned, but they are less critical for this straightforward read-only 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?

Schema coverage is 0%, but the single required parameter, property_id, is self-describing with title 'Property Id' and is referenced in the description as 'a GA4 property.' The description does not specify the expected format (e.g., numeric property ID vs. full resource name), so it only partially compensates for the missing schema description.

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

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

The description clearly states the operation: 'List audiences defined on a GA4 property.' This distinguishes it from sibling list tools like ga4_list_custom_metrics and ga4_list_data_streams by naming the specific resource. Even without the annotation title, the verb and resource are explicit.

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 concrete guidance on how to use the result, saying to 'Reference audienceId as a dimension in run_report for audience-based breakdowns.' This is a clear usage context, though it does not explicitly list alternatives or when-not-to-use situations, which keeps it just below the top score.

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 the description adds valuable context about what each entry contains and how the parameter_name should be prefixed when used in get_metadata or run_report. It does not mention pagination or limits, but for a read-only list tool this is acceptable.

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

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

The description is compact, front-loaded with the core action, and every sentence adds useful information. The prefix guidance and entry content summary are directly actionable without adding fluff.

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 low-complexity list tool with an output schema, the description covers the main purpose, the contents of the response, and the downstream usage of the returned data. It is nearly complete, though it could briefly mention where property_id comes from or address potential 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 0%, and the description does not meaningfully elaborate on the property_id parameter beyond calling it a GA4 property. The parameter name and title are already in the schema, so the description adds little semantic value for this single required argument.

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

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

The description states a specific verb and resource: 'List custom dimensions configured on a GA4 property.' It is clearly distinct from sibling tools like ga4_list_custom_metrics and ga4_list_key_events by naming the exact entity being listed.

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

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

The description provides clear usage context: it is 'Essential grounding before running reports that reference custom fields.' It does not explicitly exclude alternatives or state when not to use it, but the context is strong enough for an agent to know when this tool is relevant.

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 description does not need to restate safety. It adds useful context by specifying the fields returned for each entry (parameter_name, display_name, measurement_unit, scope, restricted_metric_type), which sets expectations 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?

The description is compact and front-loaded: one clear purpose sentence followed by a concise list of returned fields. There is no fluff or redundant restatement of annotations.

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 list operation with one parameter, read-only annotations, and an output schema, the description covers the essential resource and result structure. It does not discuss pagination or limits, but those are lower-risk for a read-only list tool and are partially covered by the openWorldHint.

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

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

Schema description coverage is 0% and the description never defines property_id or its expected format. The only clue is 'configured on a GA4 property,' which weakly connects the parameter to the tool but does not compensate for the missing schema documentation.

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

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

The description uses a specific verb and resource: 'List custom metrics configured on a GA4 property.' It clearly distinguishes from sibling tools such as ga4_list_custom_dimensions by naming the exact entity being listed.

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 intended use is implied by 'List custom metrics configured on a GA4 property,' but there is no explicit guidance about when to choose this over related siblings like ga4_list_custom_dimensions or ga4_get_metadata. 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 and openWorldHint=true, covering the safety profile. The description adds useful context by scoping the list to web/iOS/Android streams and mentioning creation/update timestamps, but it does not disclose pagination, rate limits, or how many streams are returned. This matches the expected level for a read-only list with 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?

Three tight sentences: the first states the operation, the second gives practical lookup purposes, and the third adds timestamp behavior. There is no filler or redundant restating of the tool name. The most important information 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-only list tool with an output schema and read-only annotations, the description is largely complete. It clearly states scope, common use cases, and available metadata fields. The only notable gaps are property_id format details and explicit pagination/limit behavior, but these are minor given the low complexity and existing annotations/output schema.

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

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

The schema has 0% description coverage for property_id, so the description carries the burden. It does tie the parameter to 'a GA4 property,' adding minimal semantic context beyond the schema's bare 'Property Id' title. However, it does not specify the expected format (e.g., numeric property ID vs. resource path), so the parameter guidance is incomplete but adequate for a single obvious required 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?

The description opens with a specific verb and resource: 'List all data streams (web, iOS, Android) on a GA4 property.' It clearly distinguishes this from sibling list tools by naming the exact resource type and the platform variants. There is no ambiguity about what the tool operates on.

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 concrete use cases: finding Measurement ID, firebase_app_id, hostname, and timestamps. It implies 'use this when you need data stream identifiers or metadata,' which is clear context. It does not explicitly mention exclusions or sibling alternatives, but the sibling tools are all different GA4 resources, so the usage context is sufficient.

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 useful scoping and return-field context, but does not disclose pagination, error behavior, or prerequisites. No contradiction with 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?

Three tight sentences with no filler. The action is front-loaded, return fields are briefly listed, and the practical use case earns its place. Well-structured for an agent to parse quickly.

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

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

For a one-parameter read-only list tool with an output schema, the description covers purpose, returned fields, and the key decision context. The only notable gap is the property_id format, which keeps it from being fully complete.

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

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

Schema description coverage is 0%, so the description bears the burden for explaining property_id. It only implies the parameter is the GA4 property via 'attached to a GA4 property'; it does not clarify the expected format (e.g., numeric ID vs. 'properties/123456789') or any constraints. This is insufficient compensation for the missing schema description.

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

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

States a specific verb ('List'), a concrete resource ('Google Ads links attached to a GA4 property'), and names returned fields. This clearly distinguishes it from sibling list tools such as ga4_list_custom_dimensions or ga4_list_key_events even 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?

Provides a concrete use case: confirm Ads↔GA4 cross-reporting availability before querying Ads-related dimensions. It does not explicitly name alternatives or when-not-to-use conditions, but the intended context is clear enough to guide selection.

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, so the read-only nature is covered. The description adds useful semantic context about conversion-worthy events and how to query conversion metrics, but it does not disclose operational details like pagination, auth requirements, or property access restrictions.

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

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

The description is short, front-loaded, and to the point. The first sentence states the operation and resource, while the additional sentences clarify the semantics and related query usage. Each sentence contributes value, though the final metric-querying hint is slightly tangential to the tool itself.

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 list tool with readOnly and openWorld annotations plus an output schema, the description is mostly complete. It explains what the key events are and how to think about conversion metrics. The main gap is no explicit guidance on choosing this over the many sibling list tools.

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

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

The schema has 0% description coverage and the description does not explain property_id at all. However, the single parameter is self-explanatory and required, so an agent can likely invoke the tool correctly. The description adds no extra meaning beyond the schema's title/type.

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

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

The description clearly states the verb 'List' and the exact resource: key events (formerly conversions) on a GA4 property. It distinguishes this tool from sibling list tools because it uniquely identifies client-marked conversion-worthy events and clarifies the legacy naming.

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

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

The description gives clear context: these are events the client has marked as conversion-worthy, which tells an agent when listing key events is appropriate. It does not explicitly mention alternative tools or when not to use this tool, so it falls short of full 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, so the safety profile is covered. The description adds genuine behavioral context beyond annotations: it warns that the tool uses Admin v1alpha because annotations are still alpha in April 2026, signaling an unstable API surface. It also enumerates the exact returned fields, though that partially overlaps with the existing 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?

The action is front-loaded in the first sentence, followed by three short paragraphs each adding distinct value: the conceptual explanation of annotations, the field list, and the alpha API version caveat. There is no filler, no repetition of annotation metadata, and no redundant content.

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

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

For a single-parameter list operation with an output schema and read-only annotations, the definition is thorough: it explains the niche resource concept, enumerates its fields, and flags the alpha API version. The only gaps are undisclosed behavioral details such as pagination behavior and possible result limits.

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

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

Schema description coverage is 0%, so the description must compensate, but it only provides minimal context ('on a GA4 property'), leaving property_id's format and origin undocumented. The burden is softened because property_id is a single self-explanatory parameter whose name conveys its meaning.

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

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

States a specific action and resource: 'List reporting annotations on a GA4 property.' The explanation of what annotations are (markers for product launches, outages, marketing pushes) gives the agent a concrete model of the resource, which distinguishes this from every sibling list_* tool (custom_metrics, key_events, audiences, etc.), none of which mention annotations.

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

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

The description implies when the tool is useful — 'so downstream analysis can correlate metric swings with known events' — which gives the agent situational context for selecting it. However, it never explicitly states when to use this tool versus the 16 siblings, nor names an alternative for related resources such as key events or custom metrics.

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, and the description adds meaningful behavioral context: data retention of 12 months, default date range of 7 days, and the common dimensions/metrics. This goes beyond the annotations without contradicting them.

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 summary is one clear sentence, followed by compact parameter guidance and use cases. Every line adds value, with no filler or repetition of the schema.

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

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

Moderately complex tool with an output schema present, so return-value details are not required. The description covers the key constraints, defaults, and use cases. Minor gaps like property_id and limit semantics keep it from a perfect score.

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 0% schema description coverage, the description partially compensates by explaining date_ranges format/defaults and the meaningful dimensions/metrics. However, it does not explain the required property_id parameter or the limit parameter, leaving part of the parameter semantics to inference.

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

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

The description opens with a specific verb and resource: 'Audit log of who-read-what on a GA4 property'. It clearly distinguishes this access-report tool from regular reporting siblings like ga4_run_report, and reinforces the purpose with named dimensions and metrics.

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?

Explicit use cases are provided: identifying staff usage, confirming service account activity, and compliance audits. It does not name alternative tools or state when not to use it, but the audit-log framing makes the intended context clear enough.

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

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

Beyond the readOnlyHint annotation, the description discloses that the API is v1alpha, that the surface may change, and that validation errors may require checking the Feb 2026 release notes. This is useful behavioral context beyond the structured annotations; no contradiction.

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

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

The description is front-loaded and the funnel code block earns its place by adding structure the schema lacks. Minor redundancy exists between 'v1alpha, API surface may change' and the later alpha-flag sentence, but overall it is well organized.

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 alpha report tool with nested objects and zero schema descriptions, the description covers the central funnel structure, the intended drop-off use case, and the external reference link. It does not describe the remaining standard parameters, but the output schema exists and the reference URL fills any 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?

With 0% schema description coverage, the description compensates well for the core funnel parameter by documenting its nested structure (is_open_funnel, steps, filter_expression, within_duration_from_prior_step) and clarifying funnel_breakdown and funnel_next_action. It leaves common parameters like date_ranges, limit, and dimension_filter without explicit descriptions, but their titles and types are largely self-explanatory.

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

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

States a specific verb and resource ('Run a GA4 funnel report') and anchors usage with 'Use for drop-off analysis across a sequence of events.' This clearly distinguishes it from sibling reporting tools like ga4_run_report and ga4_run_pivot_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?

Explicitly says when to use it ('Use for drop-off analysis across a sequence of events'), which gives clear context against the sibling report tools. It does not explicitly name alternatives or state when not to use it, so it falls short of a 5.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds value beyond annotations by explaining the pivot spec structure (field_names, limit, offset, order_bys, metric_aggregations) and noting that order_bys shares shape with run_report, which is useful behavioral context for constructing valid calls. No contradiction with annotations exists.

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

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

The description is compact and front-loaded: purpose in the first sentence, a tight structured list of the pivot sub-fields, and a memorable usage example. Every sentence earns its place, and the dense bullet-style format packs meaningful detail without padding.

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

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

Given an output schema exists (so return values need no explanation) and annotations carry the safety profile, the description needn't cover much more than the pivot mechanics, which it does well. Minor gaps remain: it doesn't state constraints like maximum pivot count or how pivots interact with the top-level dimensions/metrics parameters, but these are edge details for a moderately complex 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 0% schema description coverage, the description must compensate, but it only explains the pivots parameter in detail. The other eight parameters (metrics, dimensions, date_ranges, filters, currency_code, keep_empty_rows) are left entirely underexplained, relying on GA4 API conventions. The pivots explanation is strong and the run_report order_bys cross-reference helps, but the compensation is partial across the full parameter set.

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

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

The description states a specific verb and resource ('Run a GA4 pivot report') and immediately distinguishes it from sibling report tools by introducing the 2D pivot concept. The concrete example 'rows=date, columns=device, values=sessions' makes the tool's unique function unmistakable, separating it from ga4_run_report, ga4_run_realtime_report, and ga4_run_funnel_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?

The description gives an explicit usage trigger: 'Use when you want a 2D view'. This clearly implies the standard report tools are for non-pivoted, one-dimensional tables. It doesn't explicitly name alternatives or exclusion conditions, but the 'use when' framing provides enough routing guidance for an agent to select this tool over its siblings.

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

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

The description discloses important behavioral traits beyond the annotations, including the 30-minute window, the unsupported 'date' and 'totalRevenue' fields, and the max-2 minute_ranges constraint. The readOnlyHint annotation is consistent with the described read-only report behavior, with no contradiction.

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 well-structured and front-loaded: the main behavior, the critical realtime catalog warning, the minute_ranges detail, and the sibling alternative each have a clear purpose. No sentence is wasted, and important constraints are highlighted.

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

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

The description covers the key operational constraints, common fields, range limits, and the alternative tool, and an output schema exists so return-value documentation is not required. However, advanced parameters like filter expressions and order_bys remain underspecified for agents needing those features.

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

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

Schema description coverage is 0%, so the description must compensate. It usefully explains minute_ranges semantics and gives common dimension/metric examples, but it leaves several parameters unguided, such as limit, order_bys, metric_aggregations, dimension_filter, and metric_filter. This is partial compensation, not complete.

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

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

The description clearly states the tool runs a GA4 real-time report covering the last 30 minutes only. It distinguishes itself from the historical ga4_run_report sibling by explicitly saying realtime uses a separate catalog and that historical/batch reports should go elsewhere.

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

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

The description provides explicit usage boundaries: realtime only, last 30 minutes, separate dimension/metric catalog, and common dimension/metric examples. It also names the alternative tool (ga4_run_report) for historical or batch reports, making the selection decision unambiguous.

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?

Even though readOnlyHint=true already signals safety, the description adds rich behavioral context: it cautions about sampling (>10M events), data loss from high-cardinality dimensions, thresholding, and schema restrictions, and notes that propertyQuota is always included for self-throttling. This goes well 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?

The description is long, but justifiably so for a 14-parameter tool with no schema descriptions. It is well-structured with clear 'Args' and 'Gotchas' sections, front-loading the core purpose. A few minor redundancies (e.g., repeating filter shapes) keep it from a 5.

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

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

Given that the tool has an output schema and readOnlyHint/openWorldHint annotations, the description covers all pre-call essentials: parameter formats, constraints (hard cap, up to 4 date ranges, required property_id), pagination, and critical response metadata signals. Nothing needed 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?

Schema description coverage is 0%, so the description carries full responsibility for parameter meaning. It documents every one of the 14 parameters with concrete formats, examples, prefixes for custom dimensions, accepted date expressions, filter shape examples, default limits, and advanced spec references. This fully compensates for the empty schema descriptions.

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

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

The description opens with 'Run a GA4 standard report. The workhorse tool,' which gives a clear verb and resource. The term 'standard' implicitly distinguishes this from the many sibling run_* tools (pivot, realtime, funnel, access, batch), but it doesn't explicitly name any alternative the way a 5 would.

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?

Calling it 'the workhorse tool' implies it is the default for standard GA4 reporting, but the description gives no explicit when-to-use vs. when-not-to-use guidance and never names alternatives such as ga4_run_pivot_report or ga4_run_realtime_report. An agent must infer usage boundaries from the sibling tool names alone.

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