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

Annotations already declare readOnly=false, destructive=false and non-idempotent, so safety is covered. The description adds genuinely useful, non-obvious context: the change lands only in the workspace and 'the container is not published', telling the agent nothing goes live until a later publish step.

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 workspace-scoping constraint is front-loaded ahead of the publish 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?

The output schema covers return values and annotations cover safety, but for a 21-parameter, deeply nested creation tool with low schema description coverage, the description does not do enough to help an agent populate the parameter array correctly.

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

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

Schema coverage is only 43% across 21 parameters, including nested parameter/setupTag/teardownTag/consentSettings structures, yet the description explains none of them. It only gestures at the workspace requirement, leaving the heavy tag-configuration parameters undocumented in prose.

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

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

Specific verb+resource ('Create a tag') scoped to a workspace, which cleanly separates it from gtm_create_trigger, gtm_create_variable, and gtm_update_tag. It does not, however, explicitly name those siblings the way a 5 would.

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

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

It implies a workspace must already exist ('explicitly selected workspace'), but there is no when/when-not guidance or routing to alternatives such as gtm_update_tag for modifying an existing tag or gtm_create_workspace as a prerequisite. Usage must be inferred.

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

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

Annotations already declare the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true). The description adds one genuinely useful behavioral fact: the write lands in a draft workspace rather than live configuration. It says nothing about permissions, validation behavior, or what a failed create does.

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

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

A single front-loaded sentence with no filler words. It is efficient, though the brevity borders on under-specification for a 28-parameter mutation tool rather than being a model of tight structuring.

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 28-parameter creation tool with 21% schema coverage, the description is drastically incomplete — no guidance on trigger-type-dependent fields, filter formats, or draft/workspace lifecycle. An output schema exists so return values needn't be covered, but that does not excuse the missing parameter and workflow context.

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

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

Schema description coverage is only 21% across 28 parameters, so the description must compensate and it contributes zero parameter meaning. Even limit, filter, parameter, customEventFilter and the trigger-type-specific fields described only by unhelpful $refs are left 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 a trigger') plus a scoping constraint ('in an explicitly selected workspace draft'), which lets an agent tell it apart from gtm_create_tag or gtm_create_variable. It stops short of any differentiation from the closely related trigger siblings (update/delete/revert).

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

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

The phrase 'explicitly selected workspace draft' implies a prerequisite — a workspace must already be chosen before calling — but the description never states when to use this versus gtm_create_trigger alternatives or what happens if no workspace is set. Usage is implied rather than specified.

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 a non-read-only, non-idempotent, open-world mutation that is not destructive. The description adds the meaningful fact that the write targets a workspace draft rather than a live container. It says nothing about duplicate-name behavior (not idempotent), required permissions, or what happens if the workspace 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?

A single front-loaded sentence with no filler and the scope constraint stated immediately. It is arguably too sparse for an 11-parameter mutation, but nothing in it is wasted.

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

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

An output schema exists, so return values need no explanation, but for an 11-parameter nested mutation the description supplies no parameter guidance, no prerequisite details (account/container/workspace resolution), and no note on draft-vs-live semantics beyond the word 'draft'. It is materially under-specified for the tool's complexity.

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

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

With 11 parameters, nested objects, and only 45% schema description coverage, the description must compensate for the undocumented fields (notes, parameter, formatValue, parentFolderId, enablingTriggerId, disablingTriggerId). It mentions none of them, adding zero semantic value beyond the schema.

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

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

States a specific verb ('Create') and resource ('user-defined variable'), and scopes it to a workspace draft, which separates it from gtm_create_tag/gtm_create_trigger and from gtm_update_variable. It does not name a sibling directly, so an agent must infer the boundary, but the purpose itself 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?

The phrase 'explicitly selected workspace draft' implies the prerequisite context (a workspace must be chosen, and changes land in a draft rather than production), which is useful. However, it never states when to create a variable versus updating an existing one, nor any exclusion or alternative tool.

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 safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true), so the bar is lower, but the description adds no behavioral context beyond that: no auth/permission requirements, no note on whether the new workspace is isolated from the default one, and no rate-limit or reversibility detail.

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

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

Two short sentences, with the core action front-loaded and the workflow hint second. Nothing is wasted, though the second sentence is terse enough to be slightly ambiguous.

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. Still, for a 4-param creation tool with half the parameters undocumented, the description omits where the workspace is created and any prerequisite listing of accounts/containers.

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

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

Schema coverage is only 50% (account and container are documented, name and description are not). The description mentions no parameters at all, so it does not compensate for the undocumented fields or clarify the account/container/name relationship needed to place the workspace correctly.

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 dedicated GTM workspace'), which is easy to distinguish from sibling read tools like gtm_list_workspaces. It does not, however, explicitly contrast itself with other mutating siblings such as gtm_sync_workspace or gtm_create_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?

'Prefer this before making automated changes' is a genuine when-to-use hint, giving the agent a workflow ordering rule. It stops short of naming alternatives, prerequisites, or when not to create a workspace, so guidance is implied rather than explicit.

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

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

Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true, so the safety profile is covered. The description adds the useful fact that removal applies to a draft rather than the live container, but does not say whether the change is permanent, whether a sync is needed to propagate it, or whether it can be undone.

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

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

A single efficient sentence with the action and scope front-loaded and no filler. The 'explicitly selected' wording is slightly ambiguous but does not waste 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?

An output schema and rich annotations exist, so return values and safety are covered. However, for a 4-required-param destructive mutation in a draft/sync workflow, the description never mentions the draft-to-live propagation step, which an agent needs to sequence correctly.

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

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

Schema coverage is 75% and account/container/workspace already carry descriptions; tagId is undocumented but self-evident. The description reinforces that the workspace must be explicitly supplied and that all operations target a draft, but adds no syntax or format detail beyond the schema. Baseline 3 applies.

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

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

States a specific verb and resource ('Delete a tag') plus a scoping qualifier ('from an explicitly selected workspace draft'). It is clearly distinguishable from gtm_revert_tag and gtm_update_tag. It stops short of naming the sibling alternative, so 4 rather than 5.

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

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

No statement of when to use this versus gtm_revert_tag (which also removes a tag's effect) or when deletion is inappropriate. Usage context is only implied by the phrase 'workspace draft'. No prerequisites or follow-up steps 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 destructiveHint=true and idempotentHint=false, so the safety profile is covered. The description adds the useful nuance that the deletion is confined to the draft workspace rather than the live container, but it says nothing about irreversibility or required permissions.

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

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

A single front-loaded sentence with zero filler; the scope qualifier (workspace draft) is placed where it matters most.

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. For a destructive mutation, though, the description remains thin on side effects and downstream implications (e.g., whether the trigger still exists live), which is the kind of context an agent needs before deleting.

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

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

Schema description coverage is 75% (account, container, workspace documented; triggerId self-evident), so the schema does most of the work. The description's phrase "workspace draft" reinforces the workspace parameter's own note that it is required for every mutating operation but adds no new syntax or format detail.

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 (delete), resource (trigger), and scope (workspace draft), so the operation is unambiguous. It does not, however, distinguish itself from the sibling revert_trigger, which is the closest alternative an agent might confuse it with.

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

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

"Explicitly selected workspace draft" implies that a workspace must be chosen first, giving some context. But there is no explicit when-to-use vs revert_trigger guidance, no stated prerequisites, and no exclusions, leaving the selection logic to inference.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, lowering the bar. The description adds real context beyond them: that only user-defined variables are eligible, and that the deletion targets a workspace draft rather than the live container.

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

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

A single front-loaded sentence with no filler; the scope qualifier earns its place by narrowing which variables are affected.

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?

Annotations cover the safety profile and an output schema covers return values, so the description needn't explain those. It supplies the key scoping context, though it omits whether the deletion is reversible via revert_variable.

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

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

Schema description coverage is 75% and three of four parameters are documented in the schema, so the baseline is 3. The description adds no syntax or format detail for variableId, the one undocumented 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?

States a specific verb and resource ('Delete a user-defined variable') and narrows scope with 'from an explicitly selected workspace draft.' It doesn't name a sibling alternative (e.g. revert_variable), so it is clear but not fully differentiated.

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

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

No when-to-use guidance, no prerequisites, and no mention of alternatives such as gtm_revert_variable (which restores a variable) or gtm_update_variable. The only hint is the scoping phrase 'explicitly selected workspace draft,' which is implied rather than stated as 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, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds one useful behavioral detail - that the read targets draft workspace state rather than a published container - but says nothing about rate limits, auth, or pagination.

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

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

A single front-loaded sentence with no wasted words; the verb, resource, and scoping qualifier all appear immediately.

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

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

With an output schema covering return values and annotations covering the safety profile, the description only needs to disambiguate from list/other getter tools, which it does. It could be more complete by clarifying the default-workspace fallback for reads, but it is largely sufficient.

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

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

Schema coverage is 75%, so account, container, and workspace are already documented in the schema, and the output schema handles returns. 'By ID' loosely maps to tagId (which lacks a schema description) and 'workspace draft' hints at the optional workspace parameter, but no additional format or syntax detail is added.

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 one tag by ID') plus scope ('from a workspace draft'), which clearly separates it from gtm_list_tags. It does not name the sibling tools explicitly, so it stops short of a 5.

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

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

Usage is only implied: fetch a single tag when its ID is known, as opposed to gtm_list_tags for enumeration. There is no explicit when-to-use/when-not-to-use statement or named alternative.

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, destructiveHint=false and openWorldHint, so the safety profile is fully covered structurally. The description adds only the workspace-scoping context, which the schema already explains ('Omit only for reads to use Default Workspace'); it says nothing extra about error behavior or what is returned.

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

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

A single eleven-word sentence with zero padding and the resource front-loaded. It is appropriately sized, though borderline under-specified rather than maximally informative.

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, and the annotations cover the safety profile. What is missing is usage context and any differentiation from the dozen sibling get/create/list tools, leaving the definition merely adequate for a single-resource read.

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

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

Schema coverage is 75% (account, container, workspace documented; triggerId bare), and the description's 'by ID' implicitly maps to triggerId, adding a small amount of meaning. With high-but-not-complete coverage the schema carries most of the load, so baseline 3 fits.

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 one trigger') plus a scope qualifier ('by ID from a workspace'), which clearly separates it from the sibling gtm_list_triggers. It does not explicitly name siblings or contrast with gtm_get_tag/gtm_get_variable, so it stops 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?

No indication of when to use this versus gtm_list_triggers or the other get_* tools, and no prerequisites (e.g. that the trigger must already exist, or how to obtain a triggerId). The only implied guidance is 'by ID', which is naming, not usage.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is fully covered. The description adds one useful qualifier ('user-defined', distinguishing from built-in variables) and the workspace scope, but says nothing about not-found behavior or error conditions.

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

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

A single front-loaded sentence with the operation, resource, and locator scope in order. No filler words; every element earns its place.

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

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

With an output schema covering return values and annotations covering the safety profile, the core is present. Still, for a getter it omits what identifies a valid user-defined variable versus a built-in one and what happens when the ID is unknown, leaving clear 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 coverage is 75% (account, container, workspace documented; variableId is not). The phrase 'by ID' lightly reinforces that variableId is an identifier, and 'from a workspace' hints at the optional workspace parameter, but no format or syntax is added beyond the schema. Baseline 3 is appropriate.

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

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

The description states a specific verb ('Get'), resource ('user-defined variable'), and scope ('by ID from a workspace'), which cleanly separates it from the sibling gtm_list_variables. However, it does not explicitly name any alternative tool, so sibling differentiation 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?

There is no when-to-use guidance, no mention of prerequisites (e.g. needing an existing variableId), and no pointer to alternatives like gtm_list_variables for discovery. The agent must infer usage entirely from the tool name.

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 and idempotency profile is covered by structured data. The description adds only the auth-scoping detail that results are limited to the authenticated user; it says nothing about pagination or result size, which matters for a potentially long list.

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

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

A single front-loaded sentence with no filler. Every word earns its place and the scope qualifier is included without padding.

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

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

An output schema exists, so return-value explanation is unnecessary, and the annotations carry the safety profile. For a zero-parameter listing tool the description is essentially complete; only the absence of any routing hint toward the account/container/workspace hierarchy keeps it from a 5.

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 nothing for the description to disambiguate; the baseline of 4 applies. No parameter semantics are needed or 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?

States a specific verb (list) plus the resource (GTM accounts) and the scope of the result set (accessible to the authenticated Google user). Distinguishable from siblings like gtm_list_containers and gtm_list_workspaces, though it does not explicitly note that accounts are the top-level resource containing those.

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

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

No explicit when-to-use guidance, no mention of prerequisites, and no reference to any sibling. An agent must infer that this is the discovery entry point for obtaining account IDs. Nothing is misleading, but nothing routes the agent either.

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, covering the safety profile. The description adds no behavioral context beyond restating the list operation—no mention of pagination, result size, 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?

A single clear sentence with no wasted words, front-loading the operation and scope. It is appropriately sized for a simple list tool, though extremely terse.

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

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

Given the output schema exists and annotations cover the safety profile, the description need not explain return values or permissions. It is complete enough for a simple list operation, though it could mention ordering or result handling.

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

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

Schema description coverage is 100%, so the schema fully documents the required account parameter. The description adds no additional meaning beyond what the schema provides, making the baseline score of 3 appropriate.

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

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

The description states a specific verb (list) and resource (containers) with clear scope (every container in an account). It distinguishes from siblings like gtm_list_accounts and gtm_list_workspaces by targeting containers specifically, but does not explicitly name alternatives.

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 guidance is given on when to use this tool versus alternatives such as gtm_list_workspaces or gtm_list_accounts. The description simply states what it does, leaving the agent to infer usage context.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavioral context by disclosing that it auto-follows 'all result pages', i.e. pagination is handled internally — useful information not present in the annotations.

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

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

A single tight sentence that front-loads the scope ('every tag in a workspace draft') and then the key behavioral detail (pagination). No filler or redundancy.

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 values need not be explained, and the pagination caveat is included. The main remaining gap is the absence of any routing guidance toward gtm_get_tag or the other list_* siblings, but for a simple read tool this is largely complete.

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

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

Schema description coverage is 100%, so account, container and workspace are already fully documented in the schema (including the 'omit to use Default Workspace' note). The description adds no syntax or format detail beyond that, so the baseline of 3 applies.

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

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

The description states a specific verb and resource ('List every tag') and scopes it to 'a workspace draft', which distinguishes it from the sibling gtm_get_tag and the other list_* tools. It does not, however, explicitly name an alternative or contrast with get_tag, so it stays just short of a 5.

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

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

Usage is implied by the phrase 'in a workspace draft', which signals the context in which this listing applies, but there is no explicit when-to-use guidance and no when-not/exclusion. The agent must infer that gtm_get_tag is the single-tag counterpart.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds one genuinely useful behavioral detail beyond the annotations – that it auto-follows all result pages – but says nothing about result volume, ordering, or failure behavior during pagination.

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

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

A single front-loaded sentence with zero filler; every word carries meaning and the scope constraint is stated first.

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 values needn't be explained, and annotations cover safety. The description is therefore adequate but thin – it omits any usage routing and behavioral notes that would help the agent choose this over gtm_get_trigger.

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

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

Schema description coverage is 100%, so all three parameters (account, container, workspace) are already documented in the schema with examples. The description adds no additional parameter semantics, so the baseline 3 applies.

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

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

States a specific verb+resource ('List every trigger in a workspace'), which is clear and immediately distinguishable from gtm_get_tag/gtm_list_tags. However it doesn't explicitly distinguish itself from the sibling gtm_get_trigger, 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?

No guidance on when to use this versus alternatives like gtm_get_trigger (single fetch) or other list tools. There are no prerequisites or exclusions stated; the agent must infer that this is the bulk-listing path from the name alone.

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

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

Annotations already declare readOnly, idempotent, non-destructive and open-world, so the safety profile is covered. The description adds a genuinely useful behavioral fact beyond them: it automatically follows all result pages, so the agent knows it will not need to paginate manually. It says nothing about result volume or error behavior, keeping it short of a 5.

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

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

A single sentence with zero filler that front-loads the action, the scope and the pagination behavior. Every clause earns its place.

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

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

With an output schema present, rich annotations and fully documented parameters, the description only needs to add what structured fields cannot. It supplies the auto-pagination behavior and scope, though it leaves usage routing to the sibling tools unaddressed.

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

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

Schema description coverage is 100% and each parameter (account, container, workspace) is already documented in the schema, including the note that workspace may be omitted for reads. The description adds no format or default detail beyond that, so the baseline 3 applies.

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

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

States a specific verb and resource ('List every user-defined variable') plus its scope ('in a workspace'), which cleanly separates it from the singular gtm_get_variable sibling. It does not, however, explicitly contrast itself with the other list_* tools in the family, so sibling routing relies on the name alone.

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 never says when to prefer this tool over gtm_get_variable or how it relates to the other list_* tools, nor does it state prerequisites such as needing a container first. Usage is only inferable from the verb 'List every', which is minimal 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, idempotentHint, openWorldHint, and destructiveHint=false. The description adds no further behavioral context such as auth requirements, pagination, or return format, so it does not go beyond structured data.

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

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

A single front-loaded sentence with no filler. It states the scope and action efficiently.

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

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

Given the simple list operation, rich schema, annotations, and an output schema, the description is sufficient. It does not need to explain return values, and the schema covers parameters.

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

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

Schema description coverage is 100%, so both required parameters (account, container) are fully documented in the schema. The description adds no extra parameter meaning, so baseline 3 applies.

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

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

The description pairs the verb 'List' with the specific resource 'workspace' and scopes it to a GTM container. This distinguishes it from siblings like gtm_create_workspace and gtm_list_containers 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?

No when-to-use guidance, prerequisites, or alternatives are given. The agent must infer that it is for enumerating workspaces when needed; no exclusions or sibling comparisons are provided.

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 safety profile (readOnlyHint=false, non-destructive, non-idempotent, open-world), and the description adds genuinely useful context: it creates a temporary preview, surfaces compiler/sync errors, and explicitly does not publish. This complements rather than repeats the annotations.

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

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

Two short sentences, no filler, with the core action front-loaded and the non-publishing constraint appended as a useful qualifier. Every phrase earns its place.

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

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

For a low-complexity, three-parameter tool with an output schema (so return values need no prose) and full annotation coverage, the description supplies the essential behavior. Slight gap: it doesn't say whether compiling mutates workspace state or what the temporary preview resource is.

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

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

Schema description coverage is 100%, and all three required parameters (account, container, workspace) are fully documented in the schema, so the description adds nothing beyond the structured fields. Baseline 3 is appropriate.

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

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

States a specific verb and resource ('Compile a workspace into a temporary preview') plus the output ('report compiler/sync errors'), so the agent knows exactly what the call produces. It doesn't name sibling tools like gtm_sync_workspace or gtm_workspace_status, so differentiation relies on the reader inferring from the semantics.

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

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

The phrase 'temporary preview' and 'never publishes' imply this is a dry-run validation step before publishing, but no explicit when-to-use or when-not-to-use guidance is given, and no alternative sibling is named (e.g. sync vs preview).

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

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

Annotations already declare destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the safety profile is covered structurally. The description adds the 'optimistic fingerprint protection' concept, hinting that stale fingerprints cause conflicts, but never explains what the fingerprint is or what happens on a conflict.

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

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

A single front-loaded sentence with no wasted words; the scope and behavioral qualifier arrive immediately. It is efficient, though arguably too terse for a destructive mutation.

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, which lowers the burden. Still, for a destructive, non-idempotent mutation the description omits conflict/failure behavior and any note that it targets uncommitted workspace state rather than published tags.

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

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

Schema description coverage is 75%, so the baseline-3 concession does not apply and the description must compensate. It mentions no parameters at all, and tagId in particular is undocumented in both schema and description, leaving the gap unfilled.

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 (revert) and resource (workspace changes to a tag), clearly distinguishing it from gtm_update_tag and gtm_delete_tag. It does not, however, contrast itself with the parallel gtm_revert_trigger/gtm_revert_variable/gtm_sync_workspace siblings or clarify what 'revert' restores to.

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 when-to-use guidance: nothing says when a revert is preferable to gtm_update_tag, gtm_delete_tag, or gtm_sync_workspace, nor any prerequisite about having pending workspace changes. The agent must infer the use case from the name alone.

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

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

Annotations already declare destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the safety profile is covered. The description adds one genuinely useful trait beyond that – fingerprint protection – but leaves its behavior (what happens on mismatch, recoverability) unexplained.

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

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

A single front-loaded sentence with no filler; the verb and resource come first. It is arguably too terse to be fully useful, 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?

An output schema exists, so return values need no explanation, and annotations cover the destructive/idempotency profile. However, for a mutation tool the description omits the central mechanic it alludes to (fingerprint protection) and gives no usage routing, leaving gaps an agent must guess at.

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

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

Schema coverage is 75%, with triggerId undocumented in both schema and description; the description adds no parameter meaning at all. With most parameters already documented by the schema, this sits at the expected baseline but does not compensate for the triggerId 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 states a specific verb (revert), resource (trigger), and scope (workspace changes), which cleanly distinguishes it from gtm_revert_tag and gtm_revert_variable. It stops short of naming an alternative or clarifying how it differs from gtm_update_trigger / gtm_delete_trigger.

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

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

There is no explicit when-to-use or when-not-to-use guidance and no alternatives named, despite many close siblings (gtm_update_trigger, gtm_delete_trigger, gtm_revert_tag). The trailing 'with fingerprint protection' hints at a precondition but never explains what it means or when it matters.

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

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

Annotations already declare destructiveHint=true, idempotentHint=false, and openWorldHint=true, so safety is covered structurally. The description adds genuine context with 'fingerprint protection', signaling a concurrency safeguard, though it does not explain what the fingerprint is or whether the caller must supply one.

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

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

A single front-loaded sentence with no filler; the verb and scope come first. It is efficient, though the trailing clause about fingerprint protection sits at the end where it is easy to miss.

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 values need no explanation, and annotations cover the safety profile. However, for a destructive, non-idempotent mutation on 4 required params, the description omits prerequisites and the mechanism that 'fingerprint protection' implies, leaving a notable 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 75% (variableId is undocumented), just under the 80% baseline. The description adds nothing about parameters, so it neither compensates for the variableId gap nor clarifies the workspace scoping already shown in the schema.

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

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

States a specific verb ('Revert') and resource ('workspace changes to a user-defined variable'), which cleanly separates it from gtm_update_variable and from gtm_revert_tag/gtm_revert_trigger. It never explicitly names those siblings, but the resource noun makes the distinction inferable.

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

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

The description says what reverting does but gives no when-to-use guidance, no condition that selects revert over update_variable, and no exclusions. The agent must infer usage from the verb alone.

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

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

Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true, so the safety profile is covered. The description goes beyond that by disclosing the concrete behavioral outcome — workspace entities may be modified and conflicts may be surfaced — which tells the agent something the annotations alone do not.

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

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

Two sentences, no filler, and the core action is front-loaded before the side-effect caveat. Every clause earns its place.

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

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

An output schema exists, so return values need not be described. The description covers the action and its mutation/conflict side effects adequately; only minor gaps remain (permission requirements, whether conflicts are reported or block the sync).

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

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

Schema description coverage is 100%, with each of account/container/workspace documented in the schema itself (including the note that workspace is required for mutating operations). The description adds no parameter-level detail, so the baseline 3 applies.

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

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

States a specific verb (sync) and resource (workspace) plus the counterpart it syncs against (latest container version), which is far more informative than a tautology. It does not, however, distinguish itself from adjacent siblings such as gtm_workspace_status or gtm_quick_preview_workspace.

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 never says when to reach for this tool versus gtm_workspace_status, gtm_quick_preview_workspace, or gtm_list_workspaces. Usage is only implicitly suggested by the word 'sync'; there are no exclusions, prerequisites, or alternative routing.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the safety profile is covered. The description adds important behavioral context beyond that: it fetches the current tag, merges selected fields, and checks the fingerprint for concurrency safety. It does not, however, explain permission requirements or what happens to unmentioned fields.

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

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

A single, front-loaded sentence that states the action and the safety mechanism with no wasted words. Efficient given what it chooses to cover.

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

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

For a complex 22-parameter mutation tool with nested objects and only 45% schema coverage, a one-sentence description is insufficient. Although an output schema exists so return values need not be explained, the description omits guidance on the many optional and nested parameters, required identifiers, and failure behavior.

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 22 parameters and only 45% schema description coverage, the description needs to compensate for undocumented parameters but does not. It only broadly says 'selected tag fields' without clarifying which fields are optional, how nested parameter objects map to GTM types, or how fields like setupTag/teardownTag behave.

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 ('update'), resource ('tag fields'), and scope ('selected tag fields'), which clearly distinguishes it from siblings gtm_create_tag, gtm_delete_tag, and gtm_revert_tag. The description also names the update mechanism (fetch, merge, fingerprint check), so an agent knows this is a partial-update operation, not a replace.

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

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

The phrase 'update selected tag fields' implies partial updates as opposed to full replacement, but the description never explicitly states when to use this over gtm_create_tag or gtm_revert_tag, nor does it note prerequisites or exclusions. Usage is implied rather than guided.

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

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

Annotations already declare destructiveHint=true, idempotentHint=false, openWorldHint=true, so the safety profile is covered. The description adds one genuinely useful behavioral fact beyond that – 'fingerprint conflict protection' – implying optimistic-concurrency semantics. However it never explains what a fingerprint is, how a conflict is surfaced (error? retry?), or that changes are confined to a workspace, so the added context is suggestive but incomplete.

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

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

A single front-loaded sentence with no filler; the key action and the conflict-protection trait come first. It is arguably too terse for a 29-parameter mutation tool, but as a conciseness/structure measure it wastes nothing.

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, non-idempotent mutation tool with 29 parameters and 24% schema coverage, this description is far too thin. The output schema exists so return values need not be explained, but partial-update mechanics, conflict handling, and workspace prerequisites are all left implicit.

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

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

Schema description coverage is only 24% across 29 parameters, so the description carries a heavy burden – and it provides essentially none. 'Selected trigger fields' is the only hint about parameter behavior, leaving the vast majority of params (limit, interval, selector, visibility fields, etc.) undocumented 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?

The description names a specific verb ('update') and resource ('trigger fields'), and 'selected fields' signals partial-update semantics rather than a full replace. It is clear what the tool does, though it offers no explicit differentiation from siblings like gtm_revert_trigger or gtm_create_trigger.

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 when-to-use guidance, no prerequisites (e.g. that workspace must exist and be current), and no alternatives named. An agent cannot tell from this text why it would pick gtm_update_trigger over gtm_revert_trigger or gtm_sync_workspace.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so the safety profile is covered. The description adds one genuinely new trait not present in annotations: fingerprint conflict protection (optimistic locking). However, it omits what happens on a conflict, whether unspecified fields are preserved, and whether type changes are allowed.

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

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

A single front-loaded sentence with zero filler; the key safety concept (fingerprint protection) is placed immediately after the action. Nothing is wasted, though brevity here comes at the cost of detail scored elsewhere.

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 12-parameter mutation tool with nested objects and a destructive annotation, one sentence is thin. An output schema exists so return values need not be described, but the description says nothing about conflict resolution, merge behavior, or variable-type specifics for a tool that edits deeply nested variable configuration.

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 50% across 12 parameters, so the baseline is 3. 'Selected variable fields' usefully signals partial-update semantics (only supplied fields change), which the schema does not state, but the complex parameter/parameter-array, formatValue, and enabling/disablingTriggerId inputs get no explanation beyond the schema.

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

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

States a specific verb+resource ('update ... variable fields') plus a scope qualifier ('selected fields'), so the operation is unambiguous. It does not distinguish itself from siblings like gtm_create_variable, gtm_revert_variable, or gtm_delete_variable, which an agent must infer from the name alone.

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 create/revert/delete, nor any stated prerequisites such as needing a workspace or a fresh fingerprint. The only implicit signal is 'update', leaving routing decisions entirely to the agent.

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, open-world behavior, so the safety profile is covered. The description adds the useful detail that the output includes both modified entities and merge conflicts, but says nothing about permissions, workspace resolution, or scope limits beyond what annotations provide.

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

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

A single sentence that front-loads the two payloads an agent cares about, with zero padding or redundancy.

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, and annotations carry the safety profile. The description is adequate for an agent to call this correctly, though it omits any routing against the preview/sync siblings.

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

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

Schema description coverage is 100%, so all three parameters (account, container, workspace) are fully documented in the schema itself, including the Default Workspace fallback for omitted workspace. The description adds no parameter-level meaning beyond that, so the baseline 3 applies.

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

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

States a specific verb ('Show') and a concrete payload ('modified entities and merge conflicts in a workspace'), so the agent knows exactly what it gets back. It does not, however, contrast itself with siblings like gtm_sync_workspace or gtm_quick_preview_workspace, leaving the agent to infer the boundary.

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

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

There is no explicit when-to-use guidance, no statement of prerequisites, and no named alternative among the many workspace tools. The intent (check state before syncing) is only implied by the word 'status'.

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