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

Annotations already declare readOnlyHint, idempotentHint and non-destructive, and the description adds genuinely new context: the tool makes no network call, so it is free to invoke and safe as a pre-check, and it reports session-level counters plus limiter state. Not a 5 only because it says nothing about the shape or staleness of those counters.

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 clauses front-load the three things returned, and the trailing 'Makes no API call' is a high-value single sentence that earns its place. No filler.

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

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

An output schema exists, so return values need no elaboration, yet the description still names the three data points an agent cares about. For a zero-param, read-only diagnostic tool this is fully adequate.

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

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

Zero parameters, so the baseline of 4 applies. The description correctly implies nothing is configurable, consistent with the empty 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 names a specific resource class (sign-in scope profile, session request count, rate limiter state) and explicitly notes it makes no API call, which cleanly separates it from the many read siblings that do hit the API. It never names a sibling directly, keeping it short of a 5.

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

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

The content implies diagnostic usage — an agent would infer this is the pre-flight check for whether it has write scope or has hit its limiter — but the description never states when to call it or when not to. There is no explicit routing to or away from alternatives such as the list/get tools.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so credit goes to what the description adds: the explicit cost of '(3 requests)' — meaningfully high for a read tool — and the concrete scope of what is inspected (tag state active/missing/paused plus trigger existence). It stops short of saying whether the check runs against the workspace or the live container version.

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 core question, then the optional-events modifier. Minor waste: the '(3 requests)' parenthetical is spliced awkwardly mid-sentence and the 'view_item_list … purchase, refund' ellipsis is slightly loose, but nothing is 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?

With an output schema present, return-value detail is correctly omitted, and the diagnostic scope is well covered. However, for a 3-parameter tool at 0% schema coverage, gaps remain: container identifier format, workspace_id default behavior, and whether results reflect the workspace draft or the live version.

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 the load, and it only explains one of three parameters. include_optional_events is clarified (adds view_promotion, select_promotion, add_to_wishlist beyond the 11), but container — required, and ambiguous between ID and path — and workspace_id (nullable, default null, no stated behavior) are left entirely undefined.

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?

Precisely names the resource (the 11 GA4 ecommerce events plus custom-event triggers) and the exact question answered: which have an active GA4 event tag with 'send ecommerce data', which are missing or paused. This makes it clearly a read-only diagnostic, distinct from mutation siblings like gtm_setup_ga4_ecommerce_events or gtm_create_ga4_event_tag.

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 coverage framing plus the '(3 requests)' cost note suggests a pre-flight check before setup, but the description never says when to run it or why to prefer it over gtm_container_audit. It does explain the effect of include_optional_events, which is a concrete usage instruction for one 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 cover safety (readOnly, idempotent, non-destructive), so the description's value-add is the request-cost profile ("4–6 requests total") and the scope of what is examined. That is meaningful context beyond the structured fields, though it doesn't say whether results cover only the default workspace vs. drafts or how findings are aggregated.

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 core instruction and rationale in the first clause, then a compact enumeration of checks and a format hint. Slightly telegraphic ("UA leftovers", "dangling/unused triggers") but every fragment carries 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?

An output schema exists, so return structure needn't be described, and the container identifier format is supplied. The remaining gap is the role of the optional workspace parameters, which matters for a tool whose whole point is auditing a specific workspace scope.

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% and there are 3 parameters, so the description must compensate. It does so for `container` by giving accepted formats (GTM-XXXXXXX or accounts/<a>/containers/<c>), but says nothing about `workspace_id` or `include_workspace_status`, leaving two parameters undocumented anywhere.

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 concrete verb+resource (one-shot health check of a workspace) and enumerates the specific defect classes it detects (UA leftovers, duplicate Google tags, dangling triggers, undefined variables, paused tags, unpublished changes). It also explicitly positions itself against the family of single-resource list tools, so an agent can tell it apart from gtm_list_tags/gtm_list_triggers without inspecting schemas.

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

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

"prefer this over many single list calls" plus the 4–6 request cost note gives a clear selection rule against the sibling list tools. It does not state when *not* to use it (e.g., auditing a specific tag only), but the usage context is unambiguous for the common case.

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

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

Annotations already declare this is a non-destructive, non-idempotent, open-world write; the description adds real value beyond that by disclosing the hidden side effect that a Custom Event trigger will be reused or created with a specific dataLayer.push payload, and that dry_run=true (default) previews rather than applies the request. It does not say what happens on a second identical call (related to idempotentHint=false) or whether the created trigger persists if the tag creation 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?

Four dense sentences, front-loaded with the resource type and measurement_id format, then conditional behavior, then the dry_run safety default. No filler, though the parenthetical dataLayer.push snippet is close to redundant with the preceding clause and could be trimmed.

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?

Output schema exists, so return values need not be explained, and the key side effect plus dry_run contract are covered. However, for a 10-parameter write tool in a GTM workspace context, the description never explains what 'container' accepts (ID, path, or name — gtm_find_container exists as a sibling) or what workspace_id defaults to, which are the two gaps most likely to cause a failed or misdirected 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?

With schema description coverage at 0% across 10 parameters, the description has to carry parameter meaning — and it does for the non-obvious ones: measurement_id format (G-XXXXXXXX or {{variable}} syntax), firing_trigger_ids omission semantics, send_ecommerce_data default true for ecommerce events, and dry_run default true. It says nothing about container, workspace_id, name, trigger_name, or event_parameters, so roughly half the parameters remain undocumented anywhere.

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

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

The description identifies the resource precisely — a GA4 event tag of GTM type 'gaawe' — which an agent familiar with GTM can map to a concrete creation operation. It does not explicitly say 'creates' (the verb only appears in the name/title) and never contrasts itself with gtm_create_tag or gtm_setup_ga4_ecommerce_events, so sibling differentiation is left implicit.

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

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

Usage context is implied by the dry_run default previewing the write and by the note that a trigger is auto-reused/created when firing_trigger_ids is omitted — that tells an agent it can call this without pre-building a trigger. But there is no explicit when-to-use versus gtm_create_tag (the generic tag creator) or versus gtm_setup_ga4_ecommerce_events, both of which are close alternatives in the sibling list.

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

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

Annotations declare a non-idempotent, non-destructive open-world write, and the description adds the critical safety fact that dry_run=true previews only — that is real context beyond the annotations. It also explains type coercion of the parameters dict, though it doesn't cover what happens on a real write or container/workspace resolution.

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

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

Dense but front-loaded: the create action and type codes come first, then parameter formatting, then trigger guidance, then the alternative tool. Every sentence carries information, though the run-on `parameters` clause is heavier than it needs to be.

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?

An output schema exists so return values need no explanation, and the core create path is covered. However, for an 11-parameter mutation tool with 0% schema coverage, the unexplained workspace/container targeting and blocking-trigger semantics leave real gaps.

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

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

Schema description coverage is 0% across 11 parameters, so the description must compensate. It does well for `type`, `parameters`, `dry_run`, and implicitly `firing_trigger_ids`, but leaves `container`, `workspace_id`, `tag_firing_option`, `blocking_trigger_ids`, `paused`, and `notes` entirely 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?

States a specific verb and resource ('Create any tag type in the workspace') and immediately qualifies it with the `type` code list. It explicitly names the sibling to route GA4 event tags to, so an agent can distinguish it from gtm_create_ga4_event_tag 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?

Gives clear routing ('For GA4 event tags prefer gtm_create_ga4_event_tag') plus operational guidance (All Pages trigger id 2147479553, dry_run defaults to preview). It does not mention the update path (gtm_update_tag) for existing tags, so the when-not-to-use case is incomplete.

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

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

Annotations already declare the write/non-destructive/non-idempotent profile, and the description adds genuinely new behavior: dry_run=true previews only (so nothing is persisted), and use_regex=true changes custom_event_name into a pattern like 'a|b'. It stops short of saying whether the trigger must be published via gtm_create_version to take effect.

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

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

Dense and front-loaded: the core action comes first, then type-specific requirements, then filters, then the dry_run default. Every clause carries information, though the filter example is somewhat sprawling within a single run-on 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?

An output schema exists so return values need no explanation, and annotations cover the safety profile. The description covers the non-obvious semantics of a mutation tool with 8 undocumented params; the remaining gap is workspace_id and whether a version/publish step is required for the trigger to go live.

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 the load and largely does: it explains type, custom_event_name, use_regex, dry_run, and the exact filter object shape with the full operator vocabulary. Only workspace_id and the container/name semantics go undocumented, though those are close to self-evident.

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 ("Create a trigger") and immediately enumerates the trigger types it applies to, so the agent knows this is the creation counterpart to gtm_get_trigger/gtm_list_triggers. Sibling differentiation is implicit through the resource name rather than stated 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?

No explicit when-to-use or when-not-to-use guidance versus gtm_create_tag, gtm_create_variable, or gtm_create_version. The only workflow hint is the dry_run=true default, which implies a preview-then-apply pattern, but this is left for the agent to infer.

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 write, non-destructive, non-idempotent; the description adds the important piece beyond them — dry_run=true (default) previews only — which tells the agent the default call performs no write. It doesn't disclose undo semantics or that the variable lands in a workspace draft, but the safety-critical behavior is covered.

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, front-loaded lines with no filler, leading with what is created and following with the type-specific rules. Slightly cryptic in places ("code v", "raw parameters") 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?

For a 9-parameter write tool with an output schema, the description covers the dry-run safety model and the type-dependent required fields, which are the two things an agent could get wrong. Gaps around container/workspace placement and default_value are the remaining shortfall.

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 0% across 9 parameters, so the description had to compensate, and it does for type, value, data_layer_name, parameters and dry_run, including the non-obvious mapping of GTM type codes (v, c, jsm, u, k) to required fields. name, container, workspace_id and default_value remain undocumented in both places, which keeps it from a 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 ("Create a user-defined variable") which is distinct from the list/get siblings. It does not name a near-alternative such as gtm_create_tag or gtm_update_tag, but the resource is unambiguous enough that an agent can route to it.

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 type-conditioned guidance (which field each type requires) which implies usage, but never states when to choose this over the sibling creators or what container/workspace context is assumed. Usage is inferable rather than stated.

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

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

The annotations only say write/openWorld/non-idempotent; the description adds the critical side effect that the workspace is deleted and a fresh default one created, plus that conflicts block the operation. That is exactly the beyond-annotation context an agent needs. Minor tension: destructiveHint=false while the text describes workspace deletion, though in GTM terms the content is preserved in the snapshot, so this is a caution 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?

Three tight sentences with the most decision-relevant fact (not published) front-loaded. No filler, and the caveats are ordered by importance: side effect, then blocking condition, then safe-inspection path.

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 an output schema, this covers the essential behavior: what is created, what is destroyed, what blocks it, and how to preview. The remaining gap is parameter-level detail (name/notes/workspace_id) that neither the schema nor the description supplies.

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 the parameter burden. It does well for dry_run (semantics plus default), but name, notes, container, and workspace_id are left entirely unexplained — notably whether workspace_id omitted means the default workspace.

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?

"Snapshot the workspace into a container version" names a specific verb and resource, and "(NOT published yet)" immediately separates it from the sibling gtm_publish_version. An agent can route between create_version and publish_version 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?

It states the preconditions for a successful call (merge conflicts block it) and points at dry_run=true as the inspection path, which is real when-to-use guidance. It stops short of explicitly naming the alternatives (gtm_publish_version, gtm_get_workspace_status) that an agent should reach for first.

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 a non-read-only, non-destructive, non-idempotent, open-world write, and the description adds genuinely new behavior: the result is an empty draft and nothing is published, and dry_run defaults to true so the call only previews unless overridden. That default-preview behavior is the single most important thing an agent could miss, and it is stated here. It is consistent with annotations and adds real value.

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

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

Two sentences, front-loaded with the core action and its scope, then the operational caveat about dry_run. No filler and nothing repeated from the schema or annotations.

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

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

An output schema exists, so return values need no explanation, and the annotations cover the safety profile. What matters for this write tool is present: draft-only semantics, container format, and the default-preview flag. Minor gap: it never states that a real creation requires dry_run=false explicitly, nor what happens on a name collision.

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 schema alone tells the agent nothing. The description compensates for two of the four parameters: it gives the container format ("GTM-XXXXXXX or accounts/<a>/containers/<c>") and clarifies dry_run's default preview semantics. It says nothing about `name` or the optional `description` field, so the compensation is only partial.

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+resource ("Create a new empty workspace") and immediately scopes it as a draft where "nothing is published", which separates it from creation/publish siblings like gtm_create_version and gtm_publish_version. It stops short of naming any sibling explicitly, so it is clear but not maximally 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?

Usage is implied rather than stated: the dry_run note hints that a real creation requires dry_run=false, but the description never says when to pick this tool over the many other gtm_* creation tools, nor any prerequisites (e.g., that the container must exist). No explicit exclusions 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 this is a non-read-only, open-world, non-destructive write operation. The description adds useful behavioral context: already-enabled types are harmless, and dry_run=true previews changes. It does not contradict the annotations, though it leaves permission and workspace-default behavior unstated.

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

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

The description is front-loaded with the purpose and uses only three sentences. The long parenthetical list of types is useful rather than wasteful because the schema provides no enum. It is concise enough for the information conveyed.

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

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

The output schema exists, so return values need not be described. For a write operation with four parameters and no schema descriptions, the description is only partially complete: it explains types and dry_run but omits container and workspace_id semantics. Permissions and open-world implications are partly covered by annotations but not elaborated.

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. It compensates well for the types parameter by listing many valid API types and for dry_run by explaining that true previews changes. However, it does not explain the required container parameter or the optional workspace_id parameter, leaving clear gaps for half the 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?

The description states a specific verb and resource: enable built-in variables by API type. It gives concrete examples (pageUrl, pagePath, referrer, event, etc.), making the operation clear. It does not explicitly differentiate from the sibling gtm_list_built_in_variables, but the enable-vs-list distinction is evident.

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

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

The description implies when to use the tool by saying it enables built-in variables, and it notes dry_run=true previews. However, it does not explicitly say when to use this instead of listing variables first, nor does it give any when-not-to-use conditions.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the description doesn't need to restate safety, and instead adds genuinely new behavioral context: request-cost expectations ('1–2 requests' vs '1 request per account'). That cost asymmetry is exactly the kind of detail annotations can't express. It doesn't say what happens if both params are supplied or how results are ordered/truncated.

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 clauses, front-loaded with the primary resolution path and the request-cost hint, with the alternative mode stated second. No filler.

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

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

With an output schema present and annotations covering the safety profile, the remaining burden is mode selection and input semantics, both addressed. Minor gaps: behavior when both parameters are provided, and whether the multi-account name search is expensive enough to warrant caution.

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 the parameter burden — and it largely does: public_id is explained with accepted formats and provenance ('from the website's source'), and name_contains is explained as a name search spanning all accounts. It never states whether the two params are mutually exclusive or how matching works (case/substring).

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 ('Resolve') plus concrete outputs (account, container id, default workspace) and names the exact id formats accepted (GTM-XXXXXXX, G-/AW-). It also distinguishes the second mode (name search across accounts) from the id-resolution mode, which separates it from siblings like gtm_get_container that presumably take an internal id. It stops short of explicitly naming the sibling it replaces.

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 clearly indicates when to use each of the two modes: public_id when you got a GTM-/G-/AW- id from the site source, name_contains when you only know a name. No explicit when-not or named alternates (e.g. gtm_list_containers for browsing) are given, so it is a solid 4 rather than 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, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is fully covered structurally. The description adds the useful detail of what fields come back, but says nothing about error behavior when an id is unknown or about permission/auth requirements.

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

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

Two dense sentences with no filler; the returned-field list is front-loaded and the identifier syntax follows. The telegraphic, fragmentary phrasing ('Container as public id...') costs a little readability but wastes no space.

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

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

With an output schema present, the description need not explain return values, yet it usefully previews the fields, and it fully specifies the one required argument. What is missing is only the sibling-disambiguation context, which is a usage concern rather than a completeness gap for calling the tool.

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

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

Schema description coverage is 0%, so the description must carry the entire burden for the single required 'container' parameter, and it does: it gives both accepted forms (public id such as GTM-XXXXXXX or a linked G-/AW- destination id, and the API path accounts/<a>/containers/<c>). This is a meaningful addition over an undescribed string field, though it omits edge cases like case sensitivity or malformed-id handling.

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 the resource and enumerates the fields returned (name, public id, usage context, domains, linked tag ids), which clearly distinguishes it from mutation siblings. The verb is only implied by the noun phrase 'Container details' rather than an explicit 'retrieves', and nothing separates it from gtm_find_container or gtm_list_containers.

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 statement of when to use this single-container lookup versus gtm_find_container (search) or gtm_list_containers (enumerate), which is the most likely agent confusion given the sibling set. The only routing-like guidance is about identifier formats, which is parameter guidance rather than usage 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, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is fully covered. The description adds the useful semantic that 'live' means what visitors actually receive, but says nothing about behavior for unpublished/empty containers, error cases, or rate limits.

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

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

Two tight sentences with zero filler, and the core definition of the resource is front-loaded ahead of the identifier-format detail. Nothing repeats the annotations or the title verbatim.

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?

An output schema exists, so return values need no explanation, and the container identifier formats are covered. The remaining gap is the undocumented optional 'include_entities' flag, which an agent cannot reason about from either the schema or the description.

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 the parameter burden. It does well for 'container', spelling out the public-id forms (GTM-XXXXXXX, linked G-/AW- destination id) and the API path form, but 'include_entities' is left entirely unexplained in both schema and description.

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 the specific resource and its scope: the version currently published, clarified as 'what visitors actually get'. The verb is elided in the description (supplied only by the title), and sibling tools like gtm_get_version and gtm_list_versions are never named, so the distinction is implied rather than stated.

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

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

Phrasing like 'currently published' implicitly tells an agent to use this instead of fetching an arbitrary version, but no explicit when-to-use, when-not-to-use, or alternative tool is named. The agent must infer the gtm_get_version vs gtm_get_live_version split on its own.

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

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

Annotations already declare read-only, idempotent, non-destructive behavior, so the description's main value is in disclosing accepted container formats and the default-workspace lookup/caching behavior. It also describes the returned tag shape, though it does not mention error behavior if the tag is missing.

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

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

The description is front-loaded with the returned data shape, then gives the container format and workspace default in compact sentences. Every sentence supplies useful calling information without 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?

An output schema exists, so return-value documentation is not strictly required, but the description still adds useful return details. It covers the tricky container and workspace parameters and does not contradict annotations; the only notable omission is an explicit description of tag_id.

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

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

Schema description coverage is 0%, so the description carries the burden of explaining parameters. It does well for container (public ID, linked destination ID, or API path) and workspace_id (numeric, omitted defaults to cached Default Workspace), but it never describes the required tag_id parameter.

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 exactly what the tool returns: a full tag with flattened parameters, triggers, consent, notes, fingerprint, and referenced variables. This clearly distinguishes it from gtm_list_tags, which would list tags rather than retrieve one tag's full detail.

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 word 'Full tag' implies this is the detailed single-tag retrieval tool, but the description does not explicitly say when to use it instead of gtm_list_tags or gtm_get_version. Usage guidance for container and workspace is present, but sibling routing is left implicit.

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

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

Annotations already declare read-only, idempotent, non-destructive behavior, so the description adds real value by disclosing the completeness of the returned object and the caching behavior of the Default Workspace lookup. It stops short of noting error modes or what happens if the trigger id does not 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?

Three tight sentences: return payload first, then the two non-obvious identifier formats. Every clause carries information an agent could not infer from the schema, with zero 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?

An output schema exists, so return values need no explanation, and the two hard-to-guess parameters are documented. The remaining gap is trigger_id semantics and failure behavior for a missing id.

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 0% schema description coverage the description must carry the burden, and it does for two of three params: container accepts GTM-XXXXXXX, a linked G-/AW- destination id, or an API path accounts/<a>/containers/<c>, and workspace_id is numeric with a documented default. trigger_id receives no format or provenance guidance at all.

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

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

Opens with a concrete statement of what is returned: a single full trigger object including all filter conditions and fingerprint, which implicitly contrasts with the sibling gtm_list_triggers. The verb 'get' comes only from the name/title, not the description, so it is clear but not maximally 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?

There is no statement of when to use this versus gtm_list_triggers or gtm_get_version, and no preconditions such as required scopes. The only guidance is parameter-level ('Omit to use the Default Workspace'), which does not help tool selection.

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

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

Annotations already establish read-only, idempotent, non-destructive, open-world behavior. The description adds meaningful context beyond that: container can be a public id, a linked G-/AW- destination id, or an API path, and omitting workspace_id triggers a cached Default Workspace lookup. It does not cover error behavior or variable_id format, but it is substantially more informative than the annotations alone.

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

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

The description is compact and front-loads the returned payload, then moves through container format and workspace default. Parenthetical examples are efficient, though the opening would read more naturally if it began with the action rather than the result.

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?

An output schema exists, so return-value explanation is unnecessary, and annotations cover the safety profile. The description supplies the container addressing formats and workspace omission behavior that an agent needs to invoke the tool correctly; only the variable_id format is left unaddressed.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It documents container formats in useful detail and explains the workspace_id default-with-caching behavior, but variable_id is left entirely unexplained beyond its name. Two of three parameters are well served, which is adequate but incomplete for a zero-coverage 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 states that it returns a full variable with flattened parameters and fingerprint, which is a specific resource and payload shape. It distinguishes itself from gtm_list_variables implicitly, but the core action verb (retrieve a single variable by id) is only implied by the tool name rather than stated outright.

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

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

Usage is implied by the required container and variable_id parameters and by the contrast with list-style siblings, but the description never explicitly says when to use this tool versus gtm_list_variables or gtm_get_container. It does provide useful guidance on optional workspace_id behavior, which slightly exceeds pure implication.

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

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

Annotations already declare readOnly, idempotent, non-destructive, so the safety profile is covered. The description adds genuinely useful return-shape context (counts, tags-by-type, compact lists), but says nothing about permissions, error behavior for a bad container/version id, or the size/truncation characteristics of the compact lists.

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 dense sentences with no filler; the return contents come first and the parameter formats second, so the most important information is front-loaded. The telegraphic style is efficient, though slightly clipped enough to read as notes rather than prose.

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

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

An output schema exists so return values needn't be described, and the container format guidance is complete. What's missing for an agent to call this confidently is where version_id comes from and how this differs from gtm_get_live_version — a real gap in a 32-tool family with three near-identical version tools.

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 0%, so the description must carry the load and largely does: it spells out both container forms (GTM-XXXXXXX public id or accounts/<a>/containers/<c> API path) and defines exactly what include_entities=true changes. Only version_id is left entirely unexplained, keeping it short of a 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 precisely what the tool returns: a single version with counts, tags-by-type, and optional compact entity lists. This distinguishes it from the listing siblings, though it never explicitly contrasts with gtm_list_versions or gtm_get_live_version, which is the closest ambiguity.

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 include_entities clause gives an implied usage rule (default is summaries; flip it for full entity lists), but there is no explicit when-to-use guidance, no note that version_id comes from gtm_list_versions, and no pointer to gtm_get_live_version as the alternative for the current live state.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety bar is covered; the description adds substantive context beyond that — it tells the agent what is actually returned (pending changes plus conflicts) and discloses the caching behavior of the Default Workspace lookup. It does not cover error behavior (e.g. invalid or missing workspace), which keeps it at 4.

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 payload is front-loaded, followed by the usage cue, then parameter formats — a sensible order with no filler. It is written in compressed fragments with stacked parentheticals, which is dense but not wasteful.

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 an output schema present it correctly avoids detailing return structure, and annotations handle the safety profile, so the remaining burden is params and usage — both covered. The one gap is failure modes (workspace not found, permission on linked destinations), which matters for an openWorld read against a live API.

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 the load and it does: 'container' is documented with accepted forms (GTM-XXXXXXX, linked G-/AW- destination id, or accounts/<a>/containers/<c> API path) and 'workspace_id' is documented as numeric with an explicit omit-to-default behavior plus its caching side effect. Nothing an agent needs to build a valid call is missing.

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 resource and the exact payload: 'Unpublished changes and merge conflicts of a workspace', which distinguishes it from gtm_list_workspaces (lists workspaces) and gtm_get_version (published versions). It is a noun phrase rather than a verb+resource statement, so it stops just short of the top mark.

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?

'run before gtm_create_version' gives an explicit sequencing cue and names the sibling it gates, which is real when-to-use guidance. There is no statement of when this tool is unnecessary (e.g. if you only want the workspace list or published version state), so it lacks the exclusions a 5 requires.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and open-world behavior, so the safety burden is covered. The description adds two useful facts beyond that: results are limited to accounts visible to the signed-in Google user, and the call costs a single request. It says nothing about pagination or result ordering, which matters 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 sentence, front-loaded with the action and resource, with the permission scope and request cost appended compactly. No filler and nothing that repeats structured fields.

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?

An output schema exists, so return values need no explanation, and annotations cover the safety profile. For a zero-parameter root listing tool this is nearly sufficient; only the pagination/ordering behavior and its role as a discovery entry point are 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?

The tool takes zero parameters, so there is no parameter semantics to explain; the baseline for a parameterless tool is 4. The description correctly signals that no filtering or scope arguments are accepted.

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 ('List every Google Tag Manager account') and scopes it to what the signed-in user can see. It does not explicitly name a sibling alternative, but the root-level 'accounts' granularity distinguishes it from gtm_list_containers, gtm_list_environments, and the other list_* children.

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 top-level nature of the call is implied but never stated as an entry point ('use this first to discover account IDs, then use gtm_list_containers'). There is no explicit when-to-use versus alternatives guidance for the many sibling listing tools.

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

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

Annotations already declare read-only, idempotent, non-destructive, open-world behavior, so the safety profile is covered. The description adds useful behavioral context by explaining that the default workspace is looked up once and cached, and by clarifying the enabled-only 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?

The description is compact and front-loaded with the core result, then moves efficiently through container formats, workspace id, and default behavior. Every sentence adds practical calling information without 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 simple read-only list tool with annotations and an output schema already available, the description is complete enough to invoke correctly. It covers both input parameters, the default workspace behavior, and the returned fields.

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. It does: container accepts a public GTM id, linked destination id, or API path; workspace_id is numeric and may be omitted to use the cached Default Workspace.

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

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

The description states a specific verb and resource: listing built-in variables currently enabled in a workspace. It distinguishes built-in variables from the broader variable listing implied by sibling gtm_list_variables, and the example format reinforces the exact object being returned.

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 'currently enabled in the workspace,' but there is no explicit guidance contrasting this with gtm_list_variables or gtm_enable_built_in_variables. The default-workspace behavior is helpful, but it is parameter guidance rather than when-to-use 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 read-only, idempotent, open-world, and non-destructive behavior. The description adds operationally important context beyond that: request counts per account, a 10-account cap, and the quota of 25 requests per 100 seconds.

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

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

The description is a single front-loaded sentence with no wasted wording. It packs scope, fallback behavior, request cost, cap, and quota into a compact statement.

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

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

An output schema exists, so return values need not be described. The description covers account_id behavior and quota well, but with 0% schema parameter coverage it leaves the name_contains filter undocumented, which is a notable completeness gap for a two-parameter listing tool.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It explains account_id omission semantics well, including the all-accounts fallback and cap, but it does not mention the name_contains parameter at all.

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

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

The description states a specific verb and resource: listing GTM containers, with clear scope for one account versus all accounts. It does not explicitly distinguish itself from siblings like gtm_list_accounts or gtm_get_container, but the resource is unambiguous.

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

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

It gives a useful conditional behavior when account_id is omitted and notes a quota cap, which implies usage context. However, it does not say when to choose this tool over alternatives such as gtm_find_container or gtm_get_container, nor does it explain when to use the name_contains filter.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so safety is covered. The description adds a non-obvious behavioral fact — that preview auth codes are never returned — which matters for anyone expecting full environment objects. It stops short of saying whether all environments are returned or how ordering works.

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 what is returned before the identifier formats. Dense and waste-free, though the opening is a fragment without a verb, which slightly weakens the lead.

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?

A read-only single-parameter list tool with an output schema, so return structure needn't be described. Purpose, identifier formats and the auth-code redaction are all covered; only the absence of routing guidance against sibling version tools is 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 coverage is 0% on the single required 'container' parameter, so the description must compensate and largely does: it lists accepted forms (GTM-XXXXXXX, linked G-/AW- destination id, or API path accounts/<a>/containers/<c>). It leaves unstated whether path-form IDs behave identically to public IDs, so it is thorough but not exhaustive.

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

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

The description names the resource (environments) and specifies that each entry is paired with the version it serves, so an agent knows exactly what a call returns. It lacks an explicit verb, but 'List' is unambiguous from the name/title and there is no sibling environment tool to confuse it with.

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

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

There is no statement of when to call this versus alternatives (e.g., gtm_get_live_version or gtm_list_versions) or what prerequisites apply. The only guidance present concerns identifier formats, which is parameter-level rather than usage-level.

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

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

Annotations already declare readOnly, idempotent, openWorld, and non-destructive behavior. The description adds useful behavior beyond annotations by stating that omitting workspace_id uses the Default Workspace, looked up once and cached, but it does not discuss pagination, error behavior, or return shape.

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

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

The description is compact and front-loads the resource scope, then moves into parameter formats and default behavior. It is slightly telegraphic and does not open with an explicit verb, but every sentence contributes useful 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 listing tool with an output schema, the description covers the resource, both parameter formats, and default workspace behavior. It lacks explicit routing guidance versus sibling tools, but the remaining gaps are minor given annotations and output schema.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It does this well for both parameters: container accepts a public ID (GTM-XXXXXXX or linked G-/AW- destination ID) or API path accounts/<a>/containers/<c>, and workspace_id is numeric with a default fallback.

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

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

The description identifies the resource precisely: folders within a GTM workspace, and notes that tags/triggers/variables reference folders via folder_id. It does not explicitly say 'list' or distinguish this from sibling listing tools, so it is clear but lacks sibling differentiation.

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

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

It explains the container and workspace parameters, including the default workspace fallback, but gives no guidance on when to use this tool versus alternatives such as gtm_list_workspaces or entity listing tools. The only usage-like context is that folders are referenced by folder_id.

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/idempotentHint annotations already cover the safety profile, but the description adds genuinely non-obvious behavior: all pages are fetched in one request and type/paused/limit/offset/name_contains are applied locally rather than server-side. It also discloses that the Default Workspace is looked up once and cached. Only rate limits or permission requirements are left unstated.

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

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

It is dense and front-loads the return shape, then container/workspace formats, which is the right order. The parenthetical about local filtering is packed into the first line and the id-format enumeration runs long, but almost every clause carries information.

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

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

With an output schema present, return fields need not be spelled out, and the description still covers the awkward inputs (container id forms, default workspace, local pagination) that would otherwise cause bad calls. It does not mention authentication or that type values must match GTM's tag type enum exactly, which 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 0%, so the description has to carry all seven parameters, and it largely does: container accepts a public id (GTM-XXXXXXX) or a linked G-/AW- destination or an API path accounts/<a>/containers/<c>; workspace_id is numeric with a cached default; type gets concrete examples (gaawe, googtag, html, awct, ua); and offset/filters are identified as local. limit, paused and name_contains are only implied as filters, which is the one gap.

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

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

The description names the resource (tags of a workspace) and enumerates what comes back — type label, paused flag, trigger ids, key parameters — so an agent knows exactly what object it gets. It does not use an explicit verb like 'list' and does not contrast itself with gtm_get_tag or gtm_list_triggers, so sibling differentiation is left to the name.

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

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

It gives an actionable default ('Omit to use the Default Workspace, looked up once and cached') which is real usage guidance. It never says when to reach for gtm_list_tags versus gtm_get_tag or gtm_list_triggers, and no exclusions are stated, so usage is implied rather than directed.

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 the read-only, idempotent, non-destructive safety profile. The description adds useful behavioral context beyond annotations: template code is not returned, and omitting workspace_id triggers a cached lookup of the Default Workspace. It does not cover error or permission behavior, but the added return-content and caching details are valuable.

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 dense but efficient: it front-loads the template scope, then immediately documents the container and workspace parameters. Every sentence adds necessary information, with no filler.

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

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

Given two parameters, 0% schema description coverage, and an available output schema, the description supplies all caller-relevant details: resource scope, return limitation, container formats, workspace default behavior, and caching. Nothing essential for correct invocation is missing.

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

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

Schema description coverage is 0%, so the description carries the full burden and does so well. It defines container formats (GTM-XXXXXXX, linked G-/AW- destination id, or API path accounts/<a>/containers/<c>) and explains that workspace_id is numeric and can be omitted to use the cached Default Workspace.

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

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

The description states a specific verb-like action (listing custom/community-gallery templates) and the exact resource scope: templates installed in the workspace. It also clearly distinguishes the returned data by noting that template code is not included, so an agent can tell this apart from sibling list/get tools.

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

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

Usage is implied by the resource and container/workspace context, and the default-workspace behavior is explained. However, the description does not explicitly state when to use this tool versus alternatives such as other list tools, nor does it provide when-not-to-use 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 this as read-only, idempotent, open-world, and non-destructive. The description adds useful context that each trigger comes with a one-line condition summary and that the default workspace is looked up once and cached. It does not disclose pagination behavior, rate limits, or how filtering behaves, leaving some behavioral gaps.

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

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

The description is short and front-loads what a trigger record includes, followed by parameter details. However, it is written as fragmented phrases ('Triggers with a one-line condition summary...', 'Container as public id...') rather than clear sentences, which slightly reduces 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?

Output schema and annotations are present, so return values and safety profile need not be covered. The description covers the required container parameter and workspace default well, but for a list tool with six parameters it omits useful context for filtering and pagination options like name_contains, type, limit, and offset.

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. It explains the container format (public ID, linked destination ID, or API path) and workspace_id default/caching well. But it says nothing about type, name_contains, limit, or offset, leaving four of six parameters undocumented.

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

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

The description names the resource ('Triggers') and says each includes a one-line condition summary, implying a list operation. However, it never uses a clear verb like 'list' and does not distinguish this from gtm_get_trigger or gtm_create_trigger. The purpose is inferable but not stated with specificity.

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 gtm_get_trigger or other list tools. The only usage-like information is about omitting workspace_id to get the Default Workspace, which is parameter guidance rather than tool selection guidance.

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

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

Annotations already declare the safe read-only, idempotent behavior. The description adds useful context by explaining that omitting workspace_id triggers a default-workspace lookup that is cached, and by documenting accepted container id formats.

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

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

The description is compact and front-loads the resource and output summary, then moves to container and workspace argument details. Every sentence adds useful context without repetition or filler.

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

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

An output schema exists, so return values need not be explained, and annotations cover safety. However, with six parameters and 0% schema description coverage, the description is incomplete for filtering and pagination behavior even though it handles the required container and workspace_id.

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 0% schema description coverage, the description must carry parameter meaning. It covers container formats and workspace_id default behavior well, but leaves type, limit, offset, and name_contains unexplained; the type-code parenthetical hints at variable types but does not clearly define the type filter.

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 specifies the resource as user-defined variables and adds type-code context, distinguishing it from built-in variables such as gtm_list_built_in_variables. It is clear what is being listed, though it does not explicitly say 'list' or distinguish from gtm_get_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?

The description explains container and workspace argument formats but gives no guidance on when to use this tool versus alternatives like gtm_get_variable or gtm_list_built_in_variables. There are no when/when-not conditions 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 readOnly, idempotent, non-destructive, and open-world, so the safety profile is covered. The description adds genuine behavioral context beyond that: results are newest-first, each entry carries entity counts, and the response delivers the latest version id. It does not mention pagination behavior for limit/offset, keeping it below 5.

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

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

Two dense sentences that are front-loaded with the return contents and ordering, followed by the input format detail. There is no filler, though the telegraphic style borders on cryptic.

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?

An output schema exists, so return values need not be explained, and annotations cover safety. However, with 0% schema description coverage, the description leaves three of four parameters unexplained and provides no guidance on which sibling to use for fetching or publishing a single version.

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 compensate. It does a good job with the required `container` parameter, explaining the accepted public-id (GTM-XXXXXXX, linked G-/AW-) and API-path forms, but leaves `limit`, `offset`, and `include_deleted` completely undocumented.

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

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

States a specific verb+resource (list container versions) and even specifies the payload shape (id, name, entity counts, latest version id) and ordering. It does not explicitly differentiate itself from siblings like gtm_get_version or gtm_get_live_version, so it falls short of a 5.

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

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

Usage is implied: you call this to enumerate a container's version history. There is no explicit statement of when to prefer gtm_get_version, gtm_get_live_version, or gtm_publish_version instead, and no preconditions 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, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely non-obvious behavior: workspaces represent unpublished drafts and the free tier caps them at 3. It says nothing about pagination or result ordering, but with an output schema present the bar is lower.

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, with the resource definition front-loaded and the identifier formats following. The telegraphic style ('Container as public id...') is dense but each clause carries information; a short lead-in verb would improve readability without adding length.

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

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

For a one-parameter read tool with full annotation coverage and an output schema, the description covers what the tool returns at a conceptual level, the required input and all its accepted formats, and the nature of workspaces. Nothing an agent needs in order to invoke it 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 coverage is 0% – the single 'container' parameter has no description in the schema – so the description must carry the burden, and it does: it enumerates accepted identifier forms (GTM-XXXXXXX, a linked G-/AW- destination id, or the full accounts/<a>/containers/<c> API path). That is meaningful added semantics beyond the bare string type.

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 resource (workspaces) and its parent scope (of a container), which is specific enough to distinguish it from gtm_list_containers or gtm_list_environments. The verb is only implied by the tool name rather than stated, and it never explicitly contrasts with gtm_get_workspace_status or gtm_create_workspace, so it falls short of a 5.

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

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

There is no explicit guidance on when to call this versus siblings such as gtm_get_workspace_status or gtm_list_containers. The parenthetical 'unpublished drafts; free tier allows 3' gives useful ambient context for interpreting results, but it does not tell the agent when this tool is the right choice.

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 destructive/non-idempotent/open-world, and the description adds value beyond them: the real-world effect on all site visitors, the authorization and role requirements, the two-gate safety mechanism, and the rollback procedure. This is exactly the extra context annotations cannot express.

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 highest-stakes fact (goes live for everyone) before prerequisites and rollback. No filler; every clause carries actionable 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 destructive, open-world mutation, the description covers impact, prerequisites, safety gates, and reversal, and an output schema exists so return values need no explanation. 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 0%, so the description must carry parameter meaning, and it explains the two least obvious ones well: dry_run defaults to a diff view, and confirm must be true alongside dry_run=false. version_id is implied through the rollback sentence, but the 'container' parameter's expected form (id vs. path vs. name) 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 ('Make a container version LIVE') plus the blast radius ('for every visitor of the website'), which separates it cleanly from gtm_create_version and gtm_get_live_version. The 🔴 marker in the title and description signals severity without ambiguity.

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 names the alternative mode ('dry_run (default) shows the version vs the current live version') and the exact preconditions for the live path: auth --with-writes, Publish role, dry_run=false AND confirm=true. It also supplies recovery guidance ('Rollback = publish the previous version id'), so both when-to-use and what-to-do-after 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 read-only, idempotent, open-world, and non-destructive behavior, so the description adds meaningful context with the 50 KB truncation limit. It does not cover error behavior or rate limits, but the truncation disclosure is a concrete behavioral trait beyond annotations.

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

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

Two compact sentences, front-loaded with the core verb and scope. The example and truncation warning are useful and not 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?

Given rich annotations and an output schema, the description covers the main invocation shape, path syntax, and output limit. The remaining gap is the optional params parameter, which is neither described in the schema nor the description.

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 compensate. It does explain the required path format with a concrete example, but it says nothing about the optional params object, leaving one of two parameters undocumented.

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

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

States a specific verb and resource: GET any Tag Manager v2 resource path. The escape-hatch framing and path example clearly distinguish it from the many dedicated list/get/create sibling tools.

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

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

Explicitly says to use it for things no dedicated tool covers, which gives a clear when-to-use condition. It does not name specific sibling alternatives, but the category-level exclusion 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?

Adds substantial context beyond the annotations: it discloses the two possible outcomes (restore vs. remove), clarifies that removal is scoped to the workspace and that the live container is never touched, and flags dry_run as a preview. That directly supports and explains the destructiveHint=false annotation rather than contradicting it.

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

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

One front-loaded sentence with a parenthetical clarification – no filler, and the most important scoping fact (live container untouched) sits before the dry_run note.

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?

An output schema exists, so return values need no explanation, and the operation's semantics are fully described. The remaining gap is the unresolved workspace_id parameter, which an agent cannot resolve from description or schema.

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

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

Schema coverage is 0%, so the description must compensate, and it only partially does: it defines the entity_type domain (tag/trigger/variable/folder) and the meaning of dry_run. container, entity_id, and especially the optional workspace_id (default null – which workspace is used?) remain undocumented in both places.

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 ('undo/revert') plus the resource ('this workspace's changes to one tag / trigger / variable / folder'), enumerating the entity types covered. It is clearly distinguishable from the create_*/update_* siblings, which move in the opposite direction.

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 concrete usage context: restore a live version's copy, or drop an entity created in the workspace, with dry_run=true as a preview path. It does not name an alternative tool or state when NOT to use it, so it falls just short of a 5.

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

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

Beyond the annotations (which only say non-read-only, non-destructive, non-idempotent, open-world), the description discloses the key mutation semantics: existing triggers/tags are reused, events covered only by paused tags are reported rather than duplicated, and nothing is published until a version is created and published. It also gives the accepted measurement_id formats. That's substantial added behavioral context, not a restatement of 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?

Front-loaded with the plan/apply distinction and the core output (trigger + tag per event), then supporting details in descending importance; the final sentence about publishing gates is well placed. It is dense — parenthetical event-name lists and payload examples make it slower to parse than it needs to be — 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?

An output schema exists, so return values need not be explained, and the description covers purpose, safety gating, reuse/dedup behavior, and the publish workflow — enough for an agent to call this confidently. The remaining hole is the set of behavior-altering flags (include_optional_events, add_google_tag_if_missing), which an agent cannot reason about from the description alone.

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% across 9 parameters, so the description carries the whole burden. It explains only three: dry_run (with its default), events (subset selection), and measurement_id (accepted formats). Six parameters — container, workspace_id, tag_prefix, trigger_prefix, include_optional_events, add_google_tag_if_missing — are opaque in both schema and description, and the last two materially change what gets created.

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

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

The description states a specific verb pair (plan/apply) and a concrete resource composition: one Custom Event trigger plus one GA4 event tag per missing ecommerce event, in a named workspace. It also names the concrete artifacts ('send ecommerce data', dataLayer.push payload), so an agent can tell this bulk recipe apart from the singular gtm_create_ga4_event_tag / gtm_create_trigger siblings 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 gives explicit default behavior (dry_run=true plans, dry_run=false applies), a scoping option (`events` subset), and a clear workflow gate: 'Nothing goes live until gtm_create_version + gtm_publish_version.' What's missing is an explicit statement of when to prefer this over the singular tag/trigger creators, so the alternative is only implied.

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

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

Beyond the annotations, the description discloses three non-obvious behaviors: parameters merge by key with null meaning removal, the update is a read-modify-write protected by fingerprint against concurrent edits, and dry_run defaults to true so nothing changes unless explicitly disabled. These are exactly the details an agent needs before invoking a mutation with destructiveHint=false.

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 the action and capability list, then the two highest-risk details (merge semantics and concurrency safety), then the default preview mode. No filler and no repetition of schema fields.

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

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

The tool is a 10-parameter mutation with an output schema, so return values need no explanation, and the description covers the risky parts: merge semantics, concurrency, and the dry_run default. The gap is minor — the role of `workspace_id` and `notes` and the required-vs-optional split are left entirely to the schema.

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

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

Schema description coverage is 0%, so the description carries the whole burden. It adds genuinely valuable semantics for `parameters` (merge-by-key, null removes) and maps prose to `name`, `paused`, `firing_trigger_ids`/`blocking_trigger_ids`, and `dry_run`, but leaves `notes`, `workspace_id`, `container`, and `tag_id` entirely 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 opens with a specific verb+resource ('Change selected fields of an existing tag') and enumerates the concrete edits possible (pause/unpause, rename, swap triggers, set parameters). 'Existing tag' implicitly separates it from gtm_create_tag and gtm_get_tag, but no sibling is named, so the differentiation is inferred rather than stated.

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

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

There is real workflow guidance embedded in 'dry_run=true (default) shows a before/after diff only', which tells the agent the safe default and the preview path. However, there is no explicit when-to-use / when-not guidance and no routing to alternatives such as gtm_create_tag or gtm_get_tag for read-only inspection.

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