Skip to main content
Glama
Open Tracked MCP

Open Tracked MCP

Official

open_tracked_gtm_pack

Builds web and server Google Tag Manager containers for a shop, returns a summary, and can write both JSON files to a folder for import via Admin > Import Container.

Instructions

Build the two Google Tag Manager containers (web and server) for a shop, the same ones the Setup wizard gives. Returns a summary. With outputDir (an absolute folder) the two JSON files are written there, ready for Admin > Import Container.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "containerId": "<containerId>",
      "options": "<options>"
    },
    "name": "open_tracked_gtm_pack"
  }
}

Input Schema

NameRequiredDescriptionDefault
optionsYes
outputDirNoAbsolute path of a folder to write the two files into.
containerIdYesThe Open Tracked container id (the number in its address).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.6/5.0
Behavior3/5

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

With no annotations the description carries the full burden. It does disclose one important side effect (writing two JSON files to outputDir) and that it returns a summary, but it never says whether the containers are actually created in the GTM account or only generated locally, nor whether it is idempotent or what permissions are required.

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?

Three short sentences, front-loaded with the main action, no filler. 'Returns a summary' is thin but earns its place given there is no output schema; the only minor waste is slight redundancy with the outputDir schema description.

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

Completeness5/5

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

For a tool with nested options, no annotations and no output schema, the definition covers what matters for correct invocation: the two artifacts produced, the optional file output and its intended downstream use, and the return shape at a high level. The remaining ambiguity (remote vs local creation) is a real gap but not enough to undercut an otherwise complete callable definition.

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

Parameters3/5

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

Schema coverage is 67%, so the schema carries most of the weight. The description adds contextual value only for outputDir ('ready for Admin > Import Container'); containerId and the large nested options object (destinations, platform, tokens, enrich default) get no additional explanation beyond the schema text.

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?

States a specific verb and resource: 'Build the two Google Tag Manager containers (web and server) for a shop.' That is clearly distinct in substance from the sibling list/score tools, though it never names or contrasts them explicitly, which keeps it short of a 5.

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

Usage Guidelines3/5

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

Usage is implied rather than stated: you call it when you need a GTM pack for a shop, and the outputDir sentence hints at the import workflow. There is no explicit when-to-use/when-not guidance and no reference to how it relates to open_tracked_containers.

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