Skip to main content
Glama
dhawalshah

google-tag-manager-mcp

Gtm Zone

gtm_zone

Manage zones in a Google Tag Manager workspace with create, get, list, update, remove, and revert actions; destructive operations require confirmation.

Instructions

Manage GTM zones within a workspace. Same action set as gtm_tag (create, get, list, update, remove, revert; remove/revert require confirm=true).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathNo
actionYes
configNo
paramsNo
parentNo
confirmNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.3/5.0
Behavior3/5

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

With no annotations, the description carries the burden and does disclose one meaningful behavioral rule: remove/revert require confirm=true. It does not describe side effects, permissions, reversibility, or how the actions differ beyond that confirm requirement, leaving the behavioral profile incomplete.

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

Conciseness4/5

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

The description is compact, with two sentences and no filler. The action list and confirm requirement are front-loaded and useful, though slightly more specifics about zones would improve it.

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

Completeness2/5

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

Despite having an output schema, the description does not provide enough context for correct invocation: parameter semantics are largely missing, action-specific behavior is underspecified, and there are no annotations to fill in safety or side effects. The agent is left to infer too much about how to use this tool.

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

Parameters2/5

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, but it only explains the action set and confirm requirement. The path, config, params, and parent parameters remain generic and undocumented, which is a significant gap for a six-parameter tool.

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

Purpose4/5

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

The description identifies the resource ('GTM zones') and enumerates the supported actions (create, get, list, update, remove, revert), which makes the tool's job reasonably clear. The verb 'Manage' is generichol, and the description does not explain what a zone is beyond the resource name, so it stops short of fully specific.

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

Usage Guidelines4/5

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

The reference to gtm_tag with 'Same action set as gtm_tag' gives the agent a direct comparator among siblings, and 'within a workspace' provides the containment context. It does not explicitly state when not to use this tool or list exclusions, but the usage context is fairly clear.

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