Skip to main content
Glama
Sign In
AdLoop: Google Ads, Reddit Ads & GA4

AdLoop: Google Ads, Reddit Ads & GA4

by kLOsk
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Tag Manager tag details

get_gtm_tag
Read-only

Retrieve the full raw configuration of a single Google Tag Manager tag, including triggers, parameters, priority, and pause status, to inspect or debug a flagged tag.

Instructions

Get the full RAW configuration for a single GTM tag.

Includes every parameter, firing/blocking triggers (with their filter conditions resolved to text), priority, pause status, sampling, and monitoring metadata. Suited to inspecting a tag flagged by audit_event_coverage. An unknown tag_id returns an error with the available tag IDs. Reads the live container, or a workspace's unpublished state when workspace_id is set.

Tag Manager API: https://developers.google.com/tag-platform/tag-manager/api/v2

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": {
      "tag_id": "<tag_id>"
    },
    "name": "get_gtm_tag"
  }
}

Input Schema

NameRequiredDescriptionDefault
tag_idYesNumeric GTM tag ID, as listed by list_gtm_tags.
workspace_idNoWorkspace to read (see list_gtm_workspaces), which includes drafted changes that are not published yet. Empty reads the live (published) container version.
gtm_account_idNoNumeric GTM account ID (see list_gtm_accounts). Empty uses gtm.account_id from the config.
gtm_container_idNoNumeric GTM container ID (see list_gtm_containers). Empty uses gtm.container_id from the config.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.27.1
    • addedInput schema / properties / gtm_account_id / description
      Added value: +"Numeric GTM account ID (see list_gtm_accounts). Empty\nuses gtm.account_id from the config."
    • addedInput schema / properties / gtm_container_id / description
      Added value: +"Numeric GTM container ID (see list_gtm_containers).\nEmpty uses gtm.container_id from the config."
    • addedInput schema / properties / tag_id / description
      Added value: +"Numeric GTM tag ID, as listed by list_gtm_tags."
    • addedInput schema / properties / workspace_id
      Added value: +{
+  "default": "",
+  "description": "Workspace to read (see list_gtm_workspaces), which\nincludes drafted changes that are not published yet. Empty reads\nthe live (published) container version.",
+  "type": "string"
+}
  2. Addedv0.12.0

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already establish readOnly/openWorld/non-destructive. The description adds real context beyond them: the error behavior for an unknown tag_id (returns available tag IDs) and the live-container vs. workspace-unpublished read routing when workspace_id is set. It does not mention rate limits or auth scopes, keeping it at a solid 4 rather than 5.

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?

Purpose is front-loaded in the first sentence, with payload contents, use-case, error behavior, and workspace routing following in a tight block. Every sentence carries information; the API doc link is the only mildly extraneous element.

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?

With an output schema present, return values need no explanation, and the description still covers scope, contents, error handling, and workspace vs. live reads. Nothing an agent needs to invoke the tool correctly is missing.

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 description coverage is 100%, so the schema already documents all four parameters. The description restates the workspace_id behavior (live vs. draft state) but adds no syntax or format beyond what the schema provides, so the baseline of 3 applies.

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

Purpose5/5

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

Starts with a specific verb+resource+scope ('Get the full RAW configuration for a single GTM tag') and then enumerates the exact payload contents. An agent can distinguish it from list_gtm_tags (list vs. single-get) and get_gtm_trigger (different resource) without opening the schemas.

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?

'Suited to inspecting a tag flagged by audit_event_coverage' supplies a concrete when-to-use workflow, and the schema cross-references list_gtm_tags for discovery. It stops short of naming an explicit alternative or when-not-to-use condition, so it is clear context but not fully prescriptive routing.

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

Deploy Server

Other Tools