Gtm Tag

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does mark remove and revert as '(destructive)' and requires confirm=true for them, which is valuable safety disclosure. However, it does not describe return values, error behavior, authentication needs, or what happens to related entities on removal — gaps for a mutation-focused tool with zero annotation coverage.

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 well structured: a one-line purpose statement followed by a compact bullet list of actions with their parameters. It is front-loaded and each line is minimal. Minor redundancy exists in repeating '<workspace>/tags/{tagId}' across get/update/remove/revert, but overall it is efficient and scannable.

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 6 parameters, 0% schema coverage, and no annotations, the description is moderately complete. It covers action-to-parameter mapping and marks destructive operations. However, the unexplained 'params' parameter, undefined 'config' structure, unspecified 'action' values, and absence of error/return behavior (the output schema partially mitigates the return gap) leave meaningful holes for an agent needing to invoke it correctly.

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

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

Schema description coverage is 0%, so the description must compensate. It does map which parameters each action uses (list→parent, get→path, create→parent+config, update→path+config, remove/revert→path+confirm), which adds real meaning beyond the bare schema. However, the 'params' parameter is never explained, the 'action' enum values are not enumerated, and the expected structure of 'config' is left undefined, so compensation is only partial.

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

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

The description states the resource (GTM tags) and scope (within a workspace) and enumerates six specific actions (list, get, create, update, remove, revert). The verb 'Manage' is generic, but the explicit action list with resource paths gives clear specificity and distinguishes it from siblings like gtm_trigger and gtm_variable, which target different resources.

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 action list implies usage context (e.g., list operates on a parent workspace, get/update/remove operate on a specific tag by path). However, there is no explicit when-to-use versus alternative guidance, no exclusions, and no mention of sibling tools like gtm_trigger for related workflows. The hierarchical path pattern (accounts/containers/workspaces) gives some implied context but leaves routing decisions to inference.

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