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

With no annotations supplied, the description carries the full burden and does meaningful work: it states the required API enablement (analyticsadmin.googleapis.com on the quota project), the minimum role, and the failure behavior ('the error explains how to fix it'). That tells an agent what auth and setup preconditions to expect. It does not cover pagination, volume limits, or latency for large account sets, which keeps 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?

The purpose and use case are front-loaded, which is good, but the prerequisite sentence contains an untranslated Spanish clause ('cualquier rol en al menos una cuenta de GA4') that breaks consistency and may confuse an agent parsing requirements. The final sentence packs two distinct ideas (error guidance and the ga4_check_access alternative) together rather than separating them.

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, but the description states what comes back: property ids and names. Combined with stated API prerequisites, role requirements, error behavior, and an alternative tool, an agent has enough to call this correctly and to recover from an access failure. Missing details are minor for a simple enumeration tool.

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

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

Schema description coverage is 100%, so the single optional 'property' parameter is already documented in the schema. The description adds no meaning about that parameter and in fact creates mild tension: it frames the call as enumerating all accessible properties, while the schema defaults to a saved property. Baseline 3 is appropriate since the schema does the work.

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 every Google Analytics account and property these credentials can access, with property ids and names.' It makes the scope (accounts plus properties reachable by the current credentials) concrete, which separates it from report-oriented siblings. It stops short of naming the closest alternative (ga4_list_properties) in the description itself, so it is clear but not fully differentiated.

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 provides an explicit use case ('Useful to find the property id to configure') and points to an alternative, ga4_check_access, noting that it 'checks everything at once.' That gives an agent a real routing decision. What is missing is an explicit negative case — e.g. when not to call this versus ga4_list_properties or ga4_property_details.

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 disclose the two real blockers: the Analytics Data API must be enabled on the quota project and the caller needs Viewer access on the GA4 property. It also promises a self-explanatory access error and points to ga4_check_access. It does not state that the call is read-only, how rows are ordered or truncated by limit, or what the response looks like 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?

Three tight clauses with the payload description front-loaded, then prerequisites, then the failure path. No filler. Minor deduction for the mid-sentence language switch to Spanish ("Lector (Viewer) en la propiedad de GA4") which slightly breaks readability in an otherwise English definition.

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

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

For a 5-parameter reporting tool with no output schema, the definition covers purpose, prerequisites, error recovery and the metric set, which is most of what an agent needs. The remaining gaps are row-limiting behavior and the shape of the returned breakdown, neither of which is documented here or in an 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?

Schema description coverage is 80%, so the baseline is 3 and the schema already documents dates, property and the level enum. The description echoes source/medium/campaign but omits the fourth enum value (channel) and adds nothing about limit or the level-to-column mapping, so it contributes little meaning beyond the schema. It also does not explain the "first-user" vs session-level distinction that the level choice implies.

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?

"Where new users come from: first-user source, medium and campaign, with new users, active users and key events" names the resource (traffic acquisition) and the exact dimensions/metrics returned, so an agent can tell it apart from ga4_run_report or ga4_active_users. It is descriptive rather than verb-led, but the scope is unambiguous.

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

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

It states the case this serves (new-user acquisition breakdown) and routes the agent elsewhere for setup problems by naming ga4_check_access as the one-shot health check. Prerequisite conditions are given explicitly. It stops short of naming sibling alternatives for overlapping report needs such as ga4_run_report or ga4_compare_periods.

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 reasonably well: it discloses prerequisites (Data API enabled on the quota project, Viewer role on the GA4 property) and error behavior (access failures explain the fix). It stops short of stating that this is a read-only operation, rate limits, row caps, or whether results are cached.

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

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

Front-loaded with the metric output then prerequisites, with no filler. Minor deductions for the mixed-language fragment 'Lector (Viewer) en la propiedad de GA4' mid-sentence and for cramming the access-failure guidance into the same dense block.

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

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

For a four-parameter, no-output-schema, no-annotation tool, the description covers what is returned (DAU/WAU/MAU and stickiness, optionally per dimension), the access prerequisites, and the failure remedy. An agent could invoke it correctly from this plus the schema; only output shape details are inferred.

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 all four parameters are already documented, including the relative date formats and the property defaulting to ga4_list_properties. The description adds only the notion that split_by accepts an extra dimension such as platform, which the schema already implies with the same example. Baseline 3 is appropriate.

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

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

The description names a specific verb (compute daily active users) plus the exact metric set (DAU, WAU, MAU, stickiness ratios) and the optional dimension split. That granularity lets an agent distinguish it from the general-purpose siblings like ga4_run_report or ga4_batch_reports 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 gives clear context on when this applies (active-user metrics, optionally split by platform or another dimension) and names the recovery path: if it fails for access, use ga4_check_access. What's missing is explicit routing against overlapping report tools (ga4_run_report, ga4_compare_periods) for agents deciding between them.

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 it does disclose useful behavior: the required API enablement, the permission level, and that access failures return a self-explanatory error. It does not state that the operation is read-only, whether pagination applies, or what volume of audiences to expect. The prerequisite/error disclosure is substantive but the operational profile is incomplete.

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

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

The purpose is front-loaded and the sentence count is small. The prerequisite block is a dense run-on mixing English and Spanish ("Lector (Viewer) en la propiedad de GA4"), which costs clarity at exactly the point the agent needs precision. It is compact but not cleanly structured.

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

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

This is a one-parameter, no-annotation tool, and the description covers the resource returned, its scope, the access prerequisites, and the failure-recovery path. Since no output schema exists, a fuller sketch of the returned fields would help, but the essentials for calling it correctly are present.

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 parameter already documents itself, including the default-to-default-property behavior and a pointer to ga4_list_properties. The description adds no syntax or format detail beyond that. Baseline 3 is appropriate where the schema does the work.

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?

"Audiences defined in the property, with their membership rules" names the specific resource and what comes back with it, which separates it from ga4_custom_dimensions or ga4_key_events. However, it is a noun phrase with no verb, so the agent must infer that this is a read/list operation rather than a create or configure operation. Purpose is identifiable but not stated outright.

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 lists prerequisites (Admin API enabled on the quota project, Viewer role on the GA4 property) and routes the agent to ga4_check_access when it wants everything checked at once, which is genuine alternative-routing guidance. It never says when to reach for this tool versus siblings like ga4_property_details, and it gives no exclusion conditions. Usage is implied through prerequisites 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 largely meets it: it discloses the hard cap of 5 requests, the required Google Cloud API enablement, the GA4 property permission level, and the failure behavior (access errors are self-explanatory). It omits quota/rate-limit behavior and says nothing about what the call returns, which is the remaining gap.

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

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

Three sentences, front-loaded with the capability before the prerequisites and the fallback tool, with no filler. Minor noise: the mixed-language 'Lector (Viewer) en la propiedad de GA4' reads as an untranslated fragment rather than deliberate terminology.

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 two-parameter wrapper with no output schema and no annotations, the description covers invocation shape, preconditions, batch limit, and failure handling. What is missing is any statement about the return value (presumably an ordered array of report results matching the input requests), which an agent would need to chain on.

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

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

Schema coverage is 100%, so baseline would be 3, but the description adds real value by naming the exact request shape (RunReportRequest with dateRanges, dimensions, metrics, dimensionFilter, orderBys, limit) that the opaque 'requests' items object in the schema does not enumerate. The property parameter is left to the schema, which is acceptable at full coverage.

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

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

The description opens with a specific verb, resource, and scope: 'Run up to 5 reports in one call (Data API batchRunReports).' The batch cardinality plus the named underlying API call immediately distinguishes it from the single-report sibling ga4_run_report without requiring the schema to be opened.

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

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

It supplies the preconditions for use (Data API enabled on the quota project, Viewer role on the GA4 property) and routes the agent to ga4_check_access when access is in question. It stops short of explicitly stating when to prefer this over ga4_run_report or ga4_pivot_report, so there are no real exclusions.

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

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

With no annotations, the description carries the full burden. It usefully discloses the required Admin API enablement, Viewer access on the GA4 property, and that access errors explain how to fix the issue, but it does not explicitly state that the operation is read-only or describe response/pagination behavior.

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

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

The description is front-loaded and appropriately short, covering purpose, context, prerequisites, and fallback. The mixed-language phrase 'Lector (Viewer) en la propiedad de GA4' slightly reduces clarity, but overall it is efficient.

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

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

For a simple one-parameter read tool with no output schema, this covers purpose, access prerequisites, failure behavior, and the main exported fields. It could be more complete by explicitly stating read-only semantics and the exact response structure, but it is largely sufficient.

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 the property parameter is already fully documented. The description mentions 'of the property' but adds no syntax, formatting, or selection guidance beyond what the schema 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?

The description states a specific resource and scope: BigQuery export links for a GA4 property, including target project, daily or streaming export type, and which streams are exported. It also distinguishes this from the sibling ga4_firebase_links by naming BigQuery specifically.

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 prerequisites and an alternative path for access problems by naming ga4_check_access. However, it does not explicitly say when not to use this tool or contrast it with related property/stream tools beyond the implicit scope.

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 at all, the description carries the full burden and does meaningful work: it names the API that must be enabled on the quota project, the required GA4 role (Editor/Admin), and the OAuth scope analytics.edit, plus how failures surface. It omits result limits, pagination, and retention window of the change log, which keeps it out of the top band.

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

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

The purpose is front-loaded in the first clause and the prerequisites follow in a compact second sentence; nothing is wasted. However, the phrase "Editor o Administrador en la cuenta de GA4" mixes Spanish into an otherwise English description, which slightly hurts scannability.

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 two-parameter read tool with no output schema, the definition covers what is returned conceptually (who changed what and when), the prerequisites, and the failure path. The main remaining gap is that it does not indicate volume or time-bound behavior of the change log, which an agent would want before calling it.

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

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

Schema description coverage is 100%, so both parameters (days with its 1-365 bounds and default of 30, property pointing at ga4_list_properties) are already documented in the schema. The description adds nothing about how many days are useful or how property resolution behaves, 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?

"Recent configuration changes in the property: who changed what and when" states a specific resource (change history / audit events) and names the backing API call (searchChangeHistoryEvents), which cleanly separates it from the reporting siblings like ga4_run_report or ga4_event_counts. It stops short of naming a sibling it is explicitly not, so it falls just below the top band.

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 a clear context of use (auditing who changed configuration) and routes the agent elsewhere for the related prerequisite: "ga4_check_access checks everything at once," plus "If it fails for access, the error explains how to fix it." No explicit when-not-to-use case is given, so it is clear but not fully exclusionary.

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 burden, and it does disclose meaningful behavior: it reports which tools work, which are blocked, and the exact remediation steps, and it names the analytics.edit scope dependency. It does not say whether the check performs live network calls, how long it takes, or whether it can be safely repeated, which keeps it below 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?

Three sentences, front-loaded with what is checked, then what is returned, then when to call it. No filler, and the parenthetical API and tool lists are compact and informative rather than 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?

With no output schema and no annotations, the description must explain return values, and it does at a summary level ('which tools work, which are blocked, and the exact steps to unblock each'). It does not describe the response shape or what a partially-blocked result looks like, which leaves a small gap for a diagnostic tool whose output drives follow-up decisions.

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 'defaults to the default property' behavior. The description only echoes 'for a saved property', adding no new meaning such as accepted formats or what happens when the name is unknown, 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 uses a specific verb ('Check') and enumerates exactly what is inspected: Data API, Admin API, Firebase Management API reachability plus analytics.edit write scope for a saved property. That is far more than a restatement of the name. It does not explicitly distinguish itself from the near-sibling ga4_test_connection or ga4_check_compatibility, so an agent must infer the boundary.

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

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

It gives concrete triggering conditions: call before Admin tools (custom dimensions, streams, key events) and when another tool fails for access. That is clear when-to-use guidance. It stops short of naming the alternative diagnostic sibling (ga4_test_connection) or stating when this check is unnecessary, so it is not a full 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?

With no annotations, the description carries the burden and does reasonably well: it states the return semantics (each field marked COMPATIBLE or INCOMPATIBLE plus what else fits), the prerequisites (Data API enabled on the quota project, Viewer access on the GA4 property), and that access failures return a self-explanatory fix message. It does not cover rate limits or how large selections are handled.

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

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

Three sentences, front-loaded with the core purpose before prerequisites and error behavior. One sentence mixes languages ("Lector (Viewer) en la propiedad de GA4"), an inconsistency that slightly hurts polish but not comprehension.

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 the description compensates by explaining the COMPATIBLE/INCOMPATIBLE result shape and the enrichment list. Combined with prerequisites and error guidance, an agent has enough to call it correctly; only edge-case behavior (empty selection, large lists) 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 description coverage is 100%, so all four parameters are already documented, and the description's 'pass the ones you plan to use' adds only intent framing. It does not clarify why 'only_compatible' exists or what 'what else fits' means relative to the empty-array defaults, so baseline 3 applies.

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

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

The opening sentence gives a specific verb and resource: validating whether dimensions and metrics can be combined in a single report. This clearly separates it from report-execution siblings like ga4_run_report and metadata siblings like ga4_metadata, though it never names those alternatives 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?

"Pass the ones you plan to use" tells the agent how to invoke it, and it points to ga4_check_access for a broader one-shot health check. It lacks an explicit 'do not use this for X' exclusion, so it falls short of a full routing statement.

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

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

With no annotations provided, the description carries the full burden and discloses real prerequisites: the Google Analytics Data API must be enabled on the quota project and the caller needs Viewer access on the GA4 property. It also explains the failure mode (access errors are self-explanatory) and points to ga4_check_access, though it says nothing about quota/rate-limit cost or pagination for a 12x12 cohort grid.

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?

Content is front-loaded: what the report is comes first, then prerequisites, then failure handling. It is compact and every clause is functional, though the mid-sentence language switch ('Lector (Viewer) en la propiedad de GA4') and the dense third sentence slightly reduce readability.

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 report tool with no output schema and adequate schema coverage, the definition supplies the missing pieces: the shape of the returned data, the data-model assumptions (first-visit cohorts), the access prerequisites, and the recovery path. An agent can decide to call it and interpret the result without further information.

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 80% (cohorts, periods, start_date, property all documented), so the baseline is 3. The description adds genuine meaning on top: it explains what a cohort and a following period actually represent in the output and ties granularity to weekly/monthly cohort construction, which the enum alone does not convey.

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 opening sentence names a specific verb and resource (retention of first-time users) and describes the exact report shape: one cohort per week/month, active users per following period, and share retained. No sibling tool covers cohort retention, so an agent can distinguish it immediately from ga4_run_report, ga4_funnel, or ga4_active_users.

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

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

Usage context is clear from 'weekly or monthly retention of first-time users', and the definition routes the agent to ga4_check_access for a one-shot access check when this fails. It does not explicitly say when to prefer this over ga4_run_report or ga4_compare_periods, but the scope is narrow enough that ambiguity is low.

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 usefully discloses the required API enablement, GA4 Viewer permission, row-level comparison behavior, and access-error guidance. It does not cover operational details such as sampling, sorting, or how relative change handles a zero previous-period value.

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 core operation and output are front-loaded, followed by concise use cases, prerequisites, and troubleshooting guidance. Each sentence serves a distinct purpose, although the brief language switch in the permission requirement is slightly inconsistent.

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?

Together with the rich input schema, the description provides enough information to select and invoke this comparatively complex tool, including its output concept and access prerequisites. Because there is no output schema, details such as result structure, row ordering, and the relative-change calculation would make it more 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 coverage is already high, but the description adds meaning by explaining how the four date parameters form current and previous periods and how the selected metrics appear in the comparison. It does not add date-syntax guidance for the parameters whose schema descriptions omit it.

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 that the tool compares GA4 metrics across two date ranges and returns current-period, previous-period, and relative-change values for each row. This comparative output distinguishes it from ordinary reporting siblings such as ga4_run_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?

It gives concrete use cases—week-over-week and month-over-month analysis—and directs agents to ga4_check_access for comprehensive access diagnosis. It does not explicitly say when a standard report or another GA4 sibling would be preferable.

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 much of it: it discloses that the connection is validated before saving unless skip_test is true, that re-saving an existing name overwrites it, and lists the exact GCP API and IAM roles required (including an extra Firebase Viewer role when resolving via firebase_project). It never explicitly says the operation mutates persisted state or describes the failure mode when overwriting an in-use name.

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

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

Front-loaded with purpose, then inputs, then requirements, then error routing — every sentence carries operational information. The one flaw is the mid-description language switch ("Lector (Viewer) en la propiedad de GA4; con firebase_project, además Firebase Viewer..."), which is inconsistent with the rest and mildly harder to parse.

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 10-parameter, annotation-free mutation tool with no output schema, the description covers the prerequisites, validation behavior, overwrite semantics, and troubleshooting path an agent needs before calling it. It omits what a successful save returns (confirmation, resolved property id) and gives no hint about the defaulting behavior make_default enables beyond the schema text.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds the either/or relationship between property_id and firebase_project plus the fact that the Firebase path performs a lookup, neither of which the schema encodes. It does not add meaning for quota_project, make_default, or key_file beyond what the schema already says.

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?

"Save a GA4 property so every other tool can use it by name, and remember it across sessions" gives a specific verb (save/register), resource (GA4 property), and the resulting effect (named, persisted reference). That clearly separates it from ga4_list_properties, ga4_set_default, and ga4_remove_property, which do not persist a new configuration.

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

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

It states the two mutually exclusive inputs (property_id or firebase_project), how to pick an auth_type, and routes access failures to ga4_check_access and ga4_test_connection. It stops short of explicit negative guidance such as when to prefer ga4_set_default over re-saving with make_default.

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 has to carry the full behavioral burden and does much of it: property-wide impact ("changes the property for everyone"), no historical backfill ("Data is only available from the day it is registered"), plus required role and OAuth scope. It omits whether the registration can be undone, what is returned on success, and any quota/per-dimension limit.

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 first three sentences are front-loaded and earn their place, but the requirements are then stated twice in nearly identical form ("Needs the Editor role and the analytics.edit scope" followed by "Requires: ... Editor en la propiedad de GA4; OAuth scope analytics.edit"), and the untranslated Spanish fragment makes the text inconsistent.

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 mutation tool with no annotations and no output schema, the definition covers the critical unknowns: authorization prerequisites, property-wide blast radius, and the fact that no prior data is retroactively attributed. What remains missing is the success response (dimension ID/name) and whether the registration is reversible.

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% and the description adds real meaning for parameter_name (the exact parameter string the app sends, with a "destination" example) and by implication for scope. However, scope's EVENT vs USER enum distinction — a meaningful behavioral difference for reporting — is never explained, and `description` remains undocumented.

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

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

"Register an event parameter ... as a custom dimension so reports can use it as customEvent:<parameter>" gives a specific verb, resource, and observable effect, including the naming convention it produces. This is clearly distinguishable from the sibling ga4_custom_dimensions, which lists existing ones.

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

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

The description makes the trigger condition explicit (you want reports to reference the parameter as customEvent:<name>) and points to ga4_check_access for credential verification. It stops short of stating exclusions, e.g. that it should not be used merely to inspect existing dimensions, or that it fails on parameters already registered.

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 so well: it discloses two concrete prerequisites (Admin API enabled on the quota project, Viewer role on the GA4 property) and states the error behavior ('If it fails for access, the error explains how to fix it'). It does not describe the return shape or whether event and user dimensions are returned together, which keeps it short of 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?

The resource definition and the report-naming convention are front-loaded, followed by requirements and failure behavior — a sensible order with no filler. The only flaw is the mid-sentence language switch ('Lector (Viewer) en la propiedad de GA4'), which is a small readability blemish in an otherwise tight description.

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

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

For a single-optional-parameter, read-only listing tool with no output schema and no annotations, the description covers prerequisites, error handling, and how the results are consumed in reports. The remaining gap — what the response contains and whether it covers both event and user dimensions at once — is modest.

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

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

Schema coverage is 100% and the single `property` parameter is fully documented in the schema, including the default behavior and a pointer to ga4_list_properties. The description adds no further semantics about the parameter, so the baseline 3 applies.

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

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

The description names the resource precisely ('Event and user parameters registered as custom dimensions') and even explains the report-time naming convention customEvent:/customUser:, which distinguishes it from ga4_create_custom_dimension and ga4_custom_metrics. However, it never states the operation — no verb such as 'list' or 'retrieve' — so an agent must infer that this is a read/list 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?

It gives a genuine usage rule for the returned values ('Only these parameters can be used in reports'), but says nothing about when to call this tool versus ga4_custom_metrics or ga4_create_custom_dimension. The one routing hint present is indirect: 'ga4_check_access checks everything at once' points to a sibling for the access-diagnosis case.

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. It does disclose real prerequisites (Admin API enabled on the quota project, Viewer role on the GA4 property) and that access failures come back with remediation text, which is genuine behavioral value. It falls short on whether the operation is read-only, whether it returns all metrics or a filtered set, and there is no output schema to compensate.

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

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

It is short and front-loads the resource definition, and the prerequisite/error-handling clause is useful rather than filler. But it mixes Spanish ('Lector (Viewer) en la propiedad de GA4') into an otherwise English description, and the sentence structure is dense enough that the missing action verb gets lost.

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, zero-required tool with full schema coverage, the prerequisite block is enough to attempt a call and recover from auth errors. The critical gap is that the tool's actual action is never stated, and with no output schema there is nothing else to tell an agent what comes back.

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

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

Schema coverage is 100% for the single 'property' parameter, including the default-property fallback, so the schema does the semantic work. The description adds nothing about the parameter — no cross-reference to ga4_list_properties or ga4_set_default for choosing a property — matching the baseline of 3 when the schema is self-sufficient.

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 defines the resource ('Numeric event parameters registered as custom metrics') and how they are referenced in reports ('customEvent:<parameter>'), which is useful domain context. However, it never states the action the tool performs — listing, retrieving, or registering — so an agent must infer that this returns the property's custom metrics list. Sibling ga4_custom_dimensions is never mentioned as the parallel resource.

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 partial routing guidance: it points to ga4_check_access when access problems occur, which is useful triage. But it gives no explicit when-to-use versus ga4_custom_dimensions or ga4_run_report (where custom metrics are consumed), and no statement of when-not to call it.

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 burden. It usefully discloses prerequisites (Admin API enabled on the quota project, Viewer role on the GA4 property) and error behavior ('the error explains how to fix it'), but it never explicitly states the call is read-only/non-mutating and says nothing about the response shape or the possible retention values.

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

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

The purpose is front-loaded and the sentence count is low, but the remainder is a run-on semicolon chain and switches mid-sentence into Spanish ('Lector (Viewer) en la propiedad de GA4'), which adds friction for an agent parsing the requirements.

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 single-optional-parameter read with no output schema, the description covers purpose, prerequisites, and failure recovery adequately. The main missing piece is any hint about the returned retention settings (e.g., preset periods), which would help since no output schema exists.

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

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

The single 'property' parameter is fully documented in the schema (100% coverage), including that it is a saved property name and defaults to the default property. The description adds no further meaning beyond that, which is acceptable given the schema does the work.

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

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

The description states a specific resource and what information is returned: how long GA4 retains event-level and user-level data for explorations. It is clearly distinguishable from reporting siblings, though the verb is implicit (a read of retention settings) rather than stated outright.

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 names ga4_check_access as the tool that 'checks everything at once', which implies routing for access verification, and it lists the prerequisites that must hold before calling. However, it never states when to call this tool rather than ga4_property_details or another configuration reader, so usage is only implied.

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 supplied, the description carries the disclosure burden and does so for the two riskiest aspects: the required API enablement on the quota project and the Viewer role on the GA4 property. It also discloses failure behavior (errors explain how to fix access problems). It stops short of stating that this is a pure read with no side effects or how results are returned/ordered.

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?

Purpose comes first, followed by prerequisites and failure handling, which is sensible front-loading in three compact clauses. Minor blemish: the prerequisites sentence is partly in Spanish ('Lector (Viewer) en la propiedad de GA4'), an inconsistent-language fragment inside an otherwise English description.

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

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

For a simple one-optional-parameter read tool with no output schema, the description covers purpose, prerequisites, and failure recovery adequately. It is nonetheless incomplete on the optionality/default of the property argument and on whether all streams are returned in one call, both of which an agent needs to call it correctly.

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

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

The single parameter is fully documented in the schema (saved property name, see ga4_list_properties, defaults to the default property), so the description adds nothing about it. Worse, it omits the default-property behavior, meaning an agent reading only the prose would not know the parameter is optional and falls back to a default.

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

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

The description names the resource precisely ('Data streams of the property') and enumerates the concrete variants and identifying fields the agent will see (Android app, iOS app, website / package name, bundle id, URL). It is unmistakable against siblings like ga4_firebase_apps or ga4_property_details, though it uses a noun phrase rather than an explicit verb (list/get).

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 prerequisites and points to ga4_check_access as the one-shot diagnostic when access fails, which is useful routing. It never states when to call this versus related siblings such as ga4_firebase_apps or ga4_property_details, so the usage guidance is 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?

With no annotations, the description carries the full burden and does well: it warns that unique users are deduplicated per period and cannot be summed across periods, and it states the API-enablement and Viewer-role requirements plus the self-diagnosing error behavior. It omits row limits, cost/quota behavior, and what the response payload looks like.

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?

Core behavior is front-loaded in the first sentence and the caveat about deduplication follows immediately, which is the right order. There is minor clutter in the mixed-language access clause ('Lector (Viewer) en la propiedad de GA4') and the requirements tail could be tighter.

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 seven parameters, no output schema, and no annotations, the definition covers the essential semantics: what is counted, how periods and splits work, the deduplication trap, and the access preconditions. Missing only secondary details such as response shape and result-size limits, which an agent would likely need on first call.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds genuine meaning: the events-vs-prefix relationship, the day/ISO-week/month grouping including ISO semantics, and the notion of splitting by one additional dimension such as platform or country. It does not add format details for dates or dimension names beyond the schema 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 names the exact metrics (event count and unique users), the scope (a list of events or a prefix), and the optional time/dimension breakdowns, so the resource is unambiguous. It does not explicitly distinguish itself from siblings that could also return event figures (ga4_top_events, ga4_run_report), 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?

It gives real usage context: prerequisites for the API and property access, a note that failures self-explain, and an explicit pointer to ga4_check_access as the alternative for diagnosing access. It stops short of saying when to pick this over ga4_top_events or ga4_run_report.

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 meaningful work: it declares the required API enablement, the Firebase Viewer IAM role, and the failure behavior (the error explains how to fix access problems). It leaves out pagination behavior and confirms read-only only implicitly through "List".

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

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

Three sentences, front-loaded with the capability before prerequisites, and no filler. The only blemish is the mid-sentence language switch ("Firebase Viewer (o Lector) en el proyecto de Firebase"), which reads as an editing artifact in an otherwise English description.

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

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

For a low-complexity, single-parameter list tool with no output schema, the description covers purpose, returned fields, and access prerequisites, which is what an agent needs to call it or recover from failure. Only the absence of result-volume/pagination hints 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?

Single parameter with 100% schema description coverage, so the schema already explains firebase_project as the Firebase/Cloud project id. The description adds no syntax or format guidance beyond that, but the baseline for a fully documented one-parameter tool is satisfied.

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?

"List the Android, iOS and web apps of a Firebase project, with their app ids, package names and bundle ids" gives a specific verb, resource scope, and even the returned fields. It stops short of distinguishing itself from adjacent siblings such as ga4_firebase_links or ga4_property_from_firebase, which an agent could plausibly 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 implied rather than stated: the prerequisites (Firebase Management API enabled, Firebase Viewer role) tell the agent when the call will succeed, and it points to ga4_check_access as a one-shot diagnostic alternative. There is no explicit "use this when you need X instead of Y" routing against ga4_firebase_links or ga4_property_from_firebase.

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 and does substantial work: it discloses the required API enablement, the permission level on the property, and that access failures are self-explanatory with remediation in the error. It never explicitly says the operation is read-only, which is the main remaining gap.

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

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

Three short sentences with no padding, and the prerequisites are front-loaded. However, the leading fragment lacks a verb, and the mid-sentence language switch ("Lector (Viewer) en la propiedad de GA4") slightly hurts readability.

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, no-output-schema read tool, the prerequisite and error-handling context is largely sufficient. What is missing is an explicit statement of what the call returns and that it is non-mutating, plus any differentiation from ga4_firebase_apps.

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 optional `property` parameter already documents its default and points to ga4_list_properties. The description adds nothing about the parameter, so the baseline 3 applies.

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

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

The description names a specific resource ("Firebase projects linked to the property") but never states the verb — it is a noun fragment, so the agent must infer that this lists Firebase/GA4 link configurations. It does not distinguish itself from the sibling ga4_firebase_apps, which plausibly covers a related Firebase surface.

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 useful preconditions (Admin API enabled on the quota project, Viewer role on the GA4 property) and routes the agent to ga4_check_access for a one-shot access diagnosis. It stops short of saying when to call this versus ga4_firebase_apps or ga4_bigquery_links, and there are no explicit exclusions.

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

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

With no annotations, the description carries the full burden and does so well: it discloses that the endpoint is v1alpha and can return user counts that disagree with ga4_event_counts (even more users at a step than ever fired the event), and it warns to cross-check. It also names prerequisites — Data API enabled on the quota project and Viewer role on the property — and states that access errors are self-explanatory.

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?

Purpose is front-loaded in the first sentence and the caveats follow in a logical order: output shape, alpha warning, prerequisites, error handling. It is somewhat dense and contains an inconsistent language fragment ('Lector (Viewer) en la propiedad de GA4') that slightly interrupts flow, but no sentence is wasted.

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

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

For a seven-parameter analytics tool with no output schema and no annotations, the description covers what the tool returns, the alpha reliability caveat, the prerequisites, and where to go for access troubleshooting. An agent has enough to call it correctly and to interpret suspicious results.

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 all seven parameters, including steps ordering, open_funnel semantics, and breakdown_limit bounds, are already documented in the schema. The description only echoes the optional breakdown concept ('such as platform') without adding format or constraint detail beyond that. Baseline 3 is appropriate.

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

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

States a specific verb and resource — a sequential funnel over GA4 events via runFunnelReport — and specifies exactly what is produced: per-step user counts with completion and abandonment rates, optionally split by a dimension. This is clearly distinguishable from siblings like ga4_step_conversion, ga4_event_counts, or ga4_run_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 concrete routing advice: cross-check against ga4_event_counts before reporting, and use ga4_check_access if access fails. It does not explicitly contrast with the closest sibling ga4_step_conversion, so the agent must infer which funnel-style tool to pick, but the surrounding guidance is strong.

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?

Because no annotations are supplied, the description carries the full burden. It does disclose useful behavior: the required Admin API enablement, the Viewer role requirement, and that errors are self-explanatory. It does not state the read-only nature, the return shape or ordering, or pagination, and the mid-sentence Spanish phrase ('Lector (Viewer) en la propiedad de GA4') reduces clarity.

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

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

It is three compact sentences with no filler, and the subject is front-loaded. The only flaw is the inconsistent language mixing, which slightly weakens readability but costs no real 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 simple single-parameter read tool with no output schema, the description covers authorization and error guidance well. It omits what the response contains (fields per key event) and whether results are paginated or limited, which the agent would otherwise need to know.

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 a single optional parameter, and schema description coverage is 100%; the schema already explains that property is a saved property name defaulting to the default property. The description adds nothing about the parameter, so baseline 3 applies.

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

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

The description identifies the resource precisely: events marked as key events (formerly conversions) in the property, and it clarifies the legacy terminology, which helps recognition. It lacks an explicit verb such as 'list' or 'retrieve', so a reader has to infer that this is a read operation. It also does not distinguish this tool from its close sibling ga4_top_events.

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 prerequisites to run it and points to ga4_check_access as a one-shot diagnostic when access fails, which is genuine troubleshooting guidance. However, it does not say when to use this tool instead of ga4_top_events or ga4_event_counts, so routing between the event-related siblings is left to inference.

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

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

No annotations are supplied, so the description carries the full burden, and it does disclose the returned fields and that credentials are masked in the output. It does not say whether this is a pure local read or triggers a network/auth call, nor what happens when no properties are configured, which are the residual behavioral gaps.

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 that names the resource first, then enumerates the returned fields with no filler. Every clause (including 'secrets masked') adds information an agent would otherwise have to discover at call time.

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

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

With no output schema and no parameters, the description compensates by enumerating the response fields, which makes the tool callable without further exploration. Slightly incomplete because it does not state the output shape (array vs object) or the empty-registry case, but nothing critical for correct invocation is missing.

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

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

The tool takes zero parameters, so parameter semantics carry no risk and the baseline of 4 applies. The description correctly implies no filtering or arguments are needed — the returned set is whatever the server has stored.

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 verb 'List' and the resource 'GA4 properties' are both explicit, and the phrase 'this server remembers' scopes it to locally configured/registered properties, which separates it from ga4_property_details style lookups. It does not name the sibling it replaces, so an agent still has to infer that this is the discovery step.

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

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

Usage is only implied: an agent can infer this is the entry point for discovering which properties exist and which is the default before calling ga4_run_report or ga4_set_default. There is no explicit 'use this when…' clause and no statement about what to do if the list is empty or how it relates to ga4_account_summaries.

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 provided, the description carries the full burden and does reasonably well: it discloses the required API enablement, the 'Lector (Viewer)' role required in the GA4 property, and that access failures return an error explaining how to fix them. It doesn't describe output shape or whether custom fields are always included versus gated by custom_only, but the prerequisite and failure behavior are unusually well covered for an unannotated 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 purpose and the 'use before' rule are front-loaded, and every sentence carries information. Minor deductions for verbosity in the access paragraph and a language mix ('Lector (Viewer) en la propiedad de GA4') inside an otherwise English description.

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

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

For a simple, non-destructive listing tool with a fully described 4-parameter schema, the definition covers purpose, prerequisites, ordering relative to ga4_run_report, and failure handling. What remains unstated, mainly output structure and pagination/size expectations for the longer with_descriptions output, is modest 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 description coverage is 100%, so all four parameters are already documented in the schema; the description only reinforces that customEvent:* entries appear in the result, which corresponds loosely to custom_only. It adds no syntax, default behavior, or combination guidance beyond the schema baseline.

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 the dimensions and metrics available in the GA4 property', and adds a concrete scope detail about customEvent:* parameters. It does not explicitly distinguish itself from siblings like ga4_custom_dimensions or ga4_custom_metrics, which an agent might reasonably confuse it with, so it falls short of a 5.

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

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

It gives an explicit sequencing rule ('Use before ga4_run_report to find valid API names') and names an alternative, ga4_check_access, for diagnosing access problems. It stops short of stating when-not-to-use or how it differs from the dedicated custom-dimension/metric siblings, so it is clear but incomplete.

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 disclosure burden. It usefully reveals the auth prerequisites and states that access failures produce a self-explanatory error, but it never says this is a read-only operation, mentions no quota/rate-limit behavior, and says nothing about response shape or row limits.

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

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

Three sentences, front-loaded with the core purpose and a concrete example, then prerequisites, then a troubleshooting pointer. Efficient overall, though the mid-sentence switch to Spanish ('Lector (Viewer) en la propiedad de GA4') slightly hurts readability for a general audience.

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

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

For an 8-parameter, nested-object tool with no output schema and no annotations, the description covers purpose, an example, prerequisites, and failure handling. The main gap is that it does not describe the returned pivot structure, which an agent would need to interpret results without an 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?

Schema description coverage is 100%, so the schema already documents every parameter, including pivot objects with their fieldNames and limit and the requirement that dimensions cover every dimension used in any pivot. The description's pivot explanation merely restates that schema example rather than adding new semantic 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 a specific verb+resource (pivot table report via the Data API's runPivotReport) and explains the shape: rows and columns from different dimensions, with a concrete platform-across-columns/eventName-down-rows example. It implicitly distinguishes itself from the flat ga4_run_report, but never names that sibling or contrasts the two explicitly.

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

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

Gives clear usage context through prerequisites (Data API enabled on the quota project, Viewer role on the GA4 property) and points to ga4_check_access for a one-shot access check. It does not say when to choose a pivot over ga4_run_report or ga4_batch_reports, so the selection decision is left to inference.

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

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

With no annotations, the description carries the full burden and does substantial work: it states the required Admin API (analyticsadmin.googleapis.com) on the quota project and the Viewer-level role on the GA4 property. It also discloses failure behavior ('the error explains how to fix it'), which is genuinely useful pre-call context. It stops short of confirming the operation is read-only or describing the response 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 compact sentences: returned fields first, prerequisites and failure routing second. Nothing is redundant, though the mixed-language fragment ('Lector (Viewer) en la propiedad de GA4') is less clean than the surrounding English text and adds slight friction.

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

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

For a simple one-parameter read tool with no output schema, the description supplies what an agent needs: which fields come back, what credentials/permissions are required, and where to go if access fails. Nothing material 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?

There is a single optional parameter at 100% schema coverage, so the schema already explains that 'property' is a saved property name defaulting to the default property. The description adds no further meaning about that parameter, which is the baseline case for full coverage.

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

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

The description names the resource (GA4 property settings) and enumerates exactly what is returned: display name, time zone, currency, industry, service level, creation date. It implies a single-property read, which separates it from the list-oriented ga4_list_properties, but it never states the verb explicitly (read/fetch) nor names the sibling it differs from.

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 a clear context for use (inspecting a property's configuration) and routes the agent to a sibling: ga4_check_access 'checks everything at once' if access troubleshooting is the real goal. It does not explicitly say when to prefer ga4_list_properties over this tool, so the sibling differentiation is only partial.

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 burden and does well: it discloses required API enablement (firebase.googleapis.com on the quota project), required IAM role (Firebase Viewer/Lector), and that failures return actionable access errors. It stops short of stating whether it performs any writes or how large the response can get.

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

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

The purpose and the 'use before ga4_configure' guidance are front-loaded, which is good. However the prerequisite sentence mixes languages ('Firebase Viewer (o Lector) en el proyecto de Firebase'), reducing clarity for an agent parsing requirements.

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 lookup with no output schema, the description covers purpose, prerequisites, error behavior, and a related alternative. The main omission is a hint about the shape of the returned property/stream data, though the opening sentence partially implies it.

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

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

There is a single parameter with 100% schema description coverage, so the schema already explains the project id format. The description adds no extra meaning about the parameter, which matches the baseline for full coverage.

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

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

States a specific verb and resource ('Find the GA4 property linked to a Firebase project') plus the returned detail (data streams per Android/iOS app). It does not distinguish itself from similarly-named siblings like ga4_firebase_links or ga4_firebase_apps, which an agent could easily confuse it with.

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

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

Explicitly says to use it before ga4_configure when only the Firebase project is known, and routes access-checking to ga4_check_access. This covers the main selection decision, though it doesn't rule out when not to use it versus the firebase/apps 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?

With no annotations supplied, the description carries the full burden and does a solid job: it discloses the 30-minute data window, the two prerequisites (Data API enabled on the quota project, Viewer role on the GA4 property), and that access failures return self-explanatory errors. It omits quota/cost behavior, pagination, and how limit interacts with the returned rows.

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 purpose, then field inventory, then prerequisites, then failure behavior — a logical order with no filler. Minor deductions for density and an untranslated Spanish phrase ("Lector (Viewer) en la propiedad de GA4") that sits awkwardly in otherwise English prose.

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

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

For an 8-parameter tool with nested filter objects and no output schema, the definition covers purpose, valid field names, auth prerequisites, and error behavior well. The remaining gap is that nothing describes the response shape or row-cap behavior, which matters given there is no output schema to fall back on.

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 88%, so the baseline is 3. The description adds genuine value by enumerating the valid realtime dimensions (eventName, platform, country, city, unifiedScreenName, appVersion, minutesAgo) and metrics (activeUsers, eventCount, screenPageViews, keyEvents), which the schema does not list. It says nothing about how minutes_ago_start/minutes_ago_end combine or how the two FilterExpression objects are shaped beyond the schema 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?

States a specific verb and resource with scope: a realtime report over the last 30 minutes via the Data API runRealtimeReport. An agent can immediately tell this is the realtime path rather than a historical report. It stops short of naming ga4_run_report explicitly as the non-realtime counterpart.

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 context for when this applies (30-minute live window, its own smaller field set) and routes access troubleshooting to ga4_check_access. It does not explicitly exclude historical reporting or point to ga4_run_report / ga4_active_users as the alternatives for overlapping needs.

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 at all, the description carries the full behavioral burden. It does meaningful work by implying the operation only removes a saved configuration entry ("forget") and by ruling out env-var-backed properties, but it never states whether the underlying GA4 property is untouched, whether the action is reversible, or what happens when the name doesn't match.

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

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

Two short sentences, purpose front-loaded, with the constraint immediately after. No filler and nothing that 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 one-parameter tool with no output schema and no annotations, the description covers the essentials: what it does and the one precondition that blocks it. The remaining gap is post-call behavior (idempotency, behavior on unknown names), which is minor at this complexity level.

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

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

The single parameter has 100% schema description coverage ("Saved property name"), so the baseline is 3. The description adds nothing about matching rules, case sensitivity, or whether the name must correspond to an existing saved entry.

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?

"Forget a saved GA4 property" gives a specific verb (forget/remove) plus the exact resource, and the word "saved" scopes it to a locally stored property rather than the GA4 property itself, which distinguishes it from siblings like ga4_list_properties or ga4_property_details. It stops short of naming a sibling explicitly, so it lands at 4 rather than 5.

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

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

The description supplies one real when-not condition: properties sourced from environment variables cannot be removed here. It gives no when-to-use framing, no pointer to how to discover removable saved properties (e.g. ga4_list_properties), and no alternative for the env-var case, so usage is only implied.

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 hard prerequisites (analyticsdata.googleapis.com enabled on the quota project, Lector/Viewer role on the property) and the failure behavior (access errors explain how to fix themselves; ga4_check_access validates everything at once). It omits return-row shape and any rate/quota limits, and "Run" only implicitly signals a read-only operation.

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

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

Dense and front-loaded: capability, naming convention, filter shape, and prerequisites in four compact sentences. The mid-sentence language switch to Spanish ("Lector (Viewer) en la propiedad de GA4") is a small readability blemish in an otherwise efficient definition.

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 nested filter objects and no output schema, the definition covers auth prerequisites, field-naming conventions, error recovery, and cross-tool helpers. The remaining gap is what a response row looks like and how limit/offset paging interacts with totals, but the schema covers those parameters individually.

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

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

Schema coverage is 100%, so baseline is 3; the description earns a 4 by establishing that dimensions and metrics take API names (not display names) rather than free text, and by routing the agent to ga4_metadata to discover valid names — real semantics the schema does not supply. Filters and orderBys are only told to follow "the Data API JSON shape," which the schema already exemplifies.

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?

"Run any GA4 Data API report" gives a specific verb (run) and resource (GA4 Data API report), and the word "any" signals this is the generic escape hatch versus the numerous specialized siblings (ga4_top_events, ga4_realtime_report, ga4_pivot_report, ga4_event_counts). It never explicitly names those siblings as alternatives, so the boundary is inferred rather than stated.

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

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

The description points to ga4_metadata for valid dimension/metric names and to ga4_check_access when access errors occur, giving useful pre-call and troubleshooting guidance. However, it does not say when to prefer this generic report tool over the ~30 specialized report siblings, which is the main selection decision an agent faces here.

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; it does add real value by naming prerequisites (Data API enabled on the quota project, Viewer role on the GA4 property) and by promising that access errors explain the fix. It omits behavioral traits an agent needs before calling: result sort order, what the default limit of 50 means for truncation, and the shape of the response.

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?

Purpose is correctly front-loaded and the sentences are short, but the requirement clause is crammed and switches to Spanish mid-English ('Lector (Viewer) en la propiedad de GA4'), which is jarring for an English description and slightly obscures the permission requirement.

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 is the only place to learn what a result row looks like, and it gives only the metric names without ordering, row shape, or truncation behavior. It is adequate for calling the tool, but not complete for a report tool with five parameters and no structured return documentation.

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 80%, so the baseline is 3. The description restates the 'contains' filter behavior, which the schema already documents, and adds nothing about 'limit' truncation, the relative date syntax, or how 'property' resolves to the default property.

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

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

States a specific resource (app screens / web pages) and the exact metrics returned (views, users, engagement time), which separates it from event-oriented siblings like ga4_top_events. It never names a competing sibling such as ga4_run_report, so the differentiation is implicit rather than 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 'contains' sentence makes the optional filtering use case clear, and the closing line routes access failures to ga4_check_access. However, there is no guidance on when to prefer this over ga4_run_report or ga4_realtime_report, and no statement of when not to use it.

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 must carry the behavioral burden. It discloses that the tool sets a default property used by other calls, which is meaningful beyond the schema. However, it omits permissions, persistence scope, whether it overwrites a prior default, and reversibility, which are important for a configuration mutation.

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

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

The description is a single front-loaded sentence with no wasted words. It states the action and the condition of its effect immediately.

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

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

For a simple one-parameter configuration tool, the description covers the core action and its downstream effect. Given no annotations and no output schema, it should also mention how to obtain a valid saved property name or what happens on invalid input, but those gaps are not severe.

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 already documents the single parameter as 'Saved property name' with 100% coverage. The description reinforces that the name refers to a saved GA4 property and becomes the default, but it adds no format, source, or validation details beyond the schema.

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

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

The description uses a specific verb ('Choose') and resource ('saved GA4 property') and explains the effect: tools use that property when a call names none. This clearly distinguishes it from sibling tools such as ga4_list_properties or ga4_configure.

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 a clear condition for the tool's effect: it applies when a call does not name a property. It does not explicitly state when to choose this tool versus alternatives or whether it should be run before report tools, but the context is strong enough for an agent to infer usage.

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 non-sequential counting semantics and the resulting caveat that a user can appear at a later step without having completed earlier ones. It also lists prerequisites (Analytics Data API enabled on the quota project, Viewer role on the GA4 property) and states that access failures return a self-explanatory error. Return shape beyond the metric list (ordering, formatting) is not described.

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 core computation and the key caveat are front-loaded in the first sentence, and every clause carries information. It is dense, run-on, and contains a mixed-language fragment ('Lector (Viewer) en la propiedad de GA4'), which slightly hurts scanability, but there is no filler.

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

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

For a multi-step analytical report with no output schema and no annotations, the description supplies the methodology, the output fields that will be produced, prerequisite access setup, and a pointer to the diagnostics tool. Missing are output shape details (row ordering, date granularity, pagination) for a non-trivial report result.

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 all five parameters are already documented in the schema, including 'Event names in funnel order' and 'Dimension to split by, e.g. "platform"'. The description restates the same meaning (steps in order, optional split) without adding format or constraint detail beyond it, 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 names the resource (a funnel report) and its exact computation method: unique users per event, non-sequential, with users, share of first step and share kept from the previous step, optionally split by a dimension. It also explicitly contrasts itself with the sibling ga4_funnel ('reliable where ga4_funnel's alpha counts are not'), so an agent can distinguish the two. The only shortfall is that the verb ('build/report') is implied rather than stated.

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

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

It gives a clear selection rule against the closest alternative ('reliable where ga4_funnel's alpha counts are not') and defers access diagnostics to ga4_check_access ('checks everything at once'). It does not spell out a positive trigger case or constraints like step-count limits, but the sibling routing is explicit rather than inferred.

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

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

With no annotations, the description carries the full burden and does useful work: it states the two prerequisites (Data API enabled on the quota project, Viewer role on the GA4 property) and that access errors are self-explanatory. It never says this is a read-only operation, what the result rows contain, or how limit truncation behaves, which are the gaps an agent would still have to guess at.

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 breakdown purpose is front-loaded in the first clause, which is good. The final sentence mixes languages ("Lector (Viewer) en la propiedad de GA4") and packs prerequisites, error behavior, and a sibling pointer into one run-on, which hurts readability.

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 six-parameter analytics query with no output schema, the description covers purpose and prerequisites but omits what a result row looks like (dimension value plus user/event counts) and how `limit` affects the breakdown. Adequate to attempt a call, not complete enough to predict the response shape.

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

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

The prose restates the breakdown choices already enumerated in the schema's `by` enum and explains the `events` filter ("optionally only for some events"), adding slight meaning. It says nothing about `limit`, `property`, or date-range interplay, so at 67% schema coverage the description does not compensate for the undocumented remainder.

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 opening clause names the metrics (users and events) and enumerates the breakdown dimensions (platform, app version, OS version, device model), which is a specific verb+resource statement. It is distinguishable from ga4_top_events and ga4_event_counts by focusing on dimensional breakdown rather than top-N or totals, though it never names those siblings explicitly.

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

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

It gives a concrete use case ("spot a version or device where a step fails") and routes the agent to ga4_check_access when the failure is access-related. There is no explicit statement of when NOT to use it (e.g., when a full report or funnel is needed), which keeps it below a 5.

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

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

With no annotations provided, the description carries the burden well: it discloses prerequisites (analyticsdata.googleapis.com enabled on the quota project, Viewer role on the property), what the response contains, and that access failures return an explanatory error. It does not mention quotas, rate limits, or whether any state is written, leaving minor gaps for a diagnostic 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 core purpose and return values are front-loaded in the first clause, and every sentence carries information. It is a dense run-on using semicolons, and the mixed-language fragment 'Lector (Viewer) en la propiedad de GA4' slightly hurts readability.

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

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

With no output schema and no annotations, the description still covers return values, prerequisites, failure behavior, and the sibling alternative. The only omission is any note on latency, quota consumption, or whether the returned metrics are sampled, which is minor for a connectivity test.

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 parameter is already documented as 'Saved property name; defaults to the default property'. The description adds no further meaning about accepted names, formats, or how the default is resolved, so it meets the baseline only.

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: verifying that a saved property's credentials can read its GA4 data, with concrete evidence returned (active users and events for the last 7 days, or the API error). It also names the sibling ga4_check_access and contrasts scope, so an agent can distinguish 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?

It implies the usage context (validate a saved property before relying on it) and points to ga4_check_access as the broader alternative, which is clear routing guidance. It stops short of an explicit 'use this instead of X when Y' rule or stating when not to use it.

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 required API enablement, the permission level, and that access failures return a self-explanatory error, plus a pre-flight alternative. It does not mention quota consumption or that this is strictly a read-only query, so it is strong rather than complete.

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 front-loaded sentences: output first, optional filter second, prerequisites and failure handling last. Efficient overall, though the mixed-language phrase 'Lector (Viewer) en la propiedad de GA4' is slightly awkward and could be tightened to a single English permission statement.

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

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

For a five-parameter read-only reporting tool with no output schema, the description covers what is returned, the optional filter, the auth/API prerequisites, and the recovery path via ga4_check_access. An agent has everything needed to call it or diagnose failure without opening the 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?

Schema coverage is 80%, so the schema already documents prefix, dates and property. The description only restates the prefix filter in prose and adds nothing about limit semantics (default 50, max 1000) or how relative dates interact with the range. Baseline 3 applies where the schema does the heavy lifting.

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

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

The description states a specific operation and resource: the most frequent events in a period, plus the exact metrics returned (event count, unique users, events per user) and an optional prefix filter. It is clear what the tool produces, though it does not name a sibling (e.g. ga4_event_counts or ga4_run_report) that 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?

It gives real prerequisites (Data API enabled on the quota project, Viewer access on the GA4 property) and routes the agent to ga4_check_access when access is in doubt, which is genuine usage guidance. However, it never says when to choose this over the many sibling reporting tools (ga4_event_counts, ga4_run_report, ga4_realtime_report) or when not to use it.

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