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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context by warning that responses can be LARGE and recommending batch-size limits. However, it does not disclose response format, error behavior, or rate limits, so it stays at a moderate transparency level.

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 appropriately short: a clear purpose statement followed by a focused warning. The core action is front-loaded, and every sentence earns its place without repeating schema or annotation content. This is exemplary conciseness.

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

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

With no output schema, the description leaves the batch response shape unspecified and does not explain how partial failures or errors across multiple reports behave. It covers the main invocation constraints—batching, limits, and token safety—so an agent can call it, but it is not fully complete for an unfamiliar agent.

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 baseline is 3. The description adds extra meaning beyond the schema by advising that each batch should contain 2-5 reports and that each report should have small limits to avoid excessive data. This is genuinely useful parameter-level guidance that the input schema does not provide.

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

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

The description states a specific verb and resource: "Run multiple reports in a single request." This clearly distinguishes the tool from single-report siblings like ga_run_report, ga_run_realtime_report, ga_run_pivot_report, and ga_run_funnel_report. The batch nature is explicit and leaves no ambiguity about what the tool does.

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

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

The description implies the primary use case—batching multiple report requests—but it does not explicitly contrast with ga_run_report for single reports or other report variants. The token optimization warning provides practical guidance (limit to 2-5 reports, keep limits small), but there is no explicit when/when-not or alternative-selection guidance.

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

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

Annotations already cover read-only, idempotent, open-world, and non-destructive behavior. The description adds useful behavioral context: it avoids wasted report requests and error loops, and it lists which other fields remain compatible. No contradiction with annotations.

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

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

The description is two short sentences that front-load the primary purpose and then add a concrete benefit plus an extra output behavior. Every sentence earns its place with no wasted words.

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

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

The description covers the essential selection and invocation context: property validity, dimensions, metrics, compatibility filter, and the benefit of avoiding failed report requests. It mentions the extra output of compatible fields, but with no output schema, the response format is not detailed.

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 each parameter already includes a helpful description with examples. The tool description itself adds no parameter-level semantics beyond the schema, 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 states a specific verb and resource: 'Check whether a combination of dimensions and metrics is valid for this property'. It also explicitly positions itself as a pre-report validation step, which clearly differentiates it from ga_run_report and other report-related siblings.

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

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

The description gives explicit timing guidance with 'BEFORE running a report', making the intended use case clear. It does not name sibling alternatives directly or state when not to use it, so it stops short of 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?

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description adds useful context about the 'compact overview' scope and single-call efficiency, though it does not detail response shape, ordering, or whether results are paginated.

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 with no wasted words. The first sentence states exactly what the tool does, and the second reinforces its primary use case and output value.

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

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

For a zero-parameter, read-only discovery tool, the description is complete: it names the resource scope, the single-call nature, and the key output fields. The annotations cover safety and idempotence, so no critical information 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 has zero parameters and an empty input schema, so there are no parameter semantics to explain. The description correctly avoids inventing parameter guidance, matching the baseline for a no-parameter tool.

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

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

The description states a specific verb and resource: 'Get a compact overview of all accessible GA accounts and their properties in a single call.' It also clarifies the concrete value delivered: 'account IDs, property IDs, and property names.' This clearly distinguishes it from siblings like ga_list_accounts and ga_list_properties by emphasizing a compact, single-call aggregate view.

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 frames usage as the fastest way to discover account and property IDs/names, which gives clear context on when to call it. It does not explicitly name alternatives or say when not to use it, but the intended discovery use case is evident.

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

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

Annotations already mark this as read-only, idempotent, and non-destructive. The description adds meaningful behavioral context beyond that: the response is intentionally complete ('ALL available dimensions and metrics'), can be around 500+ items, and should be cached/sparingly used. This is valuable operational disclosure.

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

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

The description is two short blocks: a one-sentence purpose followed by a focused warning. It is front-loaded, contains no filler, and every sentence contributes either to selecting the tool or using it responsibly.

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 tool with fully documented schema, the description gives the essential context: what the tool returns, that the response is large, and that results should be cached. The absence of an output schema means some return-format details are unspecified, but this is a minor gap given the simplicity of the operation.

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

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

The input schema already documents propertyId thoroughly, including accepted formats and a discovery hint via ga_get_account_summaries, and schema coverage is 100%. The description itself adds no parameter-level detail, so the baseline of 3 applies.

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

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

The description opens with a specific verb+resource: 'Get available dimensions and metrics metadata for your GA4 property.' It clearly distinguishes this from siblings such as ga_list_custom_dimensions and ga_list_custom_metrics, which concern custom definitions, and ga_run_report, which executes queries.

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

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

The token-optimization note tells the agent when to be cautious and to cache results, which is useful operational guidance. However, it does not explicitly state when to choose this tool over alternatives or when not to use it, so selection guidance is only implied by the purpose.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds the useful scope behavior (configured default vs. propertyId override), but no further behavioral details such as response shape or access requirements. No contradiction with annotations.

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

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

A single concise sentence that front-loads the action and immediately clarifies both default and override behavior. No filler or redundant restatement of the tool name.

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

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

For a simple read-only, one-optional-parameter tool with rich annotations and full schema coverage, the description is nearly complete. It explains the default target and override mechanism, though it leaves the exact content of 'details' unspecified, which is a minor gap.

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

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

The schema provides 100% coverage of the single optional propertyId parameter, including the default override behavior and accepted formats. The description itself only mentions propertyId in passing, so it adds no semantic value beyond what the schema already documents.

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

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

The description states a clear verb-resource pair: 'Get details about a GA4 property'. It also signals the scope (configured property or any accessible one via propertyId), which helps distinguish it from list-oriented siblings like ga_list_properties, though it does not name them explicitly.

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

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

The description gives useful context: the tool fetches the configured GA4 property by default or a specific property via propertyId. However, it does not explicitly state when to prefer this over alternatives such as ga_list_properties or ga_get_account_summaries, nor does it mention exclusions.

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

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

Annotations already declare read-only and idempotent behavior. The description adds useful context by clarifying that the listing is scoped to the service account's accessible accounts and that 'all' accounts are returned. There is no contradiction with annotations.

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

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

Two short sentences with no filler. The core behavior is front-loaded before the usage pointer, and every sentence earns its place.

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

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

For a zero-parameter, read-only list tool with comprehensive annotations, this is complete. It conveys the output intent (account IDs) and the workflow context, and no missing detail would prevent an agent from calling 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?

There are zero parameters, so the schema is complete by default. The description's mention of account IDs is about output intent and workflow, not input semantics, so the baseline score of 4 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 opens with a specific verb and resource: 'List all Google Analytics accounts accessible to the service account.' This clearly defines the tool's scope at the account level and even explains its purpose (finding account IDs for listing properties), distinguishing it from property/data-stream/reporting siblings.

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

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

It explicitly tells the agent when this tool fits: to find account IDs before listing properties. It does not name alternatives or exclusions, such as ga_get_account_summaries, so it falls short of a 5, but the usage context is unmistakable.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds a useful purpose hint (API-name discovery for reports) but does not disclose return shape, ordering, or pagination, which leaves some behavioral ambiguity.

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 with the primary action first and the practical use case second. Every sentence earns its place; there is no repetitive or filler content.

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

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

For a one-optional-parameter read-only listing tool, the description covers the resource, scope, and practical purpose. It does not detail return values beyond the API-name example, but the simple read-only nature and full schema make this a minor gap.

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

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

The only parameter, propertyId, is fully documented in the schema (format, override behavior, and discovery via ga_get_account_summaries), so schema description coverage is 100%. The tool description itself adds little parameter-level meaning beyond the example output value, hence the baseline 3.

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

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

The description starts with a specific verb-resource pairing: 'List all custom dimensions defined for the configured GA4 property.' It clearly distinguishes the tool's scope from sibling tools such as ga_list_custom_metrics by naming the exact GA4 resource being listed.

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

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

'Use this to discover custom dimension API names (e.g., "customEvent:plan_type") for reports' gives a concrete reason to invoke the tool. It does not say when not to use it or point to alternatives, so it stops short of a full routing guide.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds some context about the configured property and the API-name output, but it does not disclose pagination, limits, or other behavioral quirks; this is acceptable but not exceptional.

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 with no filler. The action and scope are front-loaded, and the use-case sentence earns its place by explaining why an agent would call the tool.

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

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

For a simple read-only list tool with one optional, well-documented parameter, the description is nearly complete. Without an output schema, it helpfully states that the result surfaces custom metric API names for reports, though a bit more detail about the response shape would make it 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?

The input schema documents propertyId fully, including accepted formats and how to discover IDs, with 100% schema description coverage. The description adds no parameter-specific detail, so the schema bears the load and 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 opens with 'List all custom metrics defined for the configured GA4 property', a specific verb and resource that clearly distinguishes it from sibling tools such as ga_list_custom_dimensions and ga_list_key_events. It immediately tells the agent what object is acted on.

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

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

The second sentence, 'Use this to discover custom metric API names for reports', provides a clear intended use case. It does not explicitly mention when not to use it or name alternatives, but the context is concrete enough to route an agent correctly.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description adds context that the tool is the path to measurement IDs, but does not disclose additional behavioral details such as pagination, quotas, or error conditions; given the rich annotations, this is acceptable.

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

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

Two short sentences carry clear action, scope, and purpose with no filler. The main statement is front-loaded and the usage hint follows 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 single-optional-parameter read-only list tool, the description is sufficient: it names the resource, the default scope, the override, and the intended use. The return value is strongly implied through 'find measurement IDs,' so the lack of an output schema does not create a gap.

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

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

Schema description coverage is 100%, and the propertyId parameter is already well documented with format, default behavior, and discovery guidance. The tool description itself does not need to add parameter detail, so 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 uses a specific verb and resource: 'List data streams for the configured GA4 property.' It also gives a concrete downstream purpose (finding measurement IDs for Measurement Protocol), which distinguishes this listing tool from sibling tools that list accounts, properties, dimensions, metrics, or key 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 explicitly says when to use it: when measurement IDs are needed for Measurement Protocol. It does not name exclusions or alternatives, but the use case is clear enough for an agent to select this over sibling list tools.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is well-covered. The description adds the operation's scope but does not disclose additional behavioral details such as permissions, pagination, or response format. This is acceptable given the annotations, but not exceptional.

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 clearly states the action, resource, and scope in minimal space.

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, read-only list tool with a well-documented optional parameter and comprehensive annotations, the description is largely sufficient. No output schema exists, so a bit more detail about the returned data could help, but 'List Google Ads accounts' strongly implies the return shape and the tool's scope is clear.

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 provides 100% coverage for the single parameter, including override behavior, accepted formats, and how to discover IDs. The description does not add meaningful parameter semantics beyond restating the GA4 property context.

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 ('List'), a clear resource ('Google Ads accounts'), and a precise scope ('linked to a GA4 property'). This clearly distinguishes it from sibling tools like ga_list_accounts or ga_list_properties.

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 usage context is implied by the description: use this tool when you need Google Ads accounts linked to a GA4 property. The schema hints to use ga_get_account_summaries for discovering IDs, but the description itself does not explicitly state when to choose this tool over alternatives 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.

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=true, so the safety profile is fully covered. The description adds little beyond restating the tool's purpose; no pagination, return format, or error behavior is disclosed, but given the strong annotations this is acceptable.

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

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

Two sentences, no fluff. The action is front-loaded, and the usage context is a natural second sentence that earns its place. Nothing is redundant with the schema or annotations.

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

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

For a simple read-only listing tool with a single optional parameter and strong annotations, the description is complete. It could mention that propertyId defaults to GA_PROPERTY_ID, but the schema already covers that. No output schema exists, but the description gives enough context for correct invocation.

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

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

Schema description coverage is 100%, with propertyId fully documented including accepted formats and a pointer to ga_get_account_summaries. The description adds no extra parameter meaning, so the baseline of 3 applies.

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

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

The description clearly states the verb and resource: 'List the key events (conversions) configured for the GA4 property.' This precisely distinguishes it from sibling tools like ga_list_data_streams or ga_list_custom_dimensions, and the parenthetical '(conversions)' disambiguates the concept immediately.

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

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

The second sentence gives clear context: this is useful before building reports or sending events, so an agent knows when to call it. It doesn't explicitly mention when not to use it or name alternatives, but the context is specific enough that no exclusion is strictly needed.

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

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

The annotations already declare this tool read-only, idempotent, non-destructive, and open-world. The description adds behavioral context beyond those annotations: without an account ID, properties from all accessible accounts are aggregated; with one, results are filtered. It does not mention pagination or auth specifics, but those are unnecessary for this simple listing 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?

The description consists of two short sentences: the first states the purpose directly, and the second explains the optional filtering behavior. Every sentence earns its place, there is no repetition of the schema, and the key usage information is front-loaded.

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

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

Given the low complexity, one optional parameter, rich annotations, and complete schema coverage, the description fully equips an agent to invoke the tool correctly. It states what the tool does and exactly how the optional parameter affects the result, with nothing essential missing.

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

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

Schema description coverage is 100%, and the schema already documents accountId as an optional filter with an example. The description reinforces the optional filtering behavior but adds little semantic value beyond the schema, so the baseline score of 3 is appropriate.

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

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

The description opens with a specific verb and resource, 'List Google Analytics properties', making the tool's function immediately identifiable. It also explains the optional account ID filter and the aggregation behavior, which clearly distinguishes it from account-level or single-property siblings like ga_list_accounts and ga_get_property.

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

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

The description clearly explains when to supply an account ID and what happens when it is omitted, providing a decision rule for the caller. It does not explicitly name alternative tools or state when not to use this tool, so it falls just short of a 5.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior. The description adds useful behavioral context on how steps map to events, the eventName default, and the filterExpression override, which goes beyond the annotations without contradicting them.

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

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

The description is compact and front-loaded: it states what the tool does in the first sentence and immediately provides the most important step-matching behavior in the second. Every sentence contributes useful information without unnecessary filler.

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

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

Given the nested schema and lack of an output schema, the description is adequate for invoking the tool but leaves gaps: it doesn't describe what the funnel report output contains, pagination, or how to choose among the many report siblings. The schema and annotations cover the core invocation details, so this is not severely incomplete.

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

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

The description adds slight interpretive value for funnelSteps, especially the per-step eventName default and filterExpression override, but much of this is already present in the input schema. Other parameters like dateRanges, funnelBreakdown, and funnelVisualizationType receive no additional clarification 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 clearly states the action ('Run') and the resource ('a funnel analysis report') with a specific goal ('track user progression through steps'). It also identifies the API version. While it doesn't explicitly contrast with sibling ga_run_report, the funnel-specific wording makes it reasonably distinguishable.

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

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

Usage is implied by the funnel-report framing and by the step-matching explanation, but there is no explicit when-to-use or when-not-to-use guidance. Alternatives such as ga_run_report, ga_run_pivot_report, or ga_run_realtime_report are not mentioned, leaving routing 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?

The annotations already cover read-only and idempotent behavior. The description adds useful behavioral context beyond the schema by warning that pivot reports can be VERY large and that token usage should be managed by limiting dimensions and date ranges. This is important operational guidance an agent would not get from annotations alone.

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 only two short sentences, front-loaded with the core purpose and followed by a high-value warning. Every sentence earns its place, and there is no redundant 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?

The tool has 5 parameters, no output schema, and no description of return values or pivot structure, making this incomplete for confident invocation. It does not clarify the relationship between the 'dimensions' and 'pivots' parameters, nor does it explain when to use this tool versus ga_run_report. The token-optimization warning is valuable, but it does not fill the structural gaps.

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

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

Schema description coverage is only 40%, and the description does not compensate by clarifying the missing parameters. It gives high-level advice to limit dimensions and date ranges, but does not explain how pivots map to row/column dimensions, what metrics should contain, or how fieldNames in pivots work. The description adds strategic guidance but not enough parameter-level meaning.

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

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

The description clearly states the verb and resource: 'Run a pivot table report with row and column dimensions.' This distinguishes it from ga_run_report and ga_run_realtime_report at a basic level, though it does not explicitly name those siblings or explain the exact difference beyond the pivot-table concept.

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

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

The description gives clear context: pivot reports are for analysis, not raw data extraction, and should use limited dimensions and small date ranges. It does not explicitly name alternative tools like ga_run_report for raw extraction, but the guidance is actionable enough for an agent to select the right use 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?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description adds useful context about the 30-minute recency window and token optimization, but does not disclose response shape, potential rate limits, or pagination behavior. This is adequate but not rich.

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

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

The description is compact and front-loaded with the core purpose. The token-optimization note and common dimension/metric lists are concise and earn their place. There is no redundant or vague filler.

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

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

With four parameters, no output schema, and strong annotations, the description provides enough guidance to invoke the tool: real-time scope, common fields, and limit usage. It does not explain the return value format or detail how metrics/dimensions should be structured, but these gaps are partially mitigated by the schema and examples.

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 baseline is 3. The description adds value by listing common dimensions and metrics (city, country, activeUsers, conversions) that are not present in the schema, helping the agent form valid queries. It also reinforces limit's purpose, though the schema already documents the 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 opens with a specific verb and resource: 'Get real-time Google Analytics data (last 30 minutes).' This clearly identifies both the action and the exact time scope, and the real-time distinction differentiates it from siblings like ga_run_report. The purpose is immediately understandable.

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

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

The description clearly states this is for real-time data within the last 30 minutes, giving the agent context on when to select this tool. It also provides practical guidance on using 'limit' for token optimization. However, it does not explicitly contrast this with historical reporting tools like ga_run_report or state 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?

Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds a meaningful behavioral dimension by warning that large datasets can consume significant tokens and recommending the 'limit' parameter. This goes beyond the structured annotations and is practically important for an agent invoking the tool.

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

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

The description is compact and well-structured. It front-loads the purpose, follows with an important token warning, and then provides useful examples. Every sentence contributes meaningful information without unnecessary fluff.

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

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

For a tool with 9 parameters, nested objects, and many related sibling tools, the description is somewhat thin. It does not explain output format, pagination semantics, or when to choose this over related report tools. The schema and annotations compensate for parameter details, but the description alone leaves gaps in selection and expected 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 the baseline is 3. The description adds value by listing common dimensions and metrics, which helps the agent choose valid field names for the 'dimensions' and 'metrics' parameters. It also reinforces the 'limit' default behavior, which is already in the schema but given practical emphasis.

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

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

The description clearly states the core action: 'Run a custom Google Analytics report with dimensions and metrics.' This identifies the verb, resource, and scope. It does not explicitly differentiate from sibling report tools like ga_run_realtime_report, ga_run_pivot_report, or ga_run_funnel_report, 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?

The description gives no direct guidance on when to use this tool versus alternatives such as realtime, pivot, funnel, or batch report tools. The token-optimization warning implies careful use for large datasets, but it does not state selection criteria or exclusions. Sibling tool names are available in context, but the description itself does not leverage 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?

Annotations already indicate the tool is non-read-only, non-idempotent, and non-destructive. The description adds the ecommerce event context but does not disclose additional behavioral traits such as authentication requirements, rate limits, or whether user_id versus client_id is required. There is no contradiction with the annotations.

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

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

The description is two short sentences with the key action front-loaded. The second sentence is slightly redundant but adds the valuable ecommerce context, so it earns its place.

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

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

For a send-event tool with a rich nested input schema, the description is adequate but lean. It does not explain the relationship between required fields, the role of user_id/client_id, or what the tool returns, and there is no output schema to compensate. The detailed input schema prevents this from being a lower score.

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

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

Schema description coverage is 67%, so the schema already documents most top-level parameters. The description does not add meaningful semantics beyond what the schema provides; for instance, user_id and client_id remain undocumented, and the description only echoes that items are being added to the cart.

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

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

The description clearly states the action ('Send an add to cart event'), the target ('Google Analytics'), and the specific event type. The second sentence reinforces that this is an ecommerce event for cart additions, which differentiates it from purchase, login, signup, and other sibling event tools.

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 trigger context: use when items are added to a shopping cart, and it identifies the event as ecommerce. It does not explicitly name alternatives like ga_send_event or ga_send_purchase, but the usage context is clear enough to infer the intended scenario.

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

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

The annotations already mark this as non-read-only and non-idempotent, and the description's 'Send' makes the outbound write nature clear. However, the description adds little beyond that—no mention of auth requirements, duplicate-event risk, or the Google Analytics side effects beyond sending the event.

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 that lead with the core action and follow with the event's purpose. There is no filler or redundant detail, and the most important information is front-loaded.

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

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

For a straightforward event-sending tool, the description gives the event type, timing, and purpose. The schema covers the nested item structure and required parameters. It would be improved by noting when not to use it (e.g., use ga_send_purchase for completed checkout), but the description is otherwise sufficiently complete.

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

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

The description provides no parameter-level guidance beyond what the schema already states. With 71% schema coverage, most parameters are documented, but user_id and client_id remain unexplained, and the description does not compensate for those gaps or add meaning to the required fields.

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

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

The description clearly states the action ('Send a begin checkout event to Google Analytics') and supplies the event's purpose ('tracking when users start the checkout process'). This is specific enough to distinguish from sibling tools like ga_send_purchase or ga_send_add_to_cart.

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

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

The second sentence gives clear usage context: use this event when a user starts checkout. It does not explicitly call out sibling alternatives or exclusions, but the timing and event semantics are clear enough for an agent to select it appropriately.

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

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

Annotations already convey that this is not read-only and not idempotent. The description adds meaningful behavioral context: events are processed asynchronously and appear in reports within minutes, helping the agent set expectations about immediate vs delayed effects. It does not contradict any annotation.

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

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

The description is compact, front-loaded, and avoids redundancy. Three short paragraphs each serve a purpose: what the tool does, when to use it, and what behavior to expect.

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 moderately complex tool with four parameters and a rich schema, the description is mostly complete. It covers the purpose, usage, async behavior, and event examples; it could be stronger by explicitly routing to specialized senders, but that is a minor gap given the sibling names.

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 all four parameters. The description adds modest value by listing common event name examples, but it does not substantially expand on user_id, client_id, or user_properties semantics 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 opens with 'Send a custom event to Google Analytics via Measurement Protocol,' a specific verb plus resource. It further clarifies by listing common custom events like click, form_submit, and custom_conversion, which distinguishes this generic sender from specialized siblings such as ga_send_purchase and ga_send_pageview.

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 states 'Use this for tracking custom user actions, conversions, or any GA4 event,' giving clear usage context. It does not explicitly mention when to prefer specialized siblings like ga_send_purchase or ga_send_login, so it stops short of full exclusions/alternatives guidance.

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

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

Annotations already convey that this is a non-read-only, non-idempotent operation. The description adds little behavioral context beyond restating that it sends a login event; it does not mention side effects, requirements, or consequences such as what data is transmitted or whether a successful send returns anything.

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 concise sentences, front-loaded with the core action. No filler, redundant sections, or unnecessary technical detail; the description earns its 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 straightforward event-sending tool, the description plus schema cover the essentials: what it sends and the required method. However, it lacks usage-alternative guidance, behavioral caveats, and any indication of return value or output, leaving moderate ambiguity for an agent selecting among many event-sending siblings.

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

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

Schema coverage is 75%, with client_id left undescribed, and the description does not compensate for that gap. Mentioning 'authentication method' loosely echoes the method parameter, but adds no meaning beyond the schema's existing description of method.

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

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

The description clearly states the specific action and resource: sending a login event to Google Analytics. It identifies the event type as 'login,' which distinguishes it from broader siblings like ga_send_event or ga_send_signup, though it does not explicitly name or contrast them.

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

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

The phrase 'Standard event for tracking user logins' provides clear context for when the tool should be used. It does not explicitly list alternatives or exclusions, but the login-specific framing makes the intended use case obvious among the many send_* siblings.

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

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

Annotations already establish that this is a non-read-only, non-idempotent operation. The description adds a useful behavioral detail by noting that the 'page_view' event name is applied automatically, but it does not elaborate on send-specific side effects beyond what annotations imply. No contradiction with annotations.

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

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

Two sentences with no fluff. The core action is front-loaded, and the second sentence adds the two key pieces of context: standard use case and automatic event name. Every sentence earns its place.

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

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

For a straightforward send-event tool, the description plus a fully documented schema and relevant annotations provide enough to call it correctly. It lacks explicit sibling differentiation and return-behavior information, but no output schema exists and the operation is simple, so the definition is adequate.

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

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

The input schema already provides descriptions for all six parameters, so the baseline is 3. The description does not add parameter-level detail; the only added insight is that the event name is fixed, which is informative but not tied to any specific parameter beyond clarifying why no event_name parameter exists.

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

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

The description clearly states the verb ('Send') and resource ('page view event to Google Analytics'), and characterizes it as the 'standard event for tracking page/screen views.' This makes the tool's purpose immediately obvious, though it does not explicitly contrast it with sibling tools such as ga_send_event or ga_send_purchase.

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

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

The phrase 'Standard event for tracking page/screen views' gives clear guidance on when to use this tool: for page and screen view tracking. It does not, however, explicitly mention alternatives or state when not to use it (e.g., for custom events use ga_send_event), so it falls short of a 5.

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

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

Annotations already convey the safety profile: readOnlyHint=false, idempotentHint=false, destructiveHint=false. The description adds that this is the standard purchase event and carries transaction details, but it does not disclose operational behavior such as authentication needs, error conditions, or downstream effects of sending the event.

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

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

Two sentences with no filler. The action is front-loaded, and the second sentence clarifies the event's standard purpose. Every word earns its place.

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

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

The description is adequate for identifying the tool's purpose, and the schema covers parameter details. However, it lacks explicit guidance on choosing this specialized event over ga_send_event, and with no output schema it does not clarify what an agent should expect in the response.

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

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

Schema description coverage is 82%, and required parameters like transaction_id, value, currency, and items already have descriptions. The phrase 'transaction details and items' maps to those required parameters but adds no new semantic meaning beyond what the schema already provides.

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

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

The description names a specific verb and resource: 'Send an ecommerce purchase event to Google Analytics.' It further distinguishes itself by calling out 'completed purchases with transaction details and items,' which separates it from sibling tools like ga_send_add_to_cart, ga_send_begin_checkout, and ga_send_event.

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

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

The phrase 'Standard event for tracking completed purchases' gives clear context for when the tool should be used. However, it does not explicitly name alternatives or state when not to use it, such as pointing to ga_send_event for non-purchase events or ga_send_refund for returns.

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

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

Annotations already indicate this is a non-read-only, non-idempotent operation; the description adds useful behavioral context by explaining how the event encodes refund type through items. It does not contradict any annotation and provides meaningful detail beyond the structured fields.

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

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

Three sentences with no filler. The core action is front-loaded, and the full/partial refund distinction is delivered in compact, immediately actionable form.

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

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

Given the absent output schema and moderate parameter complexity, the description covers the key invocation decision (full vs partial) and the critical transaction_id constraint. Minor omissions like explicit guidance on optional value/currency handling are adequately covered by the schema descriptions.

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 description clarifies the most important parameter semantics: the conditional role of 'items' in distinguishing full from partial refunds and the requirement to match the original transaction_id. Schema coverage is 71%, and the description meaningfully compensates for the central ambiguity even though it does not elaborate on user_id or client_id.

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: 'Send a refund event to Google Analytics.' It clearly identifies the tool as an ecommerce refund event and distinguishes it from sibling event tools by describing full vs partial refund behavior.

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 usage instructions: omit 'items' for a full refund, include them with quantities for a partial refund, and reuse the same transaction_id as the original purchase. It does not explicitly name alternative tools or when not to use this one, so it stops short of a 5.

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

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

Annotations already establish the side-effect profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false). The description adds the semantic context of a signup event but does not disclose any further behavioral traits such as asynchronous delivery, failure behavior, or authentication requirements.

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

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

Two short sentences, with the primary action and destination front-loaded and the purpose immediately following. No redundancy or filler.

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

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

For a straightforward event-send tool, purpose, parameters, and side-effect profile are mostly covered by the description plus schema/annotations. The lack of an output schema and the undocumented client_id are minor gaps, but the description still gives an agent enough to select and invoke the tool correctly.

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

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

Schema description coverage is 75%, so the baseline is 3; the description itself adds no parameter-level details and doesn't compensate for the undocumented client_id field. It neither clarifies the meaning of method beyond the schema's example nor explains how user_properties are used.

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

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

The description uses a specific verb-resource pair ('Send a sign-up event to Google Analytics') and adds the domain purpose ('tracking new user registrations'), which clearly distinguishes it from sibling tools like ga_send_login, ga_send_purchase, and generic ga_send_event.

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

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

The second sentence gives explicit context for when the tool applies: it is the standard event for new user registrations. It stops short of naming excluded alternatives or explicitly contrasting with ga_send_login and ga_send_event, so it doesn't fully earn a 5.

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

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

Annotations already mark readOnlyHint=false, signaling a state-changing call. The description adds useful context by identifying the event type and funnel position, but it does not disclose any additional behavioral traits such as required identifiers, side effects beyond sending, or rate-limiting considerations. No contradiction with annotations.

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

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

Two short sentences with the core action front-loaded ('Send a view item event') and no filler. The funnel context earns its place by supporting purpose and usage differentiation.

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?

Adequate for a straightforward tracking event given that the schema documents most parameters and annotations convey the mutation profile. However, it omits guidance on the use of client_id vs user_id and does not clarify how to construct the items array beyond what the schema provides. The missing output schema is partially mitigated by the nature of a send event, but the coverage gaps keep it from being complete.

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

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

The description adds no parameter-level meaning; it only names the event. Schema description coverage is 67%, leaving user_id and client_id undocumented in both the schema and the description. Since the description does not compensate for these gaps or enrich the semantics of the existing parameters, it provides minimal value beyond the input schema.

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

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

States a specific verb and resource: 'Send a view item event to Google Analytics.' Further clarifies it as an ecommerce event for tracking product/item detail views and places it in the standard funnel (view_item → add_to_cart → begin_checkout → purchase), which clearly distinguishes it from sibling send_add_to_cart, send_begin_checkout, and send_purchase tools.

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

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

Provides clear context: this is for product/item detail views and is the first step in the standard ecommerce funnel. It implies when to use it relative to the other send_* event tools, but it does not explicitly name alternatives or state when not to use it, so it stops short of full routing guidance.

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

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

Annotations already cover read-only/idempotent/non-destructive behavior. The description adds valuable behavioral detail: it uses the debug endpoint, does not record the event, and returns validation messages/errors. No contradiction with annotations.

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

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

Three concise sentences, front-loaded with the primary purpose, followed by mechanism and return value. Every sentence earns its place.

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

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

For a validation tool with strong annotations and a nested input schema, the description covers purpose, non-destructive behavior, and return value. Some parameter semantics are thin, but the schema plus standard GA field names make the tool callable. An output schema would have helped, but the description states the return enough for selection.

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

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

With only 25% schema description coverage, the description needed to compensate, but it adds no information about user_id, client_id, user_properties, or the structure of the events array beyond generic 'event.' The schema supplies some details, but the description doesn't bridge the gap.

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

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

States a specific verb and resource: 'Validate an event before sending it to Google Analytics.' It also names the mechanism (GA4 debug endpoint) and explicitly distinguishes itself from send tools by noting it checks without recording the event.

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: use before sending an event to verify errors without recording it. It doesn't explicitly name alternatives such as ga_send_event or state when not to use it, so it stops short of a 5.

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