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

Annotations already declare readOnlyHint=true, so safety needs no explanation. The description adds the useful 'newest first' ordering and the fact that snapshots are local (slightly at odds with openWorldHint=true, though not a direct contradiction). It says nothing about pagination behavior, whether 'limit' truncates silently, or what a snapshot record contains.

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, zero filler, with the ordering guarantee and the ID format both front-loaded where an agent will read them.

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

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

For a simple read-only list tool with no output schema, the description covers resource, ordering, and the trickiest parameter's format. Missing only the filtering semantics (does 'id' scope the list?) and how 'limit' behaves at the boundary, which keeps it short of 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 only 33%, so the description must compensate; it partially does by explaining the exact 'id' format for both GA4 property IDs and GTM '<accountId>-<containerId>'. The 'platform' enum and the 'limit' default are left to the schema, and the interaction between 'id', 'platform', and 'limit' is never clarified.

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 ('Lists the local snapshots') plus ordering ('newest first'), which is more than the title's 'List backups'. It implicitly separates itself from backup_read, but never names that sibling, so an agent must infer the list-vs-fetch split.

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

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

Usage is only implied: the presence of an 'id' parameter and a sibling backup_read suggest 'list here, then read details there', but the description never says when to use this versus backup_read or whether omitting 'id' lists across all properties. No exclusions or prerequisites are stated.

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

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

readOnlyHint=true already declares the safety profile, so the description only needs to add context. It adds the path provenance and the intended downstream uses, but says nothing about what happens with a stale/missing path, whether reads are full-document or lazy, or how large snapshot payloads behave.

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 compact sentence with the key constraint (path comes from backup_list) front-loaded and the use cases trailing. Efficient, though the parenthetical-plus-em-dash construction makes it slightly harder to parse at a glance.

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 two-parameter read tool with full schema coverage and annotations declaring read-only behavior, the description covers what is needed to invoke it. The only gap is that with no output schema, the shape of the returned snapshot is left implicit.

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 are already documented, including a concrete path example and dot-path semantics for select. The description adds genuine provenance meaning for path (where to obtain it) but nothing about select, so it sits at the schema baseline plus a small increment.

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 ("Reads a snapshot") and implicitly contrasts with the listing sibling by saying the path comes "from backup_list". An agent can tell this is the fetch-by-path counterpart to backup_list, though "basis for comparison or restoring" is a little fuzzy about what the read actually yields.

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

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

Gives concrete when-to-use context (comparison, restoring) and, more usefully, tells the agent where valid paths originate: backup_list output or the backup field of a write action. No explicit exclusion or error-condition guidance, but the prerequisite chaining is clear.

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

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

Annotations already flag destructiveHint=true and openWorldHint=true, but the description adds a genuinely non-obvious safeguard: without confirm=true a DELETE only previews current state and deletes nothing, and it tells the agent that path is relative to the API version. This is exactly the kind of dry-run mechanics an agent cannot infer from annotations or schema, and it does not contradict 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?

One dense paragraph that front-loads the purpose and the escape-hatch rule, then earns its list of examples since path shapes are the hardest part of driving an arbitrary pass-through tool. The confirm caveat is placed last rather than up front, which slightly buries the most safety-critical 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?

There is no output schema, so the description carries the burden of telling the agent what comes back — it never says the response is raw API JSON, nor how errors or pagination on GET are surfaced. For a high-blast-radius generic mutation tool it covers method/path/confirm well but leaves the return and failure story unstated.

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

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

Schema coverage is already 80% (path, body, confirm, apiVersion all documented), so the baseline is 3. The description adds real meaning on top: path syntax including query strings (the updateMask example), which methods pair with which endpoints, and that the path is relative to the API version — details the schema only gestures at.

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 (arbitrary call) and resource (GA4 Admin API at analyticsadmin.googleapis.com), and explicitly scopes it to 'anything without its own tool', which routes the agent away from siblings like ga4_list_properties, ga4_create_key_event, or ga4_update_data_redaction. The concrete path examples make the intended usage unmistakable.

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 clause 'for anything without its own tool' is an explicit fallback rule that tells the agent to prefer dedicated tools first, and the four method/path examples show the shape of eligible calls. It stops short of naming specific alternative tools or listing when NOT to reach for it (e.g. bulk reporting, which belongs to ga4_run_report).

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. Beyond that, the description usefully discloses the return content (who/what/when plus state before/after) and that changes made directly in the GA4 UI are captured, which matters for interpreting audit results. It also notes pagination via pageToken, though it omits the fact that GA4 change history is time-bounded and that pageSize defaults to 25.

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 the core payload description front-loaded, then the time format, then pagination. No filler. The 'incl.'/'incl.' abbreviations and the parenthetical are slightly cryptic but the density is appropriate for an audit 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 an 8-parameter tool with no output schema, the description covers what is returned in prose and the time format, but leaves filter semantics, retention window, and default/max page behaviour unexplained. An agent can call it, but may apply filters incorrectly or misinterpret empty 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 only 38% across 8 parameters, so the description has to compensate and it partly does: it supplies the RFC3339 format with an example for earliestChangeTime/latestChangeTime, which the schema leaves undocumented, and explains pageToken's continuation role. It says nothing about how actions, actorEmails, and resourceTypes filters combine (AND vs OR) or about their allowed values, leaving several undocumented parameters unexplained.

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 retrieval scope: who changed what on the GA4 property, when, plus before/after state. That distinguishes it from reporting tools like ga4_run_report and from ga4_list_annotations, though it never names an alternative explicitly. The 'who changed what ... and when' framing identifies the resource (change history) clearly enough to select correctly.

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

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

There is no explicit when-to-use or when-not guidance, and no mention of sibling tools such as ga4_list_annotations, which an agent could easily confuse with this audit-log tool. Usage is only implied by the phrase 'change history'. The '(including in the GA4 UI)' parenthetical hints at coverage scope but is not framed as a selection criterion.

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 the read-only and open-world profile, and the description adds real behavioral detail beyond them: the compatible=false outcome, that 'requested' identifies the problematic field, and that listAddable=true expands the result with all addable fields. It does not explain error conditions or rate limits, so a 4 rather than 5.

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

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

Three tight sentences, zero filler. Scope and rationale come first, followed by the two response-mode behaviors, each earning 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 carries the burden of explaining return values, and it does so for the two key modes (compatible/requested and listAddable). Given six parameters with one required and nested filter objects, it is largely complete, though it could clarify defaults when metrics/dimensions are omitted.

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 67%, with property and filter parameters documented in the schema. The description adds meaning for listAddable beyond the schema's bare 'Default false', but says nothing about metrics, dimensions, or the metricFilter/dimensionFilter semantics beyond the schema's own note.

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 — checks whether dimensions and metrics fit together in one ga4_run_report — and explicitly names the sibling tool whose inputs it validates. An agent can immediately distinguish it from ga4_run_report or ga4_get_metadata.

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 use by tying the check to ga4_run_report and noting 'not every combination is allowed', which implies a pre-flight validation role. It does not explicitly say 'call this before ga4_run_report' or state exclusions, so it falls short of the 5 bar.

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=false, destructiveHint=false and openWorldHint=true. The description adds genuinely non-obvious context beyond that: ORANGE is reserved for Google (explaining why the color enum omits it) and that later edits/deletes must go through ga4_admin_request, which usefully signals the created marker is not managed by this 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?

Front-loaded with the action and effect, then the two structural facts an agent needs (date vs range, color reservation). The telegraphic style ('One day (date) or a range (date + endDate)') is efficient rather than wasteful, though slightly clipped.

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 6-parameter write tool with no output schema, the description covers purpose, date-range semantics, a hidden color constraint, and the follow-up path for modification. Missing only auth/property-permission expectations and any note on what the created annotation identifier looks like.

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 83%, so parameter meaning is largely carried by the schema itself. The description reinforces the date/endDate pairing and supplies example titles, but adds no format or validation detail beyond what the schema already 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?

States a specific verb and resource ('Creates an annotation') and explains the observable effect: it appears in GA4 reports as a marker. Concrete example titles ('Relaunch', 'GTM: Consent Mode v2 live') make the resource unambiguous against siblings like ga4_list_annotations or ga4_admin_request.

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 a clear condition for one-day versus ranged annotations ('One day (date) or a range (date + endDate)') and explicitly routes delete/modify operations to ga4_admin_request. It stops short of naming ga4_list_annotations as the read counterpart or stating prerequisites such as required property permissions.

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=false, destructiveHint=false and openWorldHint=true, so the mutation and safety profile is covered structurally. The description adds essentially nothing beyond that: it does not mention that a created dimension's scope is immutable, that GA4 enforces a per-property cap on custom dimensions, or that the change propagates with delay — all material facts for a create 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?

A single front-loaded sentence with no filler or repetition. It is appropriately sized for what it conveys, though the same brevity is what leaves the usage and behavioral gaps.

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

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

For a five-parameter, three-required mutation tool with no output schema, the definition should say more: whether the created dimension is returned, whether scope can be changed later, and how to verify success. The presence of ga4_list_custom_definitions as a sibling makes the missing pre-check guidance a real omission.

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

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

Schema description coverage is 80%, so the schema already explains property ID formats, displayName and parameterName examples. The description's phrase 'event/user/item parameter' loosely mirrors the scope enum and confirms the parameter-name linkage, but adds no new semantics such as the immutability of scope or naming constraints. 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 gives a specific verb and resource ('Creates a custom dimension') and scopes it to event/user/item parameters, which tells an agent it is not the same as ga4_create_custom_metric or ga4_list_custom_definitions. It stops short of explicitly naming those siblings, but the create-vs-list and dimension-vs-metric distinctions are inferable.

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

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

No when-to-use guidance is given: nothing tells the agent to check ga4_list_custom_definitions first to avoid duplicates, when to prefer ga4_create_custom_metric, or what prerequisites (admin access on the property) are required. Usage is only implied by the verb.

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=false, destructiveHint=false and openWorldHint=true, so the mutation and external-visibility profile is covered. The description adds that scope is fixed to 'event', narrowing behavior beyond the schema, but says nothing about whether the metric becomes active immediately, whether it can be removed afterwards, or which permissions the caller needs.

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?

One front-loaded sentence with zero filler; the constraint on the parameter type appears before any secondary detail. It is efficient but perhaps too terse for a mutation tool with five parameters.

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

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

For a five-parameter write operation with no output schema and only 40% parameter coverage, the description omits return shape, preconditions, and post-creation state. The annotation set covers safety hints, but the agent still lacks enough to invoke this confidently or to recover from failure.

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 40%, below the compensated threshold, so the description must carry more weight. It does add the key constraint that parameterName must refer to a numeric event parameter and that scope is not configurable, but it says nothing about description, displayName, or the measurementUnit enum that the schema documents only as 'Default STANDARD'.

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 ('Creates a custom metric') plus a scope constraint ('event scope') and a precondition ('for a numeric event parameter'). This implicitly separates it from ga4_create_custom_dimension, though the sibling is never named.

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

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

No when-to-use or when-not-to-use guidance, no mention of alternatives such as creating a dimension or a key event, and no prerequisite steps (parameter must already be collected, property ID format). The only inference available is that the target parameter must be numeric.

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=false, destructiveHint=false, and openWorldHint=true, so the mutation safety profile is covered. The description adds the useful 'formerly conversion' framing but does not disclose required permissions, idempotency, or behavior when the event does not yet exist.

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 well-formed sentence that front-loads the core action and tacks on a clarifying example. No wasted wording, though it is arguably under-specified rather than richly concise.

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 3-parameter, non-destructive write with a fully documented schema and no output schema, the definition is minimally adequate. It omits permission prerequisites and edge-case behavior that an agent calling a GA4 admin mutation would benefit from.

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 including the countingMethod enum. The description's 'generate_lead' example mirrors the schema's eventName example, adding no meaning beyond it.

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

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

States a specific verb and resource: 'Marks an event as a key event', and clarifies the legacy term 'conversion'. An agent knows exactly what the tool does, though it does not explicitly distinguish itself from sibling ga4_list_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?

Usage is implied by the naming and example (mark a conversion-worthy event), but there is no explicit when-to-use, when-not-to-use, or prerequisite guidance such as requiring admin access to the property.

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

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

Annotations only declare readOnlyHint and openWorldHint; the description adds the crucial behavioral fact that the result lands as a local JSON file and must be read back with backup_read, plus the rationale that GA4 keeps no version history. Note the mild tension with readOnlyHint=true, since a local file is written, but the description discloses this explicitly rather than contradicting it, so an agent is not misled.

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, front-loaded with the action and scope, followed by the justification and the retrieval pointer. Nothing is redundant and no sentence could be removed without losing routing or rationale information.

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

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

For a two-parameter export tool with no output schema, the description covers what is produced (a local JSON file), where to get it (backup_read), and why it matters (no native GA4 versioning). Nothing an agent needs in order to call and follow up 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%, with both `property` and `label` documented including examples and the 'manual' default, so the baseline is 3. The description adds no syntax or format detail beyond the schema — it only describes what the backup contains, not how the parameters shape it.

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

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

States a specific verb and resource ("Backs up the complete configuration of a property") and enumerates exactly what is captured: settings, data streams incl. enhanced measurement, key events, custom dimensions/metrics, data retention, links. It is clearly distinguished from GTM export siblings by naming GA4 property scope, and it routes to backup_read for retrieval.

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 the operating context that makes the tool necessary — "GA4 has no versions — this is the state to restore from" — which tells an agent to run it before destructive changes. It also names the follow-up tool (backup_read). It stops short of explicit when-not guidance or naming a specific alternative backup mechanism, so it is not a full 5.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the read-only safety profile is covered. The description does add useful scope: the settings apply only to web data streams, and it is explicitly the v1alpha surface, which signals potential API instability and that app streams are out of scope.

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

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

A single front-loaded sentence with zero filler; the resource and its scope come before the parenthetical detail. Nothing is repeated or padded.

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

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

For a two-parameter read tool with full schema coverage and annotations covering safety, this is largely sufficient, and the parenthetical enumeration gives a rough idea of what comes back. There is no output schema, so the description could have said more about the returned structure (per-stream entries), which is the only real 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%, with both 'property' and 'dataStreamId' documented including a concrete example and the 'if omitted, all web streams' fallback. The description adds only the framing that redaction applies at stream level, which the schema already implies, so the baseline of 3 applies.

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

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

States a specific verb ('Shows') and a specific resource ('data redaction settings'), further qualified by the two setting categories (email addresses, URL parameters) and the scope ('web data streams of a property'). It does not name the write counterpart ga4_update_data_redaction, so sibling differentiation is left to the agent's inference.

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

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

There is no explicit statement of when to call this versus ga4_update_data_redaction or ga4_list_data_streams, and no prerequisites or permission notes. Usage is only implied by the word 'Shows', which suggests a read of existing configuration.

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 safety (readOnlyHint=true, openWorldHint=true), so the bar is lower. The description still adds genuine behavioral detail about the response shape: unfiltered calls return only apiNames, while search/category/customOnly calls additionally return uiName, category and metric type — a meaningful disclosure not derivable from 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 dense sentences, front-loaded with purpose then usage then output behavior; no filler. The compression ('incl.', 'customEvent:…') makes it slightly harder to parse than a cleanly structured alternative, but nothing 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?

With six parameters and no output schema, the description carries the burden of explaining returns and largely does so by distinguishing the filtered and unfiltered output shapes. Combined with the fully documented schema, an agent has enough to call this correctly and interpret the result.

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

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

Schema coverage is 100%, so baseline would be 3, but the description adds real meaning beyond the schema: it specifies that search matches substrings in apiName, uiName and description, and that it conditions which output fields appear. The 'details' parameter is not addressed in the description, keeping it below 5.

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 ('Lists the dimensions and metrics that ga4_run_report knows for this property') and explicitly scopes it to the property, including custom ones with their naming prefixes (customEvent:…, customUser:…). An agent can tell this apart from report-running siblings like ga4_run_report or ga4_run_funnel_report without opening a schema.

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

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

Gives a clear precondition: 'Use before a report instead of guessing API names,' which explicitly routes the agent away from trial-and-error on ga4_run_report. It lacks any 'when not' guidance or differentiation from the closely related ga4_list_custom_definitions sibling, so it falls short of a 5.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety and external-API behavior are covered. The description adds real value beyond that by disclosing the sort order ("Newest first") and the nature of the returned items, but says nothing about pagination, result limits, or what happens when a property has no 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 front-loaded sentence with the verb and resource first, followed by clarifying examples and ordering. Every clause earns its place; the only minor cost is that the examples lengthen the sentence without aiding invocation.

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

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

For a one-parameter read-only list tool with annotations and an adequate schema, the description covers what is returned, what annotations represent, and the ordering. Pagination and empty-result behavior are the only notable omissions, and neither is critical 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?

There is a single required parameter with 100% schema description coverage, including accepted ID formats ('123456789' or 'properties/123456789'), so the schema carries parameter meaning fully. The description only implies the property argument via "of a property" and adds no format or constraint detail beyond the schema, 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?

States a specific verb and resource ("Lists the annotations of a property") and clarifies what a GA4 annotation is with concrete examples (relaunch, GTM publish, campaign start), plus the result ordering. It implicitly separates itself from ga4_create_annotation by being a read/list, but never names the sibling explicitly, so it falls just 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?

Usage is only implied: an agent can infer you call this to inspect existing annotations on a property. There is no explicit when-to-use, no when-not-to-use, and no pointer to related tools such as ga4_create_annotation for creating one or ga4_change_history for other change records.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered, but the description adds nothing beyond them: it does not say whether archived or deleted custom definitions are included, whether results are paginated, or how many items are returned. Only one short clause of behavioral context is supplied for a listing 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?

One front-loaded sentence with no filler or redundancy. It is efficient, though its brevity leaves little room for the guidance the tool lacks.

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 with full schema coverage and a clear safety annotation, the definition is minimally sufficient. It falls short on whether custom dimensions and metrics are both always returned together, on pagination/result size, and on any property-format caveat an agent might need before invoking.

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

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

Schema coverage is 100% and the single property parameter already documents the accepted ID formats ('123456789' or 'properties/123456789'). The description's phrase 'of a property' merely restates the required parameter, so the baseline 3 applies.

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

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

States a specific verb and resource ('Lists all custom dimensions and custom metrics') and scopes it to a property, so an agent knows this is a read of custom definitions. It does not explicitly distinguish itself from the sibling write tools ga4_create_custom_dimension and ga4_create_custom_metric, though the verb 'lists' does much of that work.

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

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

There is no guidance on when to call this versus alternatives such as ga4_get_metadata or ga4_list_key_events, and no stated prerequisites (permissions, property type). The agent must infer usage entirely from the name and the single required parameter.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds value by disclosing what comes back: web streams with a measurement ID (G-XXXX) and URL, which helps an agent know the output shape. However, it says nothing about other stream types (iOS/Android), pagination, or error behavior when a property lacks streams.

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

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

A single front-loaded sentence with no wasted words and the useful output detail placed in parentheses. It is efficient, though slightly thin for a tool an agent may confuse with related GA4 admin listings.

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

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

For a simple one-parameter read tool with annotations covering safety, the description is adequate but not complete: there is no output schema, so the description should say more about what is returned (all stream types, pagination, or the response envelope). It mentions web streams and measurement IDs but leaves open whether non-web streams appear.

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

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

Schema coverage is 100% and the single 'property' parameter already documents both accepted formats ('123456789' or 'properties/123456789') with an example. The description adds no extra meaning about the parameter, so the baseline 3 applies since the schema does the heavy lifting.

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

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

The description names a specific verb and resource ('Lists the data streams of a property') and clarifies the scope as belonging to a property. It distinguishes itself reasonably from ga4_list_properties by naming data streams rather than properties, but it never explicitly contrasts with the closest sibling, leaving some ambiguity for an agent choosing between GA4 admin list operations.

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

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

There is no guidance on when to use this tool versus alternatives such as ga4_list_properties or ga4_get_metadata, nor any stated prerequisites like needing admin access or a resolved property ID first. The only implied usage is that you call it to see streams for a property, which an agent could infer from the name alone.

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 readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds useful semantic context by clarifying that these are events marked as key events, formerly conversions, but it does not discuss pagination, response shape, or authorization 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?

The description is a single front-loaded sentence with no unnecessary wording. It communicates the core purpose efficiently.

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 fully documented parameter and readOnly/openWorld annotations, the description is mostly sufficient. It could mention return shape or pagination, but no output schema exists and the core operation is still understandable.

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

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

Schema description coverage is 100%, and the property parameter is fully documented in the schema with ID format examples. The description does not add meaning beyond the schema for this single parameter, so the baseline 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 uses a specific verb and resource: 'Lists the events of a property marked as key events'. It also clarifies the terminology '(formerly conversions)', which helps distinguish the concept from ordinary events. It is clear but does not explicitly differentiate itself from the sibling ga4_create_key_event tool.

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

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

The description only states what the tool does. It provides no explicit guidance on when to use this tool versus alternatives such as ga4_run_report or ga4_create_key_event, and it does not mention prerequisites or 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?

The readOnlyHint/openWorldHint annotations already cover the safety profile, and the description adds value on top by disclosing the return payload shape (name + numeric ID) despite there being no output schema. The "account can access" phrasing usefully warns that results are permission-dependent. It does not address empty results or pagination, which keeps it off a 5.

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

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

Two sentences, zero filler, and the lead sentence carries the payload shape while the second carries the actionable follow-up. Nothing here is redundant with the title.

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

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

For a zero-parameter discovery tool with no output schema, the description covers what an agent needs: what comes back and why it matters. The only residual gap is behavior on an account with no properties or many properties, which is minor but not nothing.

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

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

The tool takes zero parameters, so the baseline is 4; there is no parameter semantics to elaborate on, and the description correctly spends no words on inputs.

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 ("Lists all Google Analytics 4 properties"), scopes the result set to what "the account can access," and names the exact return fields (name + numeric property ID). That scope plus the pointer to the report tools makes it immediately distinguishable from the other ga4_list_* siblings.

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

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

Explicitly frames the tool as a prerequisite step: "You need the ID for ga4_run_report / ga4_realtime_report." That tells an agent exactly when to reach for it. It stops short of naming exclusions or saying whether a cached/resolved property ID can be reused, so it falls just shy of a 5.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds genuine context beyond that with the ~30 minute data window, but omits realtime-specific constraints such as quota/rate limits and the fact that only realtime-compatible dimensions can be requested.

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

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

Two compact sentences with the resource identity and time window front-loaded, and examples attached to the parameters that need them. The telegraphic 'e.g.' style stays readable, though the parenthetical API-method citation is of marginal value to an agent.

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

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

For a 5-param, no-output-schema tool with a nested filter object, this covers the essentials: scope, required metrics, and dimension examples. It stops short of describing the returned rows/totals and omits the limit and dimensionFilter semantics, but the schema and its cross-reference handle the filter.

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

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

Schema coverage is 60%, with property and dimensionFilter documented in-schema. The description adds real meaning for dimensions (concrete examples: unifiedScreenName, country, deviceCategory) which the schema leaves bare, but says nothing about limit or about which dimensions are valid in realtime.

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?

Names a specific verb and resource (realtime report), cites the underlying API method runRealtimeReport, and states the scope window (~last 30 min). That window is what distinguishes it from the sibling ga4_run_report, though the description never names that sibling explicitly.

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

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

The '~30 min' framing implies this is for live/traffic monitoring rather than historical analysis, which implicitly routes against ga4_run_report. However, there is no explicit statement of when to prefer this over ga4_run_report or what to do when realtime data is unavailable.

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

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

Annotations already declare readOnlyHint and openWorldHint, so safety is covered and the description is free to add semantics: with no output schema, naming activeUsers, funnelStepCompletionRate, funnelStepAbandonments and funnelStepAbandonmentRate is genuinely useful disclosure of the return shape. It stops short of quota, sampling, or property-permission behavior, which keeps it below a 5.

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

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

Front-loaded with what the tool does and what it returns before the structural detail. The example is long but earns its place by demonstrating the nested step objects; the only minor slack is the enumerative '1, 2, 3 …' phrasing.

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

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

For a 9-parameter tool with nested objects and no output schema, the description covers the core call shape, alternative step encodings, and the metric set returned. Remaining defaults (startDate/endDate, breakdownLimit, limit) are already documented in the schema, so no critical gap is left for an 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?

At 78% schema coverage the baseline is 3, and the description exceeds it by clarifying that a step is either eventName (optionally narrowed by urlContains on page_location) or a raw FunnelFilterExpression — an either/or relationship the flat schema does not make explicit. The worked three-step JSON example anchors the nested 'steps' array structure in a way the schema cannot.

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

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

Specific verb and resource ('Funnel analysis ... runFunnelReport') plus the exact question it answers (how many users reach each step and where they drop off). It also lists the returned metrics, which lets an agent separate it from ga4_run_report without opening either schema.

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

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

Usage is implied by the funnel framing, and the description cross-references ga4_run_report only for filter syntax, not for tool selection. There is no explicit 'use this instead of ga4_run_report when...' routing, nor any when-not-to-use or prerequisite guidance.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds no behavioral context such as API quotas, data freshness, pagination behavior, or return shape, so it only identifies the underlying runReport call.

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, front-loaded with purpose and then compact example lists. The lists are dense but useful, and there is 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 10-parameter report tool with nested filter objects and no output schema, the description is thin. It omits what a report response contains and how filters/ordering combine, though the schema already covers those parameters.

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 100% schema coverage the baseline is 3. The description earns a 4 by expanding the list of valid metric and dimension names well beyond the schema's brief examples, directly aiding construction of the required metrics array and optional dimensions array.

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 'GA4 core report (Data API runReport)' – a specific verb and resource – and lists example metrics and dimensions. It does not explicitly differentiate from siblings like ga4_realtime_report or ga4_run_funnel_report, keeping it at 4.

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

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

No explicit when-to-use guidance or prerequisites are provided. The word 'core' hints it is not the realtime or funnel report, but the agent must infer the choice from sibling names; no exclusions or alternatives are named.

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

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

The description adds critical context beyond the annotations by specifying what is redacted (email addresses and URL parameters), the timing of the effect (immediate/new data), and the scope of modification (only specified 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?

The description is tightly written in two sentences. It front-loads the core function and then adds crucial technical constraints, resulting in zero 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?

Given that it is a complex configuration update, the description provides all necessary behavioral and functional constraints (what, where, when, how much) required for an agent to utilize 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?

Although schema coverage is 60%, the description adds crucial meaning by naming the subjects of the redaction (emails and URL parameters), which justifies the configuration parameters for an AI agent.

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 tool name and description work together to state exactly what changes are made (data redaction) and where (web data stream). This is highly specific.

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

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

The description provides clear operational boundaries by stating the changes take effect 'immediately and only for new data.' It doesn't name an alternative tool, but the operational constraints are clear context for usage.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds genuine context beyond that: it reveals the diagnostic role (403 triage) and that the output distinguishes write from read-only token modes. It doesn't mention credential/auth prerequisites for the call itself, which keeps it from a 5.

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

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

A single sentence, front-loaded with what it reports and ending with the operational trigger. Every clause earns its place, with no filler or restatement of the title.

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 parameters, no output schema, and read-only annotations, the description supplies enough: what is reported (token mode, scopes) and when to call it. A hint about the response shape would have fully closed the gap left by the absent output schema.

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

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

The tool takes zero parameters, so the schema carries no semantic burden and the baseline of 4 applies. Nothing in the description is needed to explain inputs, and it correctly doesn't waste words on them.

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: it shows which refresh token is active (write vs read-only) and which OAuth scopes it carries. No sibling tool in the GTM/GA4 list does anything similar, so an agent can identify this as the credential-inspection tool without opening the schema.

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

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

It states an explicit trigger: 'first check when a write tool fails with 403.' That tells the agent both when to reach for it and how it relates to the mutation siblings that might fail. The guidance is concrete rather than implied.

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

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

Annotations already declare readOnlyHint and openWorldHint, so safety is covered. The description adds the useful detail that the return splits into a head snippet and a noscript body part, but says nothing about permissions, container state requirements, or error behavior for a live container.

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

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

A single front-loaded sentence: what is returned first, then the payload breakdown, then usage contexts. No filler and nothing buried.

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

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

For a simple read-only tool with no output schema, the description does the important work of describing the return shape. However, with two required identifiers at 0% schema coverage, an agent still has to guess where accountId and containerId come from.

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% for two required parameters. The phrase 'of a container' loosely implies containerId, but accountId is never mentioned and neither parameter's format or source is explained, so the description fails to 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?

States a specific verb and resource — returns the GTM install code of a container — and specifies exactly what the payload contains (head snippet plus noscript body part). That is distinguishable from siblings like gtm_export_container or gtm_list_containers without opening any schema.

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

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

Gives concrete usage contexts (onboarding, verifying installation on the website), which tells the agent when this is the right tool. It does not name an alternative or state exclusions, 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 declare a non-read-only, non-destructive, open-world mutation, and the description adds the crucial nuance that the created version is not yet live and that a compilerError flag means the workspace is broken. With no output schema, it sensibly surfaces the two return signals (containerVersionId, compilerError). It doesn't say whether the new version persists if compilation fails.

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, front-loaded sentences with no filler; the parenthetical and the error rule are compact. The telegraphic "compilerError=true means:" phrasing is slightly compressed but still parseable.

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

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

For a 5-parameter mutation with no output schema, the description covers the key success artifact and the main failure mode. What's missing is minor: how the returned version relates to existing versions, and whether a failed compile leaves an unusable version behind.

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 accountId, containerId, workspaceId, name and notes are already documented. The description adds nothing about parameter formats or constraints, which is acceptable given full schema coverage but earns only the baseline.

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

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

States a specific verb and resource ("Creates a container version from the workspace") and immediately scopes it with "NOT live yet", which separates it from gtm_publish_version and gtm_export_version among the siblings. An agent can tell what this does without opening the schema.

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

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

Explicitly positions the tool as the step that feeds gtm_publish_version and warns not to publish when compilerError=true, which is real when/when-not guidance. It doesn't mention gtm_validate_workspace as an optional pre-check, leaving a small gap in routing.

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=false, destructiveHint=false, and openWorldHint=true, so the agent knows this is a non-destructive write in an open system. The description adds a meaningful nuance — that a workspace isolates changes from the live site — but says nothing about required permissions, workspace quotas, or what happens on name collision.

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

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

A single front-loaded sentence with the action first and the isolation rationale second; no wasted wording. It is terse almost to a fault, but structurally sound.

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

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

For a mutation tool with four wholly undocumented parameters and no output schema, the definition should say what the call returns (presumably a workspace ID that downstream tools like gtm_save_entity or gtm_validate_workspace require). That omission plus the total lack of parameter documentation leaves a real 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 0% for all four parameters, so the description must carry the burden and does not. Nothing explains the accountId/containerId hierarchy, name constraints, or the optional description field, leaving the agent to guess at the GTM resource hierarchy.

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?

A specific verb plus resource ('Creates a new workspace') that an agent can distinguish from gtm_list_workspaces and gtm_validate_workspace. It stops short of explicitly naming a sibling or a contrasting operation, so it is clear but not fully differentiated.

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

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

The clause 'always bundle changes in a separate workspace, not in the default workspace of the live site' gives a workflow directive about where changes belong, which implies when to call this tool. However, no sibling alternatives (e.g., working within an existing workspace via gtm_save_entity) are named, and no prerequisites are stated.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false and openWorldHint=true, so the safety profile is known. The description adds genuinely useful behavior beyond that: the deletion is staged and only takes effect after version + publish, and the preview returns the entity name, type and inbound references (e.g. tags on a trigger). It still doesn't say what happens when the entity is in use or whether the delete is recoverable after publish.

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, zero wasted words, with the irreversible nature and the two-step flow front-loaded. The preview/confirm contrast is stated as a single tight clause pair.

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 destructive multi-parameter tool with no output schema, the definition covers the essential gaps: the staged publish requirement, what the preview returns, and when the real delete fires. It falls short only on edge behavior, such as dependency-blocked deletes or post-publish recovery, which an agent would want before invoking.

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 83%, and the confirm parameter is already documented in the schema as preview-only when omitted. The description reinforces the confirm semantics and adds what the preview contains, but adds no syntax, format or constraint detail for entityId, entityType or the account/container/workspace IDs. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

The description names a specific verb and resource ("Deletes an entity from the workspace") and scopes the effect ("live only after version + publish"). It distinguishes deletion from the write-oriented siblings like gtm_save_entity and gtm_revert_entity by verb alone, but never names those alternatives, and "entity" stays generic where the title says tag/trigger/variable.

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 explicit procedural guidance for the two modes: omit confirm for a safe preview, pass confirm=true to actually delete. That is a clear when/when-not rule for the tool's own parameter, though it offers no routing guidance against siblings such as gtm_revert_entity when the intent is to undo rather than remove.

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=false, destructiveHint=false and openWorldHint=true, so safety is covered. The description adds nothing beyond the title: it does not say whether the call is idempotent, what happens to already-enabled variables, or that changes stay confined to the workspace until published — the behavior an agent most needs to know.

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?

One short sentence, front-loaded with the verb and resource, with the example clause placed where it helps. Nothing is padded, though the sentence carries almost no information beyond 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?

There is no output schema, so the description could reasonably say what a successful enable returns or whether it is a no-op on already-enabled types. For a straightforward four-required-param mutation with full schema coverage, this is adequate but leaves the agent guessing about post-call workflow.

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 accountId, containerId, workspaceId and types are all documented. The example array in the description reinforces the expected camelCase value format but adds no syntax or constraint beyond the schema's 'BuiltInVariable types (camelCase from the GTM API)' note.

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 ('Enables built-in variables in the workspace') and even illustrates the value domain with example types. It is clear what the tool does, but it never distinguishes itself from siblings like gtm_save_entity or gtm_create_workspace that also mutate workspace state.

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

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

No when-to-use guidance, no prerequisites (workspace must already exist, caller needs edit rights), and no mention of the follow-up step (creating/publishing a version) needed for the change to take effect. The agent must infer all operational context from sibling names.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds the meaningful behavioral detail that the default target is the live version and that containerVersionId re-targets the read, but it says nothing about output volume, structure, or how large a container export can be.

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

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

Three tight sentences, front-loaded with what is read, then requirements, then the optional-parameter branch. No filler, though the final sentence is dense and packs provenance plus rationale into one clause.

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 carries the burden of describing the return, and it does so briefly ('overview of all tags, triggers and variables'). Combined with ID provenance and default-target behavior, an agent has enough to call it correctly; only return shape/size detail 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 coverage is 100%, so the baseline is 3; the description earns above that by documenting ID provenance (which sibling tool supplies each value) and by explaining that containerVersionId switches the read from live to a historical version rather than just 'optional'.

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: reads the published (live) version of a GTM container and returns tags, triggers and variables. It distinguishes live from versioned reads, though it never names the close siblings gtm_export_version or gtm_export_workspace, leaving overlap with them to be inferred.

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 a concrete use case ('ideal for tracking audits') and tells the agent where each ID comes from (accountId/containerId from gtm_list_accounts, containerVersionId from gtm_list_versions), plus when to reach for the optional versioning path (before a rollback). No exclusions or when-not-to-use guidance against the workspace/version export 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 declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description usefully adds that output is materialized as a local JSON file (a real side effect worth knowing given readOnlyHint), but it omits where the file lands, how it is named from 'label', whether an existing backup is overwritten, and how to retrieve it later via backup_list/backup_read.

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

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

A single front-loaded sentence with the default behavior in parentheses — no filler. It is arguably over-compressed for a tool with a filesystem side effect, but nothing in it 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?

With four flat parameters, no output schema, and annotations covering the read-only profile, the description covers the essential what and default target. Missing pieces — where the JSON file is written and how it relates to backup_list/backup_read — are meaningful but secondary for a backup call.

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

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

Schema coverage is 50%: label and containerVersionId carry their own descriptions, including the 'live' default that the tool description merely repeats. accountId and containerId are undocumented in both places, and the description adds no format, ID-discovery, or naming-semantics detail to compensate for that 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 (backs up) and resource (a container version) plus the result (a local JSON file), which is enough to distinguish it from sibling reads like gtm_list_versions. It does not, however, distinguish itself from gtm_export_container or gtm_export_workspace, which sound near-identical in intent.

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 — you call it when you want a backup of a version, and the parenthetical tells you the live version is the default target. There is no explicit when-to-use/when-not guidance and no routing to the very similar export_container / export_workspace siblings, so the agent must infer which of these three to pick.

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 declare readOnlyHint=true and openWorldHint=true, so the API-side safety profile is already covered. The description adds genuinely non-obvious behavior beyond that: the export captures unsaved changes that GTM does not version. It does not say where the local file is written or whether an existing file is overwritten, which is the main remaining behavioral gap.

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

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

One front-loaded sentence that states the action, the scope, the contents, the output artifact, and a key nuance with no wasted words. Nothing is buried or repeated.

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

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

For a simple export tool with full schema coverage and no output schema, the description covers the essential: what is captured, that it includes unversioned state, and the file type. The gap is the return value — no output schema exists, yet the description does not say what path or filename is returned, which an agent would need in order to chain a subsequent backup_read.

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 all four parameters including the label semantics and the cross-references (gtm_list_accounts, gtm_list_workspaces) are already documented structurally. The description adds nothing about parameters. Baseline 3 applies when the schema carries the whole 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 gives a specific verb (backs up) and a precisely enumerated resource (a complete workspace: tags, triggers, variables, folders, templates, built-in variables) with the output form stated (local JSON file). It implicitly distinguishes itself from gtm_export_container and gtm_export_version by scoping to the workspace, though it never names those siblings, so an agent must infer the boundary.

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

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

Usage is only implied — the label example 'before_relaunch' hints at the take-a-snapshot-before-changing workflow, and the 'unsaved changes' phrase suggests it is for capturing uncommitted state. There is no explicit statement of when to choose this over gtm_export_container or gtm_export_version, and no prerequisites or 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 readOnlyHint=false, openWorldHint=true and destructiveHint=false, so the description's extra value is in explaining that the operation pulls external GitHub-hosted code into the workspace and that acknowledgePermissions confirms real capabilities (loading scripts, setting cookies). That is meaningful behavioral context beyond the annotations. It does not mention whether the imported entity lands in a draft workspace requiring a subsequent publish/version step, which is the main remaining gap.

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

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

Three sentences, front-loaded with the action and resource, followed by parameter guidance in priority order. The parenthetical example lists are slightly long but each earns its place by aiding template discovery. No filler or restatement of the title.

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 mutating, open-world import with no output schema, the description covers the essential concerns: where template coordinates come from, the mandatory permission acknowledgement, and a safety prompt to review permissions first. It is nearly complete; the missing piece is what happens on success (a new draft entity in the workspace, requiring validation/publish) and behavior when the template is already installed.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds genuine meaning: it explains that galleryOwner/galleryRepository correspond to the GitHub owner and repo shown on the gallery page at tagmanager.google.com/gallery, telling the agent where to source these values. It also expands acknowledgePermissions beyond the schema's terse 'Must be true' by explaining what is being acknowledged. gallerySha and the GTM ID parameters get no added meaning, but the schema already covers them.

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 ('Imports a tag or variable template from the GTM community gallery into the workspace') and anchors it with concrete examples (consent banners like Cookiebot, usercentrics, vendor pixels). No sibling tool in the list performs gallery import, so an agent can identify this operation unambiguously from the name plus description.

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 a clear operating context: use it to pull a community template into a specific workspace, and it names the prerequisite that permissions should be reviewed before setting acknowledgePermissions=true. There is no explicit when-not-to-use guidance or comparison to an alternative path (e.g. building the tag manually via gtm_save_entity), so it falls short of a 5.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds useful behavior beyond that by sketching the shape of the result set – publicId naming convention, numeric containerId, and container type web/server – which matters because there is no output schema.

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

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

Two sentences, front-loaded with the purpose and followed by the downstream dependency. Every clause – return fields, ID formats, the gtm_export_container link – carries information an agent would otherwise have to discover.

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 parameters and no output schema, the description supplies the essential missing piece: what each returned container looks like and how to use its IDs. It does not mention pagination, authentication scope, or whether all containers across all accounts are always fetched, which would round it out.

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

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

The tool takes zero parameters, so the baseline is 4; there is nothing for the description to clarify beyond noting that every account and container is returned without filtering, which the word 'all' does.

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 ('Lists all Google Tag Manager accounts and their containers') and names the concrete fields returned (publicId GTM-XXXX, numeric containerId, web/server). This distinguishes it from the single-item sibling gtm_lookup_container and from gtm_export_container, which consumes its output.

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 a clear usage context: it is the discovery step whose accountId + containerId feed gtm_export_container. It does not explicitly say when to prefer gtm_lookup_container or gtm_list_workspaces, so alternatives are implied rather than spelled out.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds real value beyond that by disclosing the shape of the payload — complete JSON objects including parameters and fingerprint — which matters for the save round-trip. It omits volume/pagination behavior, keeping it from a 5.

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

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

A single front-loaded sentence with no filler; the payload description and the downstream save hint both earn their place. Nothing is repeated from the title or schema.

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

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

For a read-only list tool with fully documented required params and no output schema, the description says enough about what comes back to be actionable. A note on result volume or whether all entities of a type are returned would close the remaining 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%, with all four required parameters documented and the entityType enum spelled out, so the schema carries parameter meaning. The description adds no syntax, ID-chaining, or enum detail beyond what is already structured, which is the baseline-3 case.

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: returns the complete JSON objects of an entity type in a workspace, and the title enumerates tags/triggers/variables. It also positions itself relative to gtm_save_entity. It does not distinguish itself from adjacent read tools like gtm_export_workspace or gtm_list_workspaces, so a 4 rather than 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 phrase 'template for changing via gtm_save_entity' implies the read-then-modify workflow, which is useful context. However, it gives no explicit when-not guidance and does not say how this differs from gtm_export_workspace or gtm_sync_workspace, leaving the agent to infer the boundary.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered; the description adds genuinely new behavior beyond that — newest-first sort order, the per-version metrics returned, and a live=true flag for the published version. It omits how the limit/pagination behaves in practice and whether deleted versions are hidden by default, which keeps it out of 5 territory.

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 tight sentences: the first states what is returned and how it is ordered, the second gives the downstream workflow. No filler, no restating of the title, and the most useful information leads.

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 usefully describes the shape of each returned entry and the live marker, which is exactly what an agent needs. It is only slightly incomplete on paging limits and default handling of deleted versions, which affects how the required accountId/containerId are used.

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 only 50%: accountId and containerId are undocumented in both schema and description, and the description says nothing about limit or includeDeleted. The only parameter-like reference is containerVersionId, which belongs to a sibling tool, so the description does not compensate for the coverage 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?

Names a specific verb and resource (lists container versions) and immediately discloses the ordering and the fields each entry carries (name, tag/trigger/variable counts, live=true). It also distinguishes itself from gtm_export_container and gtm_publish_version by describing the workflow that uses them, so an agent can separate these tools without opening a schema.

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

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

Gives a concrete use case — this is the entry point for a rollback — and routes the agent to gtm_export_container(containerVersionId) for inspection and gtm_publish_version for the write. It stops short of explicit when-not-to-use guidance (e.g. use gtm_lookup_container or gtm_export_version for a single version's contents), but the intended context is clear.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds the useful downstream fact that returned workspaceIds are required by write tools, but says nothing about pagination, ordering, or what fields each workspace entry carries.

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 waste; the purpose is front-loaded and the prerequisite note follows. Nothing could be removed without losing information.

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

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

For a simple, read-only two-parameter list tool with no output schema, the description covers purpose and downstream use adequately. It falls short on documenting the two required identifiers and on any hint of the response shape, which is the main remaining 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 0%, so the description must carry parameter meaning, and it does not: neither accountId nor containerId is explained beyond the incidental word "container." An agent must infer both are GTM identifiers from domain knowledge alone, with no stated format or hierarchy.

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: "Lists the workspaces of a container." This is immediately distinguishable from siblings such as gtm_create_workspace or gtm_workspace_status, and the scope (one container) is 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?

Adds a genuine when-to-use signal: it is the prerequisite step for obtaining a workspaceId consumed by GTM write tools. It gives no explicit exclusions or alternatives, but for a list-prerequisite tool the context is clear.

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

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

Annotations already declare readOnlyHint and openWorldHint, so safety is covered. The description adds real substance by disclosing what the call yields (accountId and containerId) despite the absence of an output schema, and by listing the accepted ID families. It stops short of describing not-found behavior or whether linked destination IDs resolve across accounts.

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

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

One front-loaded sentence with no filler, and the accepted ID formats are packed in efficiently. The phrasing 'Finds the container with accountId and containerId for a public ID' is slightly tangled grammatically but still parses in a single read.

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

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

For a single-parameter lookup annotated as read-only and open-world, the definition covers input formats and the shape of the result, which is what an agent needs to call it and use the answer. Only failure/not-found semantics are absent, a minor gap at this complexity level.

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

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

Schema coverage is 100% and the single 'id' parameter already carries an example, so the schema does most of the work. The description modestly extends this by naming G-XXXX linked destination IDs, a format the schema example does not show, which justifies staying at the top of the baseline band.

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 (finds the container) and clarifies the mapping performed: a public ID such as GTM-XXXX, G-XXXX, or AW-123456789 resolves to accountId/containerId. That distinguishes it from listing tools like gtm_list_accounts, though it does not name a specific sibling alternative.

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 use case is implied — resolve a public/measurement/pixel ID into GTM account and container identifiers, presumably before calling other gtm_* tools — but there is no explicit when-to-use or when-not guidance and no alternative named. The agent must infer the workflow position from the description alone.

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 flag destructiveHint=true and openWorldHint=true, but the description goes further by spelling out the live-impact ('goes live on the live website immediately'), enumerating exactly what the non-confirming preview returns (version, current live version, tag/trigger/variable diffs, rollback availability), and describing the rollback strategy. That is the context an agent needs to sequence a destructive action safely.

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

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

Front-loaded with the consequence of the call, then the two-step protocol, then rollback. The telegraphic fragments ('rollback yes/no') are dense but each sentence carries operational value; only the punctuation style slightly hurts readability.

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

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

For a destructive, open-world, four-parameter tool with no output schema, the definition covers impact, the confirmation gate, the preview contents, and rollback guidance — nothing an agent needs before invoking it 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 coverage is 50%: confirm and containerVersionId are documented in the schema, while accountId and containerId are not described anywhere. The description reinforces the confirm gate semantics and the 'rollback yes/no' preview field, adding meaning beyond the schema, but it does not fill in the two undocumented identifier parameters.

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 ('Publishes a container version') plus the immediate consequence 'goes live on the live website immediately', which clearly separates it from gtm_create_version and gtm_export_version among the 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?

Gives an explicit two-step protocol: calling without confirm yields a preview only, and confirm=true is allowed only after explicit human approval. It also names the rollback path ('publish an older version from gtm_list_versions'), so both the when and the when-not are covered.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, and the description does not contradict them (nothing is created or published). Beyond annotations it adds real value: the exact return payload ('compilerError + number of tags/triggers/variables') and the follow-up behavior on failure ('searches for the cause itself (likelyCauses)'), which tells the agent the tool does diagnostic work rather than just failing.

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?

Consistent with the calibration scale, a definition whose structured fields already carry the semantics scores in the middle band here; the prose is efficient (three short sentences, front-loaded) but the 'likelyCauses' sentence is somewhat compressed.

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 carries the return contract and does it well: names the fields returned and the error-diagnostic path. What is missing is the scope of the trial compile itself — whether it evaluates every entity in the workspace, whether it is side-effect free, or any rate/time expectations for a large container.

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 of the three IDs is already documented in-schema, including provenance hints (gtm_list_accounts, gtm_list_workspaces). The description adds no additional parameter semantics, so the baseline 3 applies.

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

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

The description names a specific verb and resource ('compiles the workspace as a trial') and adds the key negative qualifiers 'without a version and without publishing anything', which distinguishes it from gtm_create_version/gtm_publish_version. It never explicitly contrasts itself with the closest sibling, gtm_validate_workspace, so an agent still has to infer the preview-vs-validate split.

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

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

Usage is only implied: 'without publishing anything' signals this is a pre-publish check, but there is no explicit 'use this before X' or 'use gtm_validate_workspace when Y'. No prerequisites, no exclusions, no cost/latency guidance are stated.

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

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

Annotations already declare destructiveHint=true and openWorldHint=true, and the description adds the crucial non-obvious behavior that DELETE without confirm=true is a preview that deletes nothing. It also carves out publishing as out of scope. It does not mention auth scopes or how API errors surface, so it is strong but not exhaustive.

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

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

Three tight sentences: what it is and where it points, examples of paths, then the two safety caveats. No filler and the escape-hatch framing 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 free-form proxy with no output schema, an agent has enough to construct a call and understands the destructive gate. The main remaining gap is return-shape or error expectations for arbitrary endpoints, which is left implicit.

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 75% schema coverage, the schema already documents body, path, and confirm. The description still adds real value by giving concrete path strings that clarify the 'relative to /tagmanager/v2' convention and by reinforcing the confirm preview/delete split in behavioral terms.

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

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

The description names the exact API surface (Tag Manager API v2, www.googleapis.com/tagmanager/v2) and states it is the escape hatch 'for anything without its own tool', then gives three concrete path examples spanning GET, POST sync, and POST templates. That contrasts it cleanly with the many specific gtm_* 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 states the selection rule explicitly: use this when no dedicated tool exists, and it names a hard exclusion ('Publishing only via gtm_publish_version'). The path examples show the expected shape for both read and mutation calls.

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 only declare non-readonly, non-destructive, open-world; the description adds genuinely new behavioral content by explaining that keep='base' takes the newer published state, i.e. one side's change is discarded. It does not state whether the resolution is reversible, whether it re-runs the sync, or what is returned, which keeps it off a 5. Note a mild tension: replacing the published state with keep='workspace' has a side effect that destructiveHint=false arguably understates.

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 compact passage, front-loaded with the verb and the triggering sibling, then the option semantics. The trailing "(e.g. type 'tag', id '42')" partly duplicates the enum examples already present in the schema, making it the one marginally removable clause.

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

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

For a six-required-parameter mutation with no output schema, the description covers the decision the agent cannot infer (which side wins), the entity identity, and the precondition. It omits any statement of what the call returns or how errors surface, which is the main residual 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 coverage is 83%, so the baseline is 3, but the description goes further: the `keep` enum has no schema description at all, and the description supplies its semantics, while also pinning down `type`/`id` provenance ("from the conflict", "as in gtm_workspace_status / gtm_sync_workspace") with a concrete example. Only the account/container/workspace scoping params are left entirely to 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 gives a specific verb and resource ("Resolves a merge conflict") and anchors it to a named sibling ("after gtm_sync_workspace"), so an agent knows exactly which operation triggers it. It also disambiguates the two modes of resolution inline, which distinguishes it from generic entity tools like gtm_save_entity or gtm_revert_entity.

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 "after gtm_sync_workspace" establishes the precondition and the workflow position, and the keep values spell out the two decision branches. It falls short of an explicit exclusion (e.g. what to do instead when no conflict exists, or how to inspect conflicts via gtm_workspace_status), so it is clear context rather than full when/when-not 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?

The annotations declare destructiveHint=false, yet the description states the tool resets an entity to the live version and removes entities newly created in the workspace. Both overwriting workspace edits and deleting a pending entity are destructive updates, so the description and the annotation directly conflict. The disclosure itself is valuable, but it exposes that the supplied annotation misrepresents the tool's behavior.

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

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

Two sentences: the core action first, then the deletion consequence. Every clause carries information and there is no filler or restatement of the title.

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 6-parameter mutation tool with no output schema, the description covers the core effect but omits what is returned on success, whether a fingerprint mismatch is the only failure mode, and what happens to other entities in the workspace. It is adequate but leaves real gaps for an agent operating a mutation.

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 83%, and the schema already documents accountId, containerId, workspaceId, entityType with an enum, and the optional fingerprint concurrency guard. The description adds no parameter-level meaning, so the baseline 3 applies when the schema does the heavy lifting.

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

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

The description gives a concrete verb and resource: it resets a workspace entity to the live version, and it adds the notable side effect that a workspace-only entity is removed. What keeps this from a 5 is that it does not distinguish itself from close siblings such as gtm_sync_workspace or gtm_resolve_conflict, which an agent must be able to tell apart.

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?

Nothing in the description says when to reach for this tool rather than gtm_save_entity, gtm_sync_workspace, or gtm_resolve_conflict, and there are no stated prerequisites such as whether the workspace must be conflict-free or whether uncommitted changes are lost. The agent can infer the purpose but must guess at the routing decision.

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?

Goes well beyond the annotations: discloses that including entity.fingerprint makes GTM abort on concurrent modification, that the PUT path replaces rather than merges, and that a pre-check enforces ES5-strict JS and resolution of every {{Variable}}. The full-replace semantics sit in mild tension with destructiveHint=false, but since no entity is deleted this reads as scope clarification rather than a 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?

Front-loaded with the create-versus-replace decision, then concurrency, then an example, then pre-checks — a sensible escalation of detail. It is dense and the pre-check sentence packs several rules into one line, but no sentence is 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 nested, 7-parameter mutation with no output schema, the description covers modes, concurrency, payload format, and validation traps. The remaining gap is that it never indicates what comes back (e.g., the saved entity and its new fingerprint), which an agent needs to chain a follow-up call.

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

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

Schema coverage is 100%, so the baseline is 3; the description still adds real meaning by explaining that entityId switches POST to PUT, that fingerprint belongs inside entity, and by showing the concrete tag payload shape (type, parameter key/value, firingTriggerId). It does not elaborate on entityType beyond the enum already in 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?

States a specific verb (create or replace) and resource (GTM entity: tag/trigger/variable), and the very first clause disambiguates the two modes by presence of entityId. An agent can distinguish this from gtm_list_entities, gtm_delete_entity, and gtm_revert_entity without opening any schema.

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

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

Gives concrete workflow guidance: fetch first via gtm_list_entities, mutate in full, send back, and only skipValidation for a proven false positive. It does not say when to use this versus siblings like gtm_revert_entity or gtm_resolve_conflict for correcting an existing entity, which is the one routing gap.

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=false, destructiveHint=false, openWorldHint=true, so the mutation and external-source nature is partly known. The description adds useful context that it ingests changes published elsewhere (another workspace or the GTM UI), which explains why it can surface conflicts. It stops short of saying whether local unpublished changes are preserved, overwritten, or whether the call can fail on conflict.

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: what it does, when it is needed, and the follow-up action. The trigger condition is front-loaded in the second sentence and nothing is redundant.

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 covers purpose, trigger, and next step, which is most of what an agent needs for a three-parameter sync call. The remaining gap is outcome behavior — what a successful sync returns and how partial failures or overwritten local edits are handled.

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?

All three parameters (accountId, containerId, workspaceId) are fully documented in the schema, including where to obtain each ID, so coverage is 100%. The description adds no additional meaning about parameter format or interaction (e.g. whether account/container must match the workspace), so the baseline 3 applies.

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

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

States a specific verb and resource ('Pulls changes published in the meantime ... into the workspace') and scopes the source of those changes (another workspace or the GTM UI). This clearly separates it from siblings like gtm_workspace_status (which only reports state) and gtm_resolve_conflict (which handles the fallout).

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 an explicit trigger: use when gtm_workspace_status or gtm_create_version reports conflicts or an outdated state. It also routes the agent to the correct follow-up tool (gtm_resolve_conflict) after the sync, so both when-to-use and what-to-do-next are covered.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered; the description adds genuinely non-obvious behavior — that it parses JavaScript under ES5 strict mode including functions inside blocks, and that it verifies every {{Variable}} reference exists. It also discloses the return shape (name, ID, line and column per problem), which no output schema provides. It stops short of stating limits such as whether the check is static-only or how many problems are returned.

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, both front-loaded: the first states the check and its scope, the second states the return format. The parenthetical '(ES5 strict, incl. functions in blocks)' and the '{{Variable}}' notation are dense but each carries real information, and there is no filler or restatement of the name or title.

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, three-parameter, workspace-scoped validation tool with no output schema, the description covers what is validated, against which language rules, and what each problem record contains — enough for an agent to call it and interpret results. The remaining gap is routing guidance relative to the other GTM workspace tools (status, preview, sync), which matters given how many siblings exist.

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?

All three parameters (accountId, containerId, workspaceId) are fully documented in the schema at 100% coverage, including provenance hints pointing to gtm_list_accounts and gtm_list_workspaces, so the baseline is 3. The description adds no parameter-level information but correctly adds nothing misleading, and the workspace-scoped framing reinforces that all three IDs must refer to the same hierarchy.

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 ('Checks') on a specific resource set ('all tags, triggers and variables in the workspace') and further narrows the scope to JavaScript validity (ES5 strict, functions in blocks) and {{Variable}} resolution. That is far more precise than the title and distinguishes it from listing/status siblings such as gtm_workspace_status or gtm_list_entities, though those siblings are never named.

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

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

Usage is only implied: an agent can infer this is a pre-publish sanity check on a workspace, but the description never states when to run it versus gtm_workspace_status, gtm_quick_preview or gtm_sync_workspace, nor any prerequisites other than the required IDs. No explicit when/when-not guidance or alternatives are given.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered without description help. The description usefully adds the compact-vs-full behavioral split and the fact that conflict/change detail is relative to the live version. It does not disclose whether unresolved conflicts block later operations or what conflict metadata looks like, so added value is moderate.

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, front-loaded with the core purpose and followed by the usage trigger and the mode switch. The parenthetical field list is terse but efficient; nothing is wasted, though the phrasing is slightly compressed to the point of being clipped.

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

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

There is no output schema, so the description carries the burden of describing return values, and it does so for both modes. Remaining gaps — conflict severity, pagination, or error behavior when the workspace is out of sync — are minor for a read-only status tool.

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

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

Schema coverage is 100%, so the baseline is 3, but the description earns an extra point by explaining what full=true actually returns ('complete entities incl. code') and what the default compact form contains (kind of change, type, ID, name) — meaning the schema's bare 'Default false' does not convey.

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

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

States a specific verb and resource: 'Shows the changes and conflicts of a workspace compared to the live version', which is distinct from sibling listers like gtm_list_entities or gtm_validate_workspace. It also sketches the returned fields. It does not explicitly name a sibling it is not, which keeps it just below 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?

'Check before gtm_create_version' gives a concrete when-to-use trigger tied to a named sibling. There is no when-not guidance (e.g. use gtm_validate_workspace instead when you want pass/fail validation), so it falls short of full alternative routing.

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