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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds value beyond that with the compatibility caveat, which is a genuine behavioral limitation not captured in annotations. It is concise but meaningful.

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 first states what the tool does, the second states a critical limitation. Both sentences earn their place, and the key verb-resource pair 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?

The description covers purpose and the principal caveat, and rich annotations handle the safety profile. But gaps remain: the limit parameter is unexplained, and the boundary with ga4_list_custom_dimensions is not drawn, which matters since both tools touch custom definitions.

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

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

Schema description coverage is 0%, so the description carries the full burden for parameter meaning. It only implicitly references propertyId ('for a property') and says nothing about the limit parameter, leaving its semantics entirely to inference. The description does not compensate for the schema 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?

The description uses a specific verb ('Discover') and names the resource precisely: valid GA4 field names, descriptions, and custom definitions for a property. It clearly positions the tool as a pre-reporting metadata lookup. However, it does not differentiate from the sibling ga4_list_custom_dimensions, and the mention of 'custom definitions' partially overlaps with that sibling's purpose.

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?

'before reporting' provides clear contextual guidance on when to call this tool, and the caveat 'Does not guarantee every combination is compatible' tells the agent not to treat returned fields as freely combinable in report queries. It stops short of explicitly naming alternatives or exclusion conditions.

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 destructiveHint=false, and the description reinforces this with 'Read-only.' It adds useful context beyond the annotations by stating the authentication scope ('accounts the authenticated user can see') and describing the return content (account name, display name, property ID and display name), which is valuable since no output schema is present.

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 efficiently deliver purpose, usage guidance, and return fields with zero filler. The most important instruction ('Use this FIRST to discover propertyId') is front-loaded in the second sentence, and every clause 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 simple list tool with two optional parameters and no output schema, the description covers the purpose, the discovery workflow, and the returned fields. It also confirms read-only behavior. Nothing an agent needs to call this tool correctly is missing.

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

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

Schema description coverage is 100%, so both parameters (limit, pageToken) are fully documented in the input schema with their own descriptions. The tool description does not add parameter-specific semantics, which is acceptable given the schema already handles the heavy lifting. 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 states a specific verb ('Lists'), resource ('every Google Analytics account ... with the properties under each'), and scopes the operation to what the authenticated user can see. It also names the primary use case (discovering propertyId), distinguishing it from sibling GA4 reporting and management 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?

It explicitly tells the agent to use this FIRST to obtain the numeric propertyId that other GA4 tools require, providing clear when-to-use context. It does not offer explicit when-not-to-use guidance or name alternatives, but the 'FIRST' instruction and relation to other tools are strong directional cues.

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 destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context: it returns parameter name, display name, and scope, and it is read-only. It doesn't mention pagination behavior, but the schema already documents pageToken and nextPageToken, so the description doesn't need to repeat it.

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 purpose is front-loaded, the returned fields are listed, and the use case is stated. 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 read-only list tool with full schema coverage and safety annotations, the description is nearly complete. It could mention that the response is paginated, but the schema already covers pageToken and nextPageToken. The only minor gap is not describing the response shape, but no output schema exists and the description lists the key fields returned.

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 three parameters. The description adds the note that propertyId can be discovered via ga4_list_account_summaries, which is helpful, but it doesn't add much beyond the schema. 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 ('Lists'), a specific resource ('custom dimensions configured on a GA4 property'), and the key fields returned (parameter name, display name, scope). It also distinguishes itself from ga4_run_report by noting it's useful before referencing dimensions in that tool. This is a clear, specific purpose that an agent can act on.

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

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

The description says it's useful for discovering which custom dimensions exist before referencing them in ga4_run_report, which gives a clear when-to-use context. It doesn't explicitly say when not to use it or name alternatives like ga4_get_metadata, but the context is sufficient for most cases.

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 meaningful context beyond that: it discloses the response contents (counting method and deletability) and clarifies terminology (formerly 'conversions'). 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 a single, efficient sentence that front-loads the action ('Lists key events') and includes only necessary context. No filler or redundant phrases.

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?

Without an output schema, the description compensates by indicating what fields will be present (counting method, deletable flag). Combined with the 100% parameter documentation and annotations covering safety, it gives an agent enough to call the tool correctly. It does not specify, for example, sorting or total count, but these are not essential for a list 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?

Schema description coverage is 100%, and each parameter already has detailed descriptions (limit default, pageToken purpose, propertyId format). The tool description does not add further parameter-level meaning, 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 states a specific verb ('Lists'), a precise resource ('key events on a GA4 property'), and includes clarifying details (formerly 'conversions', counting method, deletable flag). This clearly differentiates it from sibling tools like ga4_list_custom_dimensions or ga4_list_account_summaries.

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: it is a read-only listing operation for a GA4 property's key events. Parameter descriptions add practical guidance, such as using ga4_list_account_summaries to find the property ID and preferring to narrow the query over raising the limit. It doesn't explicitly name alternatives or when-not conditions, but the context is sufficient.

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

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

Even with readOnly/idempotent annotations, the description adds behavioral details beyond them: the ~30-minute window, the schema-subset failure mode ('date', 'sessionSource' and most session-scoped fields are unavailable and will error), and the numeric-propertyId requirement. These are actionable warnings an agent would not get from annotations or schema 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 front-loaded with the core behavior and contains five focused sentences, each earning its place: the time window, propertyId prerequisite, schema-subset warning, common fields, and the sibling alternative. No filler or repetition.

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 GA4 tool with no output schema, the description covers the parameter requirements, the real-time limitations, the alternative for older data, and the sibling for finding the property ID. There are no missing prerequisites or constraints needed to invoke it correctly; output format can be inferred from the response and is not a blocker to correct use.

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 already fully documents all four parameters, but the description still adds meaning: it explains how to find propertyId (via ga4_list_account_summaries), warns that only a subset of dimensions is valid, and lists common realtime dimensions and metrics beyond the schema examples. This is meaningful value on top of a 100%-covered 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 a clear verb-resource statement: 'Returns activity from roughly the last 30 minutes.' It also distinguishes itself from the closest sibling by saying 'For anything older than 30 minutes use ga4_run_report instead,' so an agent can choose correctly without inspecting schemas.

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 states when to use the tool (activity within roughly the last 30 minutes), when not to use it (older activity should use ga4_run_report), and how to find the required property ID via ga4_list_account_summaries. This is strong when/when-not guidance that prevents common errors.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description confirms this with 'Read-only'. It adds meaningful behavior beyond annotations: the default 25-row cap to protect the context window, the flat-object return shape, and the preference for narrowing queries. This is a good level of disclosure for a read-only reporting 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 front-loaded: it states the action and output, then the most important requirement, then the limit behavior. Every sentence earns its place, and the 'Read-only' tag is a useful closing confirmation. No filler or redundant boilerplate.

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

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

For a complex 11-parameter tool with no output schema, the description covers the critical pitfalls: numeric propertyId, default row limit, output shape, and query-narrowing guidance. The schema covers the remaining parameter details. It is not a 5 because it leaves the boundary with ga4_run_realtime_report implicit, which could matter in tool 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?

Input schema coverage is 100%, so the baseline is 3. The description adds value beyond the schema by giving a concrete method to find the numeric propertyId (digits after 'p' in the GA4 URL and the Admin path), which is the most error-prone parameter. It slightly repeats the limit guidance already present in the schema, but this is harmless reinforcement.

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: it runs a Google Analytics 4 report and returns rows as flat objects. It stops short of a 5 because it does not explicitly differentiate itself from the sibling ga4_run_realtime_report, and 'GA4 report' is broad enough to overlap with the realtime variant.

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 useful practical guidance: it emphasizes the numeric propertyId requirement, shows where to find it, and advises narrowing the query instead of raising the 25-row limit. However, it does not explicitly state when to choose this tool over ga4_run_realtime_report or other siblings; the selection context is only implied by the emphasis on date ranges.

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 readOnly, idempotent, openWorld, and non-destructive behavior. The description adds valuable behavioral context beyond that: it will not expose tokens or client secrets, does not guarantee access to properties, and never initiates browser sign-in. 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 short sentences with no filler. The core purpose is front-loaded, and the caveats are relevant and compact.

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 diagnostic tool with annotations and no output schema, the description covers what the tool checks, what it avoids exposing, and its limits. It could briefly state the return shape, but this is a minor gap given the tool's simplicity.

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, so the schema imposes no burden. The description appropriately focuses on behavior instead of inputs, and no parameter-level explanation is needed.

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

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

The description uses a specific verb and resource: 'Check credential availability and read/write mode.' This clearly distinguishes the diagnostic tool from data-facing siblings like ga4_run_report or gsc_search_analytics_query.

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 this tool is for checking connection state and operational mode before or instead of relying on access assumptions. It does not explicitly name alternatives or exclusion conditions, but 'Does not guarantee access to any particular property' and 'Never starts browser sign-in' help agents know what it will not do.

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

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

Beyond the readOnlyHint/idempotentHint annotations, the description usefully discloses that it makes two read requests, uses final data, and returns null percentage change for zero baselines. This adds behavioral context the annotations alone do not provide.

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 dense sentences with no filler. The core comparison purpose is front-loaded, followed by return semantics and the two-request behavior. 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?

With no output schema, the description still explains what is returned (click/impression changes, CTR percentage-point change) and an edge case (zero baselines). It is sufficient for an agent to select and invoke the tool correctly, though a bit more detail on response structure would be ideal.

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?

Input schema coverage is 100%, so the schema already documents each parameter. The description adds the equal-length/non-overlapping relationship between the two date-range parameter groups, but does not need to explain individual parameters further.

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 action ('Compare'), resource ('Search Console web-search totals'), and scope ('two equal-length, non-overlapping date ranges'). This clearly distinguishes it from single-period siblings like gsc_search_analytics_query, even without explicitly naming 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 description gives clear selection context: equal-length, non-overlapping ranges, web-search scope, and final data. It does not explicitly list when to prefer an alternative tool, but the constraints strongly imply the intended 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=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds operational context beyond annotations: the per-property daily and per-minute query quota and the warning about quota exhaustion in loops. 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 compact and front-loaded, with the primary output listed first and usage/quota guidance following. Minor redundancy: 'Read-only.' repeats the readOnlyHint annotation, so not every token adds new 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?

With no output schema present, the description enumerates the key returned categories and clearly scopes the tool to a single URL. Combined with fully documented parameters and strong annotations, this is nearly complete; it just doesn't detail response types or error conditions, though those are less critical for a read-only inspection 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 all parameter meanings are already documented in the schema. The description does not add new parameter-level syntax or format details beyond the schema; therefore the 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?

Opens with a specific verb and resource: 'Returns Google's index status for a single URL,' then enumerates the exact verdict categories returned (coverage, crawl time, canonical, mobile usability, rich results). It also distinguishes itself from gsc_search_analytics_query by making the per-URL vs aggregate split 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?

Explicitly tells agents when to use it ('inspect specific URLs the user asked about') and when not to ('do not loop this over a list of URLs'). It names the preferred alternative for aggregate queries and warns about quota limits before looping.

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 destructiveHint=false, so the safety profile is covered. The description adds useful context about what the call actually provides, such as warning/error counts and per-type indexed counts, which goes beyond the annotations.

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

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

The description is two sentences with no wasted words. The core action and output are front-loaded, and the usage guidance earns the second sentence.

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, the description is complete enough: the schema covers the parameters and annotations cover safety, while the description outlines return fields and a use case. With no output schema, a little more detail on response shape would push it to a 5, but nothing essential is missing.

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

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

Schema description coverage is 100%, and the schema already explains both parameters, including the exact siteUrl source and the limit default. The description adds little about the parameters themselves, so a 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: 'Lists sitemaps submitted for a Search Console property.' It also names the kind of data returned (last-downloaded time, warning and error counts, indexed counts), which clearly separates it from sibling tools like gsc_list_sites or gsc_inspect_url.

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 use case: 'Useful for diagnosing indexing problems.' It does not name explicit alternatives or when-not-to-use guidance, so it stops short of a 5, but the stated purpose makes the intended context 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 readOnly, idempotent, and non-destructive behaviorched. The description adds value beyond that by mentioning the returned permission level and warning that URL format matters. However, it omits that the limit parameter defaults to 25, which can contradict 'Lists every' when a user has more properties.

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 compact, information-dense sentences. The first states the core action, the second gives crucial usage guidance, and the third reinforces safety. No unnecessary fluff beyond a brief 'Read-only' that is already in 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 one-parameter tool, the description is largely complete: it states the output includes permission levels and explains why the siteUrl format matters. A small gap is that it does not disclose the default 25-row limit or possible pagination, which is relevant to the 'Lists every' claim.

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 limit is fully documented in the schema, including its default and rationale, so the description does not need to repeat it. The description adds no additional parameter meaning, making the baseline 3 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 clearly states the tool lists every accessible Search Console property with permission level. It even highlights the significance of the exact siteUrl format, distinguishing this discovery/list tool from other GSC tools like search queries, sitemaps, and URL inspection.

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 advises using this tool FIRST to retrieve the exact siteUrl string needed by other Search Console toolsikuha. It does not name a direct alternative or when-not-to-use, but for a site-list discovery tool, this is strong contextual 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 carry readOnlyHint, idempotentHint, and openWorldHint, and the description reinforces this with 'Read-only.' Beyond that, it discloses important behaviors the annotations cannot convey: data lags 2-3 days, dataState='all' surfaces fresh partial data, the default 25-row cap versus the API's 25,000 limit, the explicit warning not to assume full results, and offset-based paging. This is substantial behavioral context added on top of 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?

Every sentence earns its place: purpose first, then the primary-tool designation, then prerequisites, date constraint, lag/freshness, row-limit warning, paging, and a closing 'Read-only.' The most critical constraints (exact siteUrl, date format) are front-loaded. No filler or repetition of schema 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 complex 10-parameter tool with no output schema, the description covers the essentials well: it states return metrics, grouping behavior, prerequisites, date format, data lag, and pagination limits. The only notable gap is the precise response row structure (how grouped results are keyed/serialized), which the description only hints at via 'grouped by the dimensions you choose'. Given the absent output schema and tool complexity, slightly more return-format detail 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?

Schema coverage is 100% and the schema itself is unusually rich (each parameter has meaningful prose, e.g., limit's 'protect the context window' and startRow's 'offset, not a page token'). On the baseline-3 for full coverage, the description adds genuine semantic linkage: it connects dataState to the data-lag problem and reframes limit as a truncation risk that agents must deliberately raise. This goes slightly beyond what the schema states.

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 ('Returns'), a specific resource (Search Console performance data), and the exact metrics returned (clicks, impressions, CTR, average position). It distinguishes itself from the GA4 siblings by noting relative dates are unsupported 'unlike the GA4 tools' and declares itself 'the primary SEO analysis tool', clearly differentiating it from the ga4_run_report and gsc_compare_periods 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 provides strong contextual guidance: it declares itself the primary SEO tool, requires siteUrl to come from gsc_list_sites, warns that relative date forms are not supported (unlike GA4), and instructs to page with startRow and raise limit deliberately. However, it never explicitly states which sibling to use instead in any given scenario (e.g., when to prefer gsc_compare_periods or ga4_run_report), so the when-not-to-use routing is left implicit.

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

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

Annotations already cover read-only, idempotent, and non-destructive aspects. The description adds two critical behavioral notes: configuration is not proof of tag firing, and the response may be large. These go beyond what annotations provide and help the agent interpret the result correctly.

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 sentences with no redundancy. The core purpose is stated first, followed by a caution and a size warning. 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 simple read-only tool with one parameter and no output schema, the description covers the purpose, key caveats, and usage hints. It does not describe the response structure, but given the nature of the tool (returning a full container), this is not a significant gap. The description is complete enough for an agent 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?

Schema coverage is 100% for the single 'path' parameter, which is already described as 'accounts/{account}/containers/{container}'. The description only adds a reiteration to choose a specific container, which does not add substantial new meaning beyond the schema. 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 states a specific verb ('Read') and resource ('the full currently published GTM version'), which is unambiguous. It clearly distinguishes from siblings like gtm_preview_version by using 'currently published' and 'live' in the title. The phrase 'choose a specific container' also clarifies the scope of the operation.

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 usage hint: 'choose a specific container' implies that the path parameter must identify a container, and it warns about large containers. However, it does not explicitly state when to use this tool versus alternatives (e.g., 'use this for published config, not preview'). The guidance is implicit but useful.

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 destructiveHint=false, so the safety profile is covered. The description adds useful context beyond annotations by noting the scope is 'every Google Tag Manager account the authenticated user can access' and that it is the entry point for discovering accountId.

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 deliver function, usage ordering, and safety in a front-loaded way. There is no filler or repetition of schema details.

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 operation with no required parameters, the description gives the agent everything needed: what it lists, that it is the first step, and that it yields accountId. The absence of an output schema is mitigated by the explicit mention of discovering accountId.

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 (limit and pageToken) are already fully documented in the schema. The description does not add parameter-level detail, but the baseline of 3 is appropriate because the schema carries the explanatory burden.

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: 'Lists every Google Tag Manager account the authenticated user can access.' It also distinguishes this tool from sibling tools by placing it first in a clear sequence (gtm_list_containers, gtm_list_workspaces), so an agent can tell what it is for.

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 usage direction: 'Use this FIRST to discover accountId, then gtm_list_containers, then gtm_list_workspaces.' This tells the agent exactly when to invoke this tool and how it fits into a larger workflow, leaving little 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?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds genuinely useful behavior beyond structured data: the response contains two distinct IDs, publicId versus containerId, and only the numeric containerId is usable by other GTM tools. This is important behavioral context not present in annotations or schema.

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

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

The description is three sentences and front-loads the core action before the prerequisite and the high-value ID warning. The only waste is the final 'Read-only,' which merely restates the readOnlyHint annotation, so it does not quite earn a 5.

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

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

For a read-only list tool with no output schema, the description covers the two most important operational facts: the prerequisite accountId discovery and the ambiguity between containerId and publicId. Pagination and limit behavior are already documented in the schema, and the safety profile is covered by annotations. It is sufficient for correct invocation without needing full response-shape 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 description coverage is 100%, and the schema already documents accountId with/without prefix, limit defaulting, and pageToken. The description does not add new parameter-level semantics, only reinforcing the containerId warning that mostly matters for interpreting the response. Baseline 3 is appropriate because the schema carries the parameter documentation burden.

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 'Lists containers in a Tag Manager account,' a specific verb and resource with no ambiguity. The prerequisite mention of gtm_list_accounts and the focus on containerId clearly distinguish it from sibling list tools like gtm_list_workspaces or gtm_list_tags.

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 instructs the agent to call gtm_list_accounts first to obtain accountId, establishing the correct invocation sequence. It also warns to pass the numeric containerId rather than publicId, which is direct guidance for downstream use. It does not name explicit alternatives or state when not to use the tool, 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 declare readOnlyHint, idempotentHint, and destructiveHint=false, so the description correctly reinforces 'Read-only.' It adds behavioral value beyond the annotations by stating that 'Parameters are condensed to key/value pairs for readability,' which tells the agent what to expect in the output format.

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 the core purpose first, then input selection, then output formatting, then safety. Every sentence contributes, and there is no fluff or repetition of schema detail beyond what is useful.

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 list tool with an annotated safety profile and complete schema documentation, the description covers the essential context: what is returned, how to identify the workspace, and output transformation. Pagination details live in the schema's pageToken description rather than the tool description, which is acceptable.

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 each parameter is already well-documented in the input schema. The description restates the path-vs-IDs alternative but does not add substantial meaning beyond the schema's own descriptions.

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

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

The description begins with a precise verb and resource: 'Lists tags in a Tag Manager workspace', and goes on to enumerate the returned attributes (type, firing triggers, parameters). This clearly distinguishes it from sibling list tools targeting accounts, containers, workspaces, triggers, and variables.

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 explains the accepted workspace identifiers ('full workspace path or accountId + containerId + workspaceId'), which is useful context, but it never says when to choose this tool over gtm_list_triggers or gtm_list_variables. Usage has to be inferred from the tool name and sibling list.

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, covering the safety profile. The description adds that the output includes type and firing conditions, which is a minor behavioral detail, but it does not disclose pagination behavior or return format beyond that. Since annotations carry most of the burden, this is adequate but not rich, warranting a 3.

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 sentences with no filler. The core purpose is front-loaded, and the alternative addressing modes are stated efficiently. Every clause earns its place, making it a model of concise structure.

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 6 parameters (0 required) with full schema coverage and no output schema, the description covers the essential purpose, the two addressing modes, and the read-only nature. It hints at the output content (type and firing conditions) but does not detail pagination or the exact return shape. However, the schema documents limit and pageToken, and the tool is a simple list operation, so the description is largely 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 schema description coverage is 100%, so all parameters are documented. The description adds value by clarifying that `path` is an alternative to the combination of `accountId`, `containerId`, and `workspaceId`, which is a relationship not evident from the schema alone. This helps the agent understand the parameter grouping and choose the right addressing mode.

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 ('lists triggers') and the resource ('a Tag Manager workspace'), and specifies the output fields ('type and firing conditions'). It distinguishes itself from sibling tools like gtm_list_tags and gtm_list_variables by naming the specific resource (triggers). The alternative addressing modes are also mentioned, making the purpose 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?

The description provides context that this is a read-only listing tool but does not explicitly state when to use it over siblings (e.g., when you need trigger definitions vs. tags or variables). The purpose implies usage, but there is no explicit 'use this when...' or exclusion guidance, so it falls at the 'implied usage' level.

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. The description adds value beyond them by disclosing that only user-defined variables are returned, that built-ins are excluded, and that results include type and parameters. It also repeats the read-only nature, which is not a contradiction and reinforces safe usage.

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, each earning its place: the core purpose, the critical built-in vs user-defined distinction, and the targeting options. The main action is front-loaded with no filler or repetition.

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 list tool, the safety profile is fully covered by annotations and the six-parameter schema is rich, including paging and default limit details. The description adds the main caveat (user-defined only) and expected response content. The only minor omission is not naming the exact collection/tool to use when built-in variables are needed, but this is not a blocking 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 schema already explains the path alternative, numeric containerId format, opaque pageToken, and limit default. The description's mention of 'path or accountId + containerId + workspaceId' only restates what the schema encodes without adding new parameter-level semantics. 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 opens with a specific verb and resource: 'Lists user-defined variables in a Tag Manager workspace with their type and parameters.' It also explicitly separates user-defined variables from built-in variables, preventing scope confusion and clearly distinguishing the tool from siblings like gtm_list_tags and gtm_list_triggers.

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: this tool returns only user-defined variables and notes that built-in variables are a separate collection, signaling when not to use it. It also states the two accepted ways to target a workspace—full path or the three IDs. It does not name a concrete sibling tool for built-ins, but the exclusion and targeting options are explicit enough.

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

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

Even with readOnlyHint, idempotentHint, and destructiveHint already declared, the description adds meaningful behavioral context by stating that writes operate on workspaces and never on the live container. The explicit 'Read-only' tag matches the annotations and creates no contradiction.

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

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

The description is compact and front-loads the purpose in the first sentence. The final 'Read-only' is slightly redundant with the annotations, but the overall size is appropriate and 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 list tool with five optional parameters and no output schema, the description covers the essential call patterns (path vs split IDs), safety semantics, and read-only behavior. Pagination behavior is left to the schema's pageToken and limit descriptions, which is acceptable.

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. The description's sentence about 'path or accountId + containerId' restates the relationship already documented in the schema; it does not introduce new semantic detail beyond an efficient summary.

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 'Lists workspaces in a container' is a specific verb+resource statement that clearly identifies the operation. The added context about workspaces being the safe editing surface helps distinguish this from sibling tools like gtm_list_containers and gtm_get_live_version.

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 for why an agent would call this tool: workspaces are the safe editing surface and all writes target a workspace, not the live container. It does not explicitly name alternatives or when-not-to-use cases, but for a simple list tool the context is sufficient.

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

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

Annotations already cover readOnly, idempotent, and non-destructive behavior English, but the description adds meaningful behavioral context: it compares by stable entity IDs, includes modified fields, and explicitly says the server cannot publish. This goes beyond simply repeating the annotations and clarifies side-effect constraints.

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 three short sentences, front-loaded with 'READ ONLY' and the core comparison purpose. Every sentence adds useful information: what it compares, how it compares, what it cannot do, and when to use it. There is no wasted wording.

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, read-only comparison tool, the description fully covers selection and invocation. It explains the operation, the comparison basis, the side-effect boundary ('cannot publish'), and the intended context ('before publishing'). No output schema is present, but the description's 'including modified fields' and 'full changes' sufficiently indicate what will be returned.

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%; the single parameter versionPath is fully described with a pattern and format. The description adds the 'candidate version' semantic but does not need to explain the parameter further. Baseline 3 is appropriate because the schema carries the parameter documentation burden.

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 ('Compare') and specific resources ('candidate version' vs 'live version'), and explains the comparison basis ('stable entity IDs and configuration', 'including modified fields'). This differentiates it from siblings like gtm_get_live_version, which likely just fetches the live version rather than diffing against a candidate.

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 frames this as a pre-publishing review step: 'Review full changes in Google Tag Manager before publishing there.' It also states what the tool does not do ('This server cannot publish'), which is a useful exclusion. However, it does not explicitly name alternative tools or conditions for choosing them, 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.