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

With no annotations, the description carries the full burden, and it does disclose the key behavioral fact that results are limited to what the service account can read (a permission boundary). However, it never states that it is a read-only, side-effect-free operation, and says nothing about pagination, rate limits, or result volume.

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

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

A single sentence with no filler, front-loading the resource and scoping constraint before the returned identifier detail. Nothing extraneous and nothing 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?

There is no output schema, so the description must sketch the return; it does so at a high level (accounts, properties, property IDs). It stops short of clarifying the account→property nesting or whether results are paginated, which an agent would need to parse the response confidently.

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

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

The tool takes zero parameters, so there are no parameter semantics to document and the baseline of 4 applies. The description correctly adds no spurious parameter 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?

Specific verb ("List") plus specific resource (Google Analytics accounts and properties) and a scope qualifier ("the service account can read"), plus the notable payload detail "with property IDs". It is distinguishable from siblings like get_property_details or run_report by being the account/property discovery call, though no sibling is named explicitly.

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

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

Usage is only implied: because it returns property IDs, an agent can infer this is the discovery step before run_report or get_property_details. There is no explicit statement of when to call it, when not to, or which sibling to use instead.

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

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

No annotations are provided, so the description carries the full burden. 'Return' implies a read-only lookup and it discloses the returned content (dimensions, metrics, apiName), but it says nothing about authentication/permission needs, empty-result behavior, or possible errors for an invalid 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?

A single sentence with no filler, and the core resource is front-loaded before the apiName purpose. Nothing could be trimmed without losing 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 tool with one fully documented parameter this is close to adequate, and the mention of apiName hints at the payload. With no output schema, however, the description should at least sketch the shape of the returned dimensions/metrics rather than leaving the agent to guess.

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

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

Schema description coverage is 100% and the single property_id parameter is fully documented in the schema, including how to find it. The description adds no parameter-level meaning beyond that, so the baseline of 3 applies.

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

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

States a specific verb ('Return') and resource ('the property's custom dimensions and metrics') with the added detail that it supplies the apiName for reports. That distinguishes it from siblings like get_property_details or get_account_summaries, though it never names a sibling explicitly.

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

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

The phrase 'with the apiName to use in reports' implies the tool is a lookup used to build report requests, which is useful inferred context. There is no explicit when-to-use statement, no exclusion of alternatives, and no guidance on what to do if the property has no custom dimensions.

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

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

With no annotations, the description must carry behavioral disclosure. It implicitly signals a read-only lookup and usefully enumerates the fields returned, which is real behavioral value. However, it says nothing about error behavior for an invalid/missing property, permission requirements, or rate limits.

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

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

A single, front-loaded sentence with the verb and the returned-field list; every word earns its place with no preamble 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?

No output schema exists, so the description usefully compensates by listing the returned fields. Combined with a fully documented single parameter, this is nearly complete for a simple read tool; only edge-case behavior (missing property, auth) is 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 100% and there is only one parameter, whose accepted formats and discovery path are fully documented in the schema. The description adds no additional meaning about property_id, 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+resource ('Return details about a property') and enumerates the returned fields (time zone, currency, industry, service level, create time), so the agent knows exactly what this yields. It doesn't explicitly differentiate itself from siblings like get_account_summaries, but those operate on a different resource, so confusion risk is low.

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

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

No when-to-use guidance, no prerequisites, and no alternatives named. The useful routing hint ('Use get_account_summaries to find it') lives in the schema's property_id description, not in the tool description, so the description itself offers no selection help.

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

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

No annotations are supplied, so the description carries the full behavioral burden, yet it discloses nothing beyond the core action. It does not state auth/permission requirements, whether the result is paginated, how links are ordered, or what happens for a property with no linked accounts.

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

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

A single front-loaded sentence with no filler, which suits a simple one-parameter list tool. It is efficient, though perhaps too terse given the absence of annotations and output schema.

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

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

For a simple listing tool with full schema coverage this is minimally adequate, but with no annotations and no output schema it leaves an agent without any behavioral context (safety, pagination, or return shape). The gaps are real but modest given the tool's low complexity.

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

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

Schema description coverage is 100% and the property_id field is already well documented (including a pointer to get_account_summaries). The description adds no additional meaning about the parameter, so the baseline of 3 applies.

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

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

States a specific verb (List) and a well-scoped resource (Google Ads accounts linked to a property), which an agent can distinguish from the get_* and run_* siblings. It does not explicitly name or differentiate from any sibling, keeping 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?

The description contains no when-to-use, when-not-to-use, or alternative guidance. It never states that a property_id is required or where to obtain one (the schema does that), nor distinguishes this from other listing tools. Usage is only faintly implied by the word 'linked to a property'.

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

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

With no annotations, the description carries the full burden. 'List' plus the note-like nature of annotations conveys that this is a non-mutating read, but it says nothing about permissions, rate limits, result volume, or ordering. It adds useful domain context (what annotations contain) without covering the operational traits.

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

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

A single sentence that front-loads the verb and resource, then spends the remainder clarifying the domain term 'annotation'. Every clause earns its place and nothing is repeated.

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

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

There is no output schema and no annotations, so the description is the only source of behavioral information. It conveys the concept of annotations but not the shape of the response (fields, ordering, pagination), which for a list tool leaves a gap despite the simple one-parameter surface.

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

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

Schema description coverage is 100% and the single property_id parameter is thoroughly documented in the schema, including the accepted formats and how to discover it via get_account_summaries. The description adds no parameter detail, so the baseline of 3 applies.

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

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

The description gives a specific verb ('List') and a precisely scoped resource ('a property's annotations'), then explains what an annotation is in GA4. No sibling tool touches annotations, so an agent can tell this apart from the report/get siblings without opening a schema.

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

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

It explains what annotations are and when they typically exist ('for releases, campaign launches or changes'), but never states when to call this tool, what prerequisite (a valid property_id) is needed, or how it relates to alternatives. That context is about the data, not about tool 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?

No annotations are provided, so the description carries the full burden. It discloses the conversion/dimension restriction and links to quota documentation plus the max-row/pagination limit, which is useful. However it never states this is a read-only report (no mutation side effects), nor auth/permission requirements for the property, leaving the safety profile implicit.

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

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

Front-loads purpose and the run_report alternative well, but the long 'Notes: The API applies dimension_filter and metric_filter independently...' block is duplicated verbatim under both filter sections, adding significant redundancy. The reference-example format is otherwise scannable but bloats 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 complex 12-parameter tool with nested filters and no output schema, the description supplies the allowed dimensions/metrics enumerations, required conversion_spec, and example payloads for every structured param. An agent has enough to call it correctly; only return-value shape is unstated, which is acceptable for a report tool.

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

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

Schema coverage is 75%, but the description goes well beyond it: worked examples for date_ranges (relative dates, multiple ranges), dimension_filter and metric_filter (all filter shapes including AND/OR/NOT/empty), order_bys, and a required conversion_spec format with empty-list semantics. This meaningfully reduces invocation errors.

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 ('Runs a Google Analytics Data API conversions report') and explicitly distinguishes itself from the sibling run_report, listing the exact metrics and dimensions that are conversions-only. An agent can select it over run_report without opening either schema.

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

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

Provides an explicit 'USE THIS TOOL INSTEAD OF run_report WHEN' list with four concrete triggering conditions (conversions, ROAS, attribution model, ad metrics). This is a textbook when-to-use/when-to-prefer-alternative block naming the sibling.

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

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

With no annotations, the description carries the full behavioral burden. It discloses that results are flattened to one object per row and that multiple date_ranges add a dateRange column, but it does not describe permissions, quota behavior, error conditions, or whether the operation is read-only.

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

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

The description is well organized with purpose and return values front-loaded, followed by parameter-specific sections. It is long and includes multiple verbose examples, but for a complex nested funnel_steps schema this length is largely justified.

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 complex nested input, lack of annotations, and absence of an output schema, the description provides strong invocation guidance and partial return-value context. It still omits deeper behavioral details such as auth requirements, quota limits, and error handling.

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

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

Schema description coverage is only 43%, so the description must compensate and does so extensively. It provides detailed examples for funnel_steps, funnel_breakdown, funnel_next_action, segments, and date_ranges, including shorthand event steps, filter_expression shapes, AND/OR groups, and relative date syntax.

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: 'Runs a Google Analytics Data API funnel report.' It clearly identifies the report type and mentions the returned artifacts, funnel_table and funnel_visualization, but it does not explicitly distinguish this tool from sibling tools such as run_report or run_conversions_report.

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

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

Usage is implied by the funnel-specific examples and configuration sections, but the description never states when to choose this tool over run_report or run_conversions_report. There are no explicit when-to-use or when-not-to-use rules.

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

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

With no annotations, the description carries the full burden and does substantial work: it discloses the 30-minute window, mutual exclusivity of custom metrics, the independence of dimension_filter and metric_filter, and quota implications with a link. It stops short of describing response shape or pagination behavior, which matters for a tool with no output schema.

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

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

Headings front-load the important material and the examples are genuinely useful, but the Notes block under dimension_filter is reproduced verbatim under metric_filter, wasting roughly a third of the text. An agent must read past duplicated prose to reach order_bys.

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, nested-object tool with no output schema and no annotations, the description covers the hard parts (filter semantics, ordering rules, realtime restrictions). Remaining gaps are pagination and response format, both of which the schema only partially covers.

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

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

Schema coverage is 78%, yet the description adds real meaning for the four complex parameters (dimensions, metrics, dimension_filter, metric_filter, order_bys) via five worked examples each and the constraint that order_bys fields must also appear in dimensions/metrics. It adds nothing for limit, offset, or return_property_quota, which the schema already documents.

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 ('Runs a Google Analytics Data API realtime report') plus the defining scope ('roughly the last 30 minutes'), which cleanly separates it from the sibling run_report (historical). An agent can pick it without opening the schema.

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

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

Gives clear operational constraints: realtime dimensions only (plus 'customUser:' custom dimensions from get_custom_dimensions_and_metrics), realtime metrics only, and no custom metrics. It also explains how to handle impossible filter combinations and which workaround to prefer. It never explicitly contrasts with run_report, so the alternative-selection guidance is implied rather than stated.

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

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

With no annotations, the description carries the full burden and does well: it discloses the flattened row shape ('one object per row keyed by dimension and metric name, metrics as numbers'), the multi-date-range behavior (adds a 'dateRange' column), the independent-application quirk of the two filters, and a quota warning with a link. It does not state auth/permission requirements explicitly, though the read-only nature is strongly implied by 'runs a report'.

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

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

Front-loaded with a one-line purpose and organized under headers, which is good. However, the identical multi-line 'Notes:' block about independent dimension_filter/metric_filter application is duplicated verbatim under both sections, wasting roughly ten lines, and the sheer length is disproportionate for routine 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 an 11-parameter tool with no output schema, the description covers return shape, the complex filter/ordering/date semantics, quota implications, and pagination (via the schema's limit/offset). What is missing is comparatively minor: auth/permission expectations and any note on maximum result scaling beyond the quota link.

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

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

Schema coverage is already 82%, so the baseline would be 3, but the description goes well beyond the schema with concrete worked examples for the four hardest parameters (date_ranges, dimension_filter, metric_filter, order_bys), including relative dates, AND/OR/NOT groups, and numeric/between filters. It also warns that order_bys fields must also appear in dimensions/metrics.

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: 'Runs a Google Analytics Data API report', with illustrative metrics (sessions, users, page views, events, revenue). It does not distinguish itself from the siblings run_realtime_report, run_funnel_report, or run_conversions_report, so an agent must infer that this is the general-purpose reporting tool.

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

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

There is no explicit routing guidance against the sibling report tools, only an implied 'general report' role. The description does give real operational guidance for a tricky case (that dimension_filter and metric_filter apply independently, with two workarounds and a preference for option (a) to conserve quota), which raises it above a bare 2.

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