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

The annotations already indicate this is a mutating operation (readOnlyHint false) and not idempotent. The description adds minimal behavioral context beyond a parameter example, not disclosing side effects like tag creation limits, dependency requirements, or interaction with GTM's draft/sync model. It does not contradict annotations.

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

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

The description is intentionally minimal (a short sentence plus an example JSON block). The example, though lengthy, is structured and syntactically clear. Every element serves a purpose, though one could argue the example could be trimmed, it remains concise overall.

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 rich schema (100% coverage) and no output schema requirement, the description is mostly complete. The example helps with a common use case, but it doesn't clarify operational nuances such as required identity scopes, permission requirements, or interaction with the GTM workspace publish flow. This is adequate but not exhaustive.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds value by demonstrating a complex nested parameter structure (eventSettingsTable) that illustrates how to construct the recursive 'parameters' array. This example aids in understanding beyond schema types, though it is specific to GA4 tags.

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

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

The description clearly states 'Create a new tag in a workspace' which is a specific verb+resource. However, it does not differentiate from sibling operations like gtm_update_tag or gtm_create_trigger beyond the name, but the core purpose 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?

There is no explicit guidance on when to use this tool vs. alternatives. The example for GA4 event parameters implies a common use case but does not provide exclusions or compare to gtm_update_tag or gtm_create_trigger. No when-to-use instructions are present.

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?

No additional behavioral traits disclosed beyond annotations (none). Does not mention side effects, constraints, or prerequisites beyond required parameters.

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?

Description is concise, presents a clear list of common trigger types. Schema is well-organized with nested objects and enums. No 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?

Provides basic context about what triggers do, but lacks details on when to use specific types or how filters work beyond schema. Could include examples or usage notes.

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 includes descriptions for all parameters and provides type info and examples for filter structure, though some descriptions are terse (e.g., 'Name for the trigger').

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

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

The description clearly states the tool creates a trigger in a 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?

Lists common trigger types, which gives context, but lacks explicit guidance on when to use this vs. update/list tools. However, the verb 'create' and presence of other CRUD siblings make the purpose clear.

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

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

Annotations are minimal (all flags false) and provide no safety or side-effect hints. The description only states the create action and enumerates valid type codes. It does not disclose what happens after creation (e.g., response format, persistence), permission requirements, or any side effects. For a mutation tool, this is insufficient transparency beyond the annotations.

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

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

The description is extremely concise: one sentence stating the purpose followed by a bulleted list of variable types. It is front-loaded with the main action, and every line adds useful information. There is no redundancy or filler.

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

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

Given the tool has 6 parameters and no output schema, the description is incomplete. It does not explain how to structure the 'parameters' array for different variable types, nor does it mention any required configuration for specific types. There is no guidance on expected outcomes or prerequisites. The type list is helpful but leaves major gaps for an agent to successfully invoke 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?

The schema covers all 6 parameters with descriptions (100% coverage). The description adds significant value by mapping shorthand type codes (c, v, jsm, etc.) to human-readable variable types (Constant, Data Layer Variable, etc.), which is not present in the schema beyond a bare enum list. This helps an agent construct correct type values.

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

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

The description clearly states the action 'Create a new variable' with the resource 'in a workspace'. The verb and resource are specific, and it distinguishes from sibling create tools (e.g., create_tag, create_trigger) by naming the exact object type. The listing of common variable types further clarifies the tool's scope.

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

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

The description provides no explicit when-to-use or when-not-to-use guidance relative to sibling tools. It does not mention alternatives, prerequisites, or exclusions. The purpose is implied by the name, but there is no contextual direction for an agent deciding between this and other create tools or update/delete operations.

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 show readOnlyHint=false, openWorldHint=false, idempotentHint=false, destructiveHint=false, but the description does not mention mutation of the workspace, required permissions, or side effects like creating a version that may affect other resources. It does state a precondition (workspace changes / merge conflicts) and naming is straightforward. Some behavioral transparency is present through the annotations but the description itself adds limited extra context.

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

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

The description is two sentences, front-loaded with the main action, and avoids all fluff or repetition. It reads naturally and 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?

The tool has 5 fully-described parameters, annotations for mutability, and a necessary precondition is explained. Similar tools exist in the sibling list (e.g., sync, list versions, publish, create workspace), providing useful context. It does not cover error responses, permission requirements, or what exactly occurs on merge/publish - but as a moderate create tool with a schema this is adequately complete.

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

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

The input schema has descriptions for all parameters (100% coverage), e.g., account ID, container ID, workspace ID, version name/notes, and the explicit workspace precondition. The description adds little semantic value beyond the schema since the schema already fully documents each field; the precondition about merge conflicts is the only notable addition.

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

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

The description uses a specific verb-resource pair ('Create ... version from a workspace's changes') and states the workspace must contain changes and be free of merge conflicts. It clearly establishes the core operation but does not explicitly distinguish it from listing or publishing versions.

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 conveys prerequisites (workspace with changes, no merge conflicts) and implies usage for creating a version from a workspace, but it does not give explicit directions on when to choose this tool over siblings like gtm_publish_version or gtm_get_version.

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

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

Annotations already convey that this is not read-only, not idempotent, and not destructive. The description adds only the 'new workspace' creation context and does not discuss return values, duplicate-name behavior, or required permissions, but no contradiction exists.

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

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

A single, front-loaded sentence with no filler or redundant information. Every word contributes to conveying the core action and target resource.

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 create operation with full schema coverage and annotations, the description is adequate. It could mention that the container must already exist, but the schema includes container_id and sibling lookup tools help supply that 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?

The input schema covers 100% of parameters with descriptions, so the baseline is 3. The tool description itself adds no additional parameter meaning beyond the schema.

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

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

The description 'Create a new workspace in a container' uses a specific verb and resource, clearly identifying the operation. It is distinct from sibling create tools for tags, triggers, and variables, as well as workspace status/sync/list tools.

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

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

The verb 'create' implies when to use it, but the description provides no explicit guidance on prerequisites, when not to use it, or alternatives. It is minimally viable but lacks direct 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?

The description adds no behavioral context beyond what annotations already provide. Annotations indicate destructiveHint: true and readOnlyHint: false, so the agent knows it's a destructive write. The description simply repeats the action without disclosing implications such as whether the deletion is permanent, whether it affects other resources, or that it requires publishing to take effect. Since no additional context is added, the description contributes little beyond the annotations.

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

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

The description is one sentence, directly stating the action. It is concise, front-loaded, and contains no fluff. Every word earns its place, making it appropriately sized for a straightforward delete operation.

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 operation is simple, but the description lacks some operational context. For instance, it does not mention that deletions are workspace-local and must be published via gtm_publish_version to take effect, nor does it mention any reversibility since destructiveHint is true. Without an output schema, the agent might expect some confirmation, but none is described. The description is minimally complete but leaves out important deployment workflow nuances.

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%: all four parameters (tag_id, account_id, container_id, workspace_id) have descriptions in the schema. The tool description does not add any parameter-specific information. With high schema coverage, baseline is 3, and the description's lack of additional param guidance keeps it at that baseline.

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

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

The description clearly states the action: delete a tag from a workspace. It uses a specific verb ('delete') and resource ('tag'), and the scope ('from a workspace') adds clarity. It distinguishes from sibling delete tools for triggers and variables by naming the resource 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 guidance on when to use this tool versus alternatives. It does not mention prerequisites, conditions for deletion, or that this is a destructive action (though annotations cover that). Without context like 'use this to remove a tag that is no longer needed' or 'do not use if you only need to deactivate', the description offers no usage guidance beyond the basic action.

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

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

Annotations already indicate destructive and idempotent behavior. The description adds no additional behavioral context, such as irreversibility or side effects, beyond what annotations provide. It is neutral, neither contradicting nor augmenting.

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, clear sentence without unnecessary words. It is appropriately sized and front-loaded, directly conveying the tool's purpose.

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 simplicity of a delete operation and the presence of destructive and idempotent annotations, the description is sufficient. It does not need to explain return values (no output schema) and the annotations cover side-effect expectations. It is complete enough for the 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?

The input schema provides descriptions for all four parameters (account_id, trigger_id, container_id, workspace_id), achieving 100% coverage. The tool description does not add any further parameter meaning, so the baseline score of 3 is appropriate.

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

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

The description clearly states the action: 'Delete a trigger from a workspace.' It uses a specific verb ('Delete') and resource ('trigger'), distinguishing it from sibling tools like delete_tag or delete_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 implies usage when you want to delete a trigger, but it provides no explicit guidance on when to use it versus alternative tools or any conditions. It is merely a statement of function without contextual direction.

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

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

The annotations already convey that the tool is destructive (destructiveHint=true) and idempotent (idempotentHint=true). The description adds no further behavioral context, such as permanence, side effects, or concurrency implications. It is consistent with annotations but provides no additional insight, keeping it neutral.

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, concise sentence that is immediately front-loaded with the essential verb and object. There is zero wasted text, and it is appropriately sized for the simplicity of the operation.

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 delete operation, the description is adequate given the rich annotations (destructive, idempotent) and fully documented schema. It does not explain return values, but the absence of an output schema reduces the need. The description could optionally mention that deletion is permanent or irreversible, but that is already implied by the destructive annotation, so it remains sufficiently complete.

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

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

The input schema describes all four parameters with 100% coverage, so the baseline is 3. The tool description does not add any parameter-specific meaning beyond what the schema already provides. The parameters are straightforward identifiers, and the description does not clarify relationships or usage nuances.

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

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

The description clearly states the action (Delete), the resource (a variable), and the context (from a workspace). It effectively distinguishes this tool from siblings like delete_tag and delete_trigger, making its purpose unambiguous.

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

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

The description provides no guidance on when to use this tool versus alternatives, nor does it mention any prerequisites, exclusions, or conditions (e.g., 'use only if variable is not referenced' or 'see gtm_disable_variable for non-destructive removal'). It simply states the action without any contextual direction.

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

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

Annotations declare readOnlyHint=false, destructiveHint=true, and idempotentHint=true. The description adds that 'Tags or triggers still referencing them will break,' which clarifies the destructive impact beyond the annotation. This is valuable context for an agent evaluating risk.

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

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

The description is two sentences, both essential: the action and the consequence. No filler, front-loaded with the verb and resource.

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 tool is a straightforward mutation with 4 well-documented parameters, no output schema, and strong annotations, the description covers the purpose and key side-effect. It could mention idempotency or repeated calls, but that's minor; completeness is high.

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%: each parameter (account_id, container_id, workspace_id, types) has a descriptive comment. The description itself does not add further parameter details, so baseline 3 is appropriate; no gaps to compensate.

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 ('Disable') and resource ('built-in variables in a workspace'), clearly distinguishing it from siblings like gtm_enable_built_in_variables and gtm_list_built_in_variables. It also notes the impact on dependent tags/triggers, adding purpose 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?

The description implies when to use this tool (when you want to disable built-in variables) and warns about the consequence. However, it doesn't explicitly mention alternatives like enabling or listing, though the sibling list makes that context available. Adequate but could be more 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 declare idempotentHint=true, destructiveHint=false, and readOnlyHint=false. The description adds context by explaining why enabling is useful (so tags/triggers can reference variables), but does not add extra behavioral detail beyond the annotations. It does not contradict the annotations, and the annotation coverage reduces the need for additional disclosure.

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

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

The description is a single, efficient sentence that front-loads the verb and resource. It includes a clear purpose and examples without any filler, making every word earn its place.

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

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

The tool is straightforward and all parameters are documented in the schema. The description provides sufficient context for a mutation operation, and there is no output schema to explain. The annotations cover idempotency and non-destructiveness, so the description is complete enough for most use cases.

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%—all parameters have descriptions including the list of valid camelCase values for 'types'. The description adds no additional parameter-level detail beyond what the schema already conveys, so a baseline score of 3 is appropriate.

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

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

The description clearly states the action (enable), the resource (built-in variables), and the purpose (so tags and triggers can reference them). It provides concrete examples ({{Page URL}}, {{Click Classes}}) and is easily distinguished from siblings like gtm_disable_built_in_variables or gtm_list_built_in_variables.

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

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

The description implies usage (to enable built-in variables for referencing) but does not explicitly state when to use this tool versus alternatives. It lacks guidance on prerequisites or when not to use it, though its purpose is evident. There is no direct comparison to sibling 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?

The description mentions the tool is read-only, but the annotations already declare readOnlyHint=true and destructiveHint=false. The description adds minimal extra behavioral context (e.g., what fields are returned) but doesn't explain edge cases like invalid IDs or permissions. With annotations covering safety, this is acceptable but not rich.

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

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

The description is a single, efficient sentence that front-loads the key information. Every word adds value; no fluff 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?

For a simple read-only getter with full parameter schema and no output schema, the description is sufficiently complete. It lists the main return fields and implies the usage context. Could mention error conditions or authentication, but not critical for this straightforward 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?

The schema covers 100% of the parameters with descriptions, so the baseline is 3. The description doesn't add parameter-specific meaning beyond mentioning the container ID is used, but since schema fully documents them, it's adequate.

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

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

The description clearly states the verb 'Get' and the resource 'details of a specific container', listing the key fields returned (name, public ID, domains, usage context). It distinguishes from siblings like gtm_list_containers (which lists all containers) by specifying it's for a specific container.

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 usage when you need details of one container, but it does not explicitly say when to use this vs. gtm_list_containers or other tools. There's no exclusion criteria or alternative guidance, which is a minor gap.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is covered. The description adds no further behavioral context such as return format, error conditions, or authentication needs; it merely restates the core purpose.

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, concise sentence that directly states the tool's function without any redundant wording or filler. It is well-structured and front-loaded.

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

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

Given the tool's low complexity, full schema coverage, and safe read-only annotations, the description is nearly complete. It conveys the essential scope (live/published version), though it omits details about the response shape since no output schema is provided.

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

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

Input schema covers both parameters (account_id, container_id) with descriptions and patterns, giving 100% coverage. The description does not add additional meaning to the parameters beyond what the schema already provides.

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

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

The description uses a specific verb 'Get' and clearly identifies the resource as 'the container version that is currently live (published)'. This distinguishes it from sibling tools like gtm_list_versions (which lists all versions) and gtm_get_container (which gets container metadata).

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

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

The description implies its usage context by specifying 'currently live (published)', but it does not explicitly state when to use this tool versus alternatives or provide any exclusions. No mention of alternatives like gtm_list_versions or gtm_publish_version.

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

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

Annotations already declare readOnlyHint and idempotentHint as true, and destructiveHint false. The description adds value by specifying what kind of details are returned (parameters, triggers, configuration), which is not present in the annotations. This contextualizes the response content without contradicting 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, front-loaded sentence that immediately states the tool's purpose and key details. Every word adds value, with no redundancy or fluff. Ideal conciseness.

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

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

For a simple GET operation with all required parameters fully documented in the schema, the description sufficiently covers the tool's behavior. No output schema is present, so return values need not be detailed. The description's enumeration of 'parameters, triggers, and configuration' addresses the primary context an agent needs.

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

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

Schema coverage is 100% with each parameter having a clear description (e.g., 'The GTM tag ID'), so the schema already handles parameter semantics. The description does not need to add more, and the baseline of 3 is appropriate.

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

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

The description uses a specific verb and resource: 'Get full details of a specific tag', which clearly states the action and object. The phrase 'including all its parameters, triggers, and configuration' adds useful scope, and it distinguishes from sibling methods like gtm_list_tags or gtm_get_container.

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 guidance on when to use this tool versus alternatives. The description implies it is for retrieving a single tag's full details, but it does not mention when not to use it or compare with gtm_list_tags or gtm_get_trigger. This matches the 'no guidance' 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 provide readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds value by specifying what 'full details' includes (type, filters, conditions), giving context beyond the schema. It does not contradict annotations and adds meaningful behavioral context about the returned 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, concise sentence that is front-loaded with the verb and resource, and includes the key details of the return content. No fluff or redundant information. Fully earns its place.

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

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

The tool is simple (4 IDs to fetch a trigger), annotations cover read-only and idempotent nature, and the description mentions the key fields in the response (type, filters, conditions). With no output schema, this provides enough context for an agent to know what will be returned. It could optionally mention error handling, but that is not required for a read-only get operation. Overall it is complete for its 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 coverage is 100% with each parameter having a brief description (e.g., 'The GTM trigger ID'). The tool description adds no additional parameter semantics beyond what schema already states. The baseline is 3 when schema covers all parameters, and no extra insight is provided here.

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 'Get' and resource 'specific trigger', with details on what is included (type, filters, conditions). It clearly distinguishes from list_triggers, which is a sibling, by specifying it fetches a single trigger's full details. This is a clear and specific statement.

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 usage for retrieving details of a specific trigger, which is evident from the sibling tools (list_triggers for listing, create/update/delete for mutations). It provides clear context but does not explicitly exclude alternative tools or state 'when not to use'. However, the purpose is unambiguous enough that an agent can infer when to invoke it.

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

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

The description adds no behavioral information beyond the annotations (read-only, idempotent, non-destructive). It does not mention error handling, return format, or side effects, but since annotations already cover key traits, it is adequate but not enhanced.

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, clear sentence that efficiently communicates the tool's purpose without unnecessary detail. It is well-structured and front-loaded with the core action.

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 simplicity of a get operation, the description is sufficiently complete. It does not specify the exact return structure, but with no output schema and a read-only annotation, it does not omit critical information for a basic getter.

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

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

The input schema provides concise descriptions for each parameter (account ID, container ID, workspace ID, variable ID). The tool description does not add further meaning to these parameters, leaving their role implicit from the schema.

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

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

The description clearly states the tool's function: retrieving full details of a specific GTM variable, including its type and parameters. This effectively distinguishes it from sibling tools that create, update, delete, or list variables.

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

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

The description does not explicitly indicate when to use this tool instead of alternatives like listing variables or getting workspace status. While the name implies a targeted get operation, it lacks explicit guidance on selecting it over similar get/list tools.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful context — that results are relative to 'the last container version' and that merge conflicts are surfaced — but does not disclose output shape, size limits, or authorization nuances. No contradiction with annotations.

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

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

A single, front-loaded sentence states the verb and resource immediately and packs the scope definition ('since the last container version') and conflict detection into one clause. Every word earns its place with no fluff or repetition.

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

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

For a simple read-only status tool with three fully documented parameters and strong annotations, the description adequately conveys return semantics (pending changes + merge conflicts) despite lacking an output schema. Minor gap: no mention of how this status relates to the sync/publish workflow or what to do after conflicts are detected.

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% for all three required parameters (account_id, container_id, workspace_id), so the schema carries the parameter documentation burden. The description modestly adds context by implying workspace_id selects the workspace whose changes are inspected, but adds no format or syntax detail beyond the schema.

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

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

The description uses a specific verb ('Show') with a clearly defined resource: pending changes in a workspace, scoped as 'entities added, updated, or deleted since the last container version', plus merge conflicts. This distinguishes it from siblings like gtm_list_workspaces (listing workspaces) and gtm_sync_workspace (applying changes) since it targets status/conflict inspection.

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

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

The intended use case is implied rather than stated directly: check for pending changes or merge conflicts before versioning. No explicit when/when-not guidance is given, and no alternative tools (e.g., gtm_sync_workspace or gtm_get_live_version) are named for comparison, so the agent must infer placement in the workflow.

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

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

The description adds useful context beyond the annotations by clarifying the scope ('accessible by the service account') and the return payload ('IDs, names, and paths'). This complements the readOnlyHint and idempotentHint annotations without contradiction, though it does not discuss rate limits or error behavior.

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

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

The description is a single, concise sentence that front-loads the verb and resource, includes essential scope details, and contains no redundant words. Every phrase adds value.

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

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

For a simple list operation with one optional parameter and no output schema, the description provides all necessary information: purpose, scope, and return fields. It is sufficiently complete for an agent to use the tool correctly.

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

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

The single parameter page_token is fully described in the schema with a clear explanation. The tool description itself does not add parameter information, but given 100% schema coverage, the baseline of 3 is appropriate.

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

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

The description clearly states 'List all Google Tag Manager accounts accessible by the service account' with an explicit verb and resource. It distinguishes from sibling list tools (e.g., gtm_list_containers) by naming the resource type and adds scope ('accessible by the service account') and return fields ('IDs, names, and paths').

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 usage context by noting it lists accounts accessible by the service account, which hints at discovery of available accounts. However, it does not explicitly state when to use this tool versus alternatives or mention any preconditions or follow-up tools.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is covered. The description adds that the tool lists enabled built-in variables and their role in tags/triggers, but does not disclose pagination behavior despite the page_token parameter, missing an opportunity to add value 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?

The description is two sentences, front-loaded with the core purpose, and includes a useful contextual note. Every word earns its place with no redundancy or fluff.

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

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

For a read-only list operation with comprehensive annotations and full schema coverage, the description is mostly adequate. However, it fails to mention pagination even though a page_token parameter exists, and it does not explicitly distinguish against gtm_list_variables, leaving some ambiguity for a complex tool ecosystem.

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

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

Schema coverage is 100%, with all parameters described (IDs and page_token). The description adds no parameter-specific detail beyond what the schema provides, so it meets the baseline but does not enhance understanding of 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 clearly states the action ('List the built-in variables currently enabled in a workspace') with specific resource and scope. It includes examples (Page URL, Click Classes) and differentiates from sibling tools by focusing on 'built-in' and 'enabled' status, contrasting with gtm_list_variables which would list custom variables.

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

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

The description provides context by explaining that tags and triggers can only reference enabled built-in variables, which helps an agent understand when to use this tool. However, it does not explicitly mention when not to use it or reference sibling alternatives like gtm_list_variables.

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, covering the safety profile. The description adds scope ('all containers') and output fields, but it does not disclose that pagination may be required via page_token, despite 'all' implying a single complete response. This is a notable behavioral gap beyond the structured 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 sentence that is front-loaded with the action and resource, followed by the key returned fields. Every word earns its place with no fluff or repetition.

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

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

The description conveys the purpose and expected output sufficiently for a simple list operation with only two parameters and no output schema. However, the absence of pagination behavior disclosure makes it slightly incomplete; an agent might not realize 'all' may require multiple API calls despite the page_token parameter.

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%: account_id is documented as 'The GTM account ID' and page_token as 'Continuation token from a previous call to fetch the next page of results'. The description adds no additional 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 clearly states a specific verb ('List') and resource ('all containers in a GTM account'), and explicitly enumerates the returned fields (IDs, names, public IDs, domains). It naturally distinguishes from sibling tools like gtm_get_container, which targets a single container.

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 use for enumerating containers in an account, but provides no explicit when-to-use guidance or mention of alternatives such as gtm_get_container for a single container. It does not state any exclusions or conditions, leaving the decision to inference.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=false, destructiveHint=false; description adds returned data fields (IDs, names, types, trigger associations) and thereby extends beyond the annotations, though it does not discuss pagination or rate limiting.

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-loads the resource and return fields; no filler content.

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

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

Tool complexity is modest (4 params, output schema absent) but description covers returned trigger fields and listing scope; explanation of boolean annotations and sibling tags add context. Some pagination behavior not explicitly described but inferable from page_token param.

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

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

Schema coverage is 100% with descriptions for expected account_id, container_id, workspace_id, and page_token. Yet the description doesn't provide additional meaning beyond the schema for these params; page_token's continuation semantics is explained in schema, not in tool description, so baseline 3 is warranted.

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?

Description uses a specific verb 'List' with resource 'tags' and defines scope as workspace, and enumerates returned fields (IDs, names, types, trigger associations). This clearly distinguishes it from sibling tools like get_tag, update_tag, delete_tag, and list_triggers.

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

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

States context 'in a workspace' but provides no explicit comparison with alternatives (e.g., use gtm_get_tag for a single tag) or 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 readOnlyHint=true, idempotentHint=true, destructiveHint=false, covering the safety profile. The description adds the returned fields, which is useful. However, it does not disclose pagination behavior despite the page_token parameter, and the claim of 'all triggers' could conflict with paginated results. The description adds some context but not rich behavioral 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?

The description is a single, concise sentence with no fluff or redundancy. It efficiently conveys the tool's purpose and output contents.

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

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

For a simple list operation with annotations and full schema coverage, the description is mostly complete. It specifies the output fields but omits mention of pagination, which is relevant given the page_token parameter. Minor gap, but overall 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?

Schema description coverage is 100%, so all parameters are documented in the schema. The description says it lists triggers in a workspace, which reinforces the role of account_id, container_id, and workspace_id, but adds no new semantic detail beyond what the schema already provides. Baseline of 3 is appropriate given full schema coverage.

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

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

The description clearly states the tool lists all triggers in a workspace with specific output fields (IDs, names, types, filter conditions). This distinguishes it from siblings like gtm_get_trigger (single trigger) and gtm_list_tags (different entity).

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

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

The description implicitly indicates it is for listing triggers in a workspace, which is clear context. However, it does not explicitly mention when not to use it or name alternatives like gtm_get_trigger for specific triggers. The context is enough for a straightforward list operation.

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, so safety is covered. The description adds the output field details, but doesn't mention pagination or any behavioral caveats. It adds some value beyond annotations but not substantially.

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, clear sentence, front-loaded with the action and resource. No wasted words, perfectly concise.

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

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

For a simple list operation with strong annotations and complete schema, the description covers the return content (IDs, names, types) but does not explicitly mention pagination or output format. The optional page_token implies pagination, so it's reasonably complete.

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

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

Schema coverage is 100%, with all parameters documented. The description does not add any extra parameter semantics; it merely restates the listing purpose. Baseline 3 is appropriate since the schema already provides the necessary details.

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

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

The description clearly states the action (list variables), the resource scope (workspace), and the included fields (IDs, names, types). It distinguishes from gtm_get_variable (single variable) and other list tools (tags, triggers).

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

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

The description implies usage for listing variables in a workspace, but provides no explicit guidance on when to use this versus gtm_get_variable or how to handle pagination. No exclusions or alternatives are mentioned.

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

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

The description uses the verb 'List' which aligns with the readOnlyHint and non-destructive annotations, but it does not add any extra transparency about behavior beyond what the annotations already provide. It does not mention potential side effects, 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?

The description is a single sentence, directly to the point, with no unnecessary words. It clearly communicates the tool's function without verbosity.

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

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

The description sufficiently conveys the essential purpose and expected output. It does not explicitly mention pagination, but the presence of a page_token parameter implies it. Overall, it is complete enough for a straightforward list operation, but a slight gap exists regarding pagination 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?

The input schema already provides descriptions for each parameter (account_id, container_id, page_token), and the tool description does not add any additional meaning beyond that. Since schema coverage is 100%, the baseline is 3, and the description adds nothing new.

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

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

The description clearly states that the tool lists all container versions and specifies the returned fields (IDs, names, entity counts), making the action and resource unambiguous. It distinguishes itself from sibling tools that list other entities (accounts, containers, workspaces, etc.).

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 does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention conditions or limitations. However, the tool's uniqueness among siblings (only version-listing tool) makes its usage context implicit, but this is not stated explicitly.

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 disclose readOnlyHint=true, destructiveHint=false, idempotentHint=true, but the description itself does not explain behavior such as possible large responses, paging, or ordering. It conveys that it lists data without modifying it, but not additional side effects beyond annotation signals.

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?

Single sentence, uses imperative 'List all workspaces', presents all needed information with no wasted words.

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

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

For a simple read-only listing, it is justified by annotations and schema; no return protocol, and fields inferred. He does not tell how many, but enough to support.

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 JSON schema already describes the parameters with their patterns and optionality, but the description adds human labels 'ID', 'page token', and 'container ID'. However, no new semantics beyond the schema; necessary values are clear.

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 the specific action ('List all workspaces'), the target resource ('in a container'), and the returned fields (IDs, names, and descriptions). It clearly separates it from other workspace-related operations like get_workspace_status.

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?

This is strictly a list operation with no contrast to alternatives. It says nothing about when to prefer this list-as-block over a get-single-workspace or other list tools, nor does it mention pagination 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 indicate destructive behavior (destructiveHint=true). The description adds context by stating that it 'replaces the currently live container configuration' and makes it 'served to all visitors', which clarifies the impact beyond the annotation. No contradiction exists.

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 concise, consisting of two short sentences with no redundant information. It clearly communicates the action and its consequence without fluff.

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

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

Given the simple nature of the tool and rich schema, the description adequately explains the purpose and effect. It does not mention potential error conditions or preconditions (e.g., version must be a draft), but this is a minor gap for a straightforward publish action.

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 descriptions cover all three parameters (100% coverage), so the baseline is 3. The description does not add extra meaning to the parameters themselves, which are self-explanatory as account, container, and version IDs.

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

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

The description clearly states the tool's purpose: publishing a container version to make it the live version. It uses a specific verb ('Publish') and resource ('container version'), and distinguishes it from sibling tools like gtm_create_version (which creates a version) and gtm_get_live_version (which retrieves the live version).

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

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

The description implies when to use the tool (to replace the live version) and notes the effect, but it does not explicitly mention alternatives or conditions for non-use. The clarity of purpose partially compensates, but it lacks explicit '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 indicate idempotent and non-destructive behavior, but the description adds that it reports merge conflicts, which is not implied by the annotations. This is useful behavioral context beyond what annotations provide, though it does not detail other side effects like modifying workspace state.

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

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

Two concise sentences with no unnecessary words, clear structure, and directly communicate the purpose and behavior.

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 no output schema, the description adequately explains the operation and mentions merge conflict reporting. It does not explain the return value in detail, but that is not required since it's a simple sync action. It lacks details about failure modes, but that is acceptable for this 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?

The schema describes all three parameters with basic labels ('The GTM account ID', etc.), giving 100% coverage. The description does not add further meaning or relationships between these IDs, so it stays at the baseline for full coverage.

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

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

The description clearly states the tool's function: 'Sync a workspace to the latest container version' with a specific verb and resource, and distinguishes it from sibling tools like get/create/delete by indicating an update-like operation.

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

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

It explains when to use it ('pulling in changes published since the workspace was created') and mentions the merge conflict reporting, giving context. However, it does not explicitly contrast with alternatives like get_workspace_status or update operations, so it's not fully explicit about when not to use it.

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

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

Annotations already flag readOnlyHint=false, destructiveHint=true, and idempotentHint=true. The description adds valuable behavior beyond the annotations by explaining that only provided fields are changed and that provided array fields replace existing arrays wholesale, which is important update semantics for the agent to know.

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

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

The description is a single, front-loaded sentence that states the core action first and then the key behavioral caveat. Every word earns its place; there is no redundancy or filler.

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

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

Given the 9-parameter schema, full schema coverage, and the presence of safety annotations, the description covers the most critical behavioral nuance. It does not explain return values, but no output schema is defined and the schema/annotations already handle most operational 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 coverage is 100%, so the baseline is 3. The description adds extra meaning by clarifying the partial-update contract: omitted fields remain unchanged and array fields are replaced rather than merged. This is a meaningful addition beyond the individual parameter descriptions 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?

The description states 'Update an existing tag in a workspace' with a specific verb and resource, clearly distinguishing this mutation tool from sibling create/delete/get/list tag tools. The phrase 'existing tag' also clarifies that this is not for creation.

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

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

The description clearly implies this tool is for modifying an already existing tag, providing context for when it should be used. It does not explicitly name alternatives or exclusion cases, but the sibling tool names and 'existing tag' wording give adequate contextual guidance.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=true, idempotentHint=true, so the description does not need to repeat safety traits. It adds valuable behavioral context beyond annotations: 'Only the provided fields are changed' clarifies partial update semantics, and 'provided filter arrays replace the existing ones wholesale' explains replacement behavior. This is useful and not redundant with annotations.

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

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

Two clear sentences conveying essential behavior without fluff. The first sentence states purpose, the second adds critical update semantics. Efficient and front-loaded. Could be slightly more structured (e.g., bullet points) but it is appropriately concise for its content.

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

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

For a complex update tool with nested filter structures and no output schema, the description covers the key update semantics (partial vs. wholesale replacement). It does not describe the result or error handling, but with no output schema, that expectation is lower. The description is adequate for an agent to understand what will happen without over-specifying.

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 is documented (e.g., filter descriptions mention 'replaces existing'). The description adds a global note about updating only provided fields, which reinforces param semantics but does not explain individual parameters beyond what schema already provides. Baseline of 3 is appropriate given full schema coverage.

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

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

The description clearly states the action ('Update an existing trigger in a workspace') with a specific verb and resource. It distinguishes from create/delete by the word 'existing', but does not explicitly contrast with get or list operations. Clear enough for basic selection among siblings.

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

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

Usage context is implied: this is for updating an existing trigger, not creating or deleting. However, no explicit when-to-use or when-not-to-use guidance, nor mention of alternatives. The description does not state prerequisites (e.g., must have the trigger ID) but that is evident from required parameters. Minimal guidance beyond the obvious.

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

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

Annotations already convey readOnly=false, idempotent=true, and destructive=true. The description adds valuable behavioral context beyond those: partial updates ('Only the provided fields are changed') and wholesale replacement of parameters ('a provided parameters array replaces the existing parameters wholesale'). No contradiction with annotations.

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

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

Two tight sentences: the first states the core action and target, the second spells out the two key behavioral rules. No filler, no redundancy, and the most important information is front-loaded.

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

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

The description, combined with rich schema annotations and sibling context, fully explains what the tool does and the key caveat about parameter replacement. Missing return-value description is acceptable since no output schema exists, but a note about what the update returns would have added modest completeness.

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

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

With 100% schema description coverage the baseline is 3, but the description adds important cross-parameter semantics: omitting optional fields leaves them unchanged, while providing 'parameters' replaces the entire array. This clarifies how the optional parameters interact, going slightly beyond individual schema entries.

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

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

The description clearly states 'Update an existing variable in a workspace' with a specific verb and resource, distinguishing it from create/delete/list variable tools and from update_tag/update_trigger siblings. It also clarifies the scope (workspace) 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?

The phrase 'Update an existing variable' implies this tool is for modifying an already-created variable, providing clear context versus create/delete variants. It does not explicitly name alternatives or exclusion criteria, but the verb and resource are enough to guide selection among siblings.

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