Which integrations are available for this server?

Provides tools for managing Google Tag Manager workspaces, tags, triggers, variables, consent auditing, and container versioning.

How do I use mcp-gtm-ga4?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-gtm-ga4 audit consent compliance for all tags" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

mcp-gtm-ga4

by mharnett

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

mcp-gtm-ga4

MCP server for Google Tag Manager and GA4 -- tag management, consent auditing, workspace versioning, and analytics reporting via Claude.

Features

14 tools spanning GTM workspace management (tags, triggers, variables), consent compliance auditing, workspace preview/versioning, and GA4 reporting
Sandbox safety -- all write operations verify they target the resolved workspace, refusing to write to non-sandbox workspaces
Multi-client support -- configure per-client via environment variables
Auto-detects Default Workspace ID -- no need to manually specify workspace IDs unless using a custom sandbox

Related MCP server: Analytics MCP

Installation

npm install mcp-gtm-ga4

Or clone and build:

git clone https://github.com/mharnett/mcp-gtm-ga4.git
cd mcp-gtm-ga4
npm install
npm run build

Configuration

Security: Never share your .mcp.json file or commit it to git -- it may contain API credentials. Add .mcp.json to your .gitignore.

Runtime configuration is via environment variables.

Variable	Required	Description
`GOOGLE_APPLICATION_CREDENTIALS`	Yes	Path to a Google credential JSON key file (service account or authorized-user — see Authentication below)
`GTM_ACCOUNT_ID`	Yes	GTM account ID
`GTM_CONTAINER_ID`	Yes	GTM container ID
`GA4_PROPERTY_ID`	Yes	GA4 property ID
`GTM_SANDBOX_WORKSPACE_ID`	No	Override workspace ID (auto-detects Default Workspace if omitted)
`MCP_SERVER_NAME`	No	Server name (defaults to package name `mcp-gtm-ga4`)

See config.example.json for a reference template. The only value read from disk is oauth.scope (in an optional config.json) — the single source of truth for the OAuth scope the onboarding paths request. If no config.json is present, the committed minimum scope is used.

Authentication

This MCP supports two auth models. Both feed the same GOOGLE_APPLICATION_CREDENTIALS runtime path.

Precedence & mechanism

There is no runtime service-account-vs-OAuth toggle. Both models converge on a single slot — GOOGLE_APPLICATION_CREDENTIALS — which the runtime hands to GoogleAuth({ keyFile }). Whichever file you point that env var at is the credential:

a service-account JSON key (option 1 below), or
the authorized_user keyfile the auth subcommand writes (option 2) — a file that plugs into the exact same slot.

So the only real precedence rule is failure handling: an explicitly-configured keyfile is used; when GOOGLE_APPLICATION_CREDENTIALS is unset the server fails loudly at startup with an onboarding error naming both the service-account path and the auth OAuth helper. It deliberately does not fall back to Google's Application Default Credentials (gcloud user creds / GCE metadata server) — no silent machine-local default, no silent runtime failover.

1. Service account (primary, recommended for unattended/server use)

Create a service account in your GCP project, download its JSON key, grant it the GTM container role (on the target GTM container) and GA4 property access, and point GOOGLE_APPLICATION_CREDENTIALS at the key file. No OAuth flow, no browser, no refresh token. This is the recommended path for headless/server/unattended deployments.

2. User OAuth (interactive, for users without a service account)

If you can't use a service account, mint a user credential with your own Google OAuth client (a "Desktop app" OAuth 2.0 Client ID created in your own GCP project — enable the Tag Manager API and the Google Analytics Admin + Data APIs). Two equivalent onboarding commands, both hardened with PKCE (RFC 7636, S256) and both requesting the scope from config.json (oauth.scope) so they never drift:

export GOOGLE_CLIENT_ID=your-client-id.apps.googleusercontent.com
export GOOGLE_CLIENT_SECRET=your-client-secret

# Option A: write an authorized_user credential file directly
node dist/index.js auth --output ./gtm-ga4-credentials.json
# then set GOOGLE_APPLICATION_CREDENTIALS=./gtm-ga4-credentials.json

# Option B: the standalone helper (prints GOOGLE_REFRESH_TOKEN + a ready-to-save
# authorized_user JSON you can write to a file for GOOGLE_APPLICATION_CREDENTIALS)
node get-refresh-token.cjs

The refresh token / credential is written by you and read from your environment only. Nothing is shared and no OAuth client keyfile is bundled. Do not run the helper with stdout redirected to a shared log — the refresh token is printed to stdout by design.

OAuth scopes requested

The onboarding paths request exactly the scopes this MCP's tools use (from config.example.json → oauth.scope):

Scope	Needed by
`tagmanager.edit.containers`	`gtm_create_tag`, `gtm_update_tag`, `gtm_create_variable`, `gtm_update_variable`, `gtm_delete_variable`, tag/trigger/variable reads
`tagmanager.edit.containerversions`	`gtm_create_version`
`tagmanager.publish`	`gtm_create_version`, `gtm_preview` (quick preview)
`analytics.readonly`	`gtm_ga4_run_report`, `gtm_ga4_realtime_report`, `gtm_ga4_list_custom_dimensions`
`analytics.edit`	`gtm_ga4_create_custom_dimension`

tagmanager.readonly is intentionally not requested — the edit scopes already grant read access.

Usage

Claude Code (.mcp.json)

{
  "mcpServers": {
    "gtm-ga4": {
      "command": "node",
      "args": ["/path/to/mcp-gtm-ga4/dist/index.js"],
      "env": {
        "GOOGLE_APPLICATION_CREDENTIALS": "/path/to/service-account.json",
        "GTM_ACCOUNT_ID": "1234567890",
        "GTM_CONTAINER_ID": "9876543",
        "GA4_PROPERTY_ID": "331956119"
      }
    }
  }
}

npx

GTM_ACCOUNT_ID=1234567890 \
GTM_CONTAINER_ID=9876543 \
GA4_PROPERTY_ID=331956119 \
GOOGLE_APPLICATION_CREDENTIALS=/path/to/sa.json \
npx mcp-gtm-ga4

Claude Desktop: Add to ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows).

Safety

Workspace sandbox protection

All write operations (gtm_update_tag, gtm_create_tag, gtm_preview, gtm_create_version) verify they target the resolved workspace before executing. If a request attempts to write to a different workspace, the server returns a SafetyError and blocks the operation.

This prevents accidental production changes when the MCP server is configured against a sandbox workspace.

Tools

GTM Tags

Tool	Description
`gtm_list_tags`	List all tags in the workspace with consent status and firing triggers
`gtm_get_tag`	Get full tag configuration by tag ID
`gtm_update_tag`	Update an existing tag (merge patch via JSON)
`gtm_create_tag`	Create a new tag from a JSON definition

GTM Structure

Tool	Description
`gtm_list_triggers`	List all triggers (ID, name, type)
`gtm_list_variables`	List all variables (ID, name, type)

Tool	Description
`gtm_audit_consent`	Audit all tags for consent configuration compliance

GTM Workspace

Tool	Description
`gtm_preview`	Generate a quick preview of the current workspace
`gtm_create_version`	Create a new container version from the workspace

GA4 Reports

Tool	Description
`gtm_ga4_run_report`	Run a GA4 report with dimensions, metrics, date range, and filters
`gtm_ga4_realtime_report`	Run a GA4 realtime report (last 30 minutes)

GA4 Admin

Tool	Description
`gtm_ga4_list_custom_dimensions`	List all custom dimensions for the property
`gtm_ga4_create_custom_dimension`	Create a new custom dimension

Architecture

GTM API: googleapis (Tag Manager v2)
GA4 Data: @google-analytics/data (BetaAnalyticsDataClient)
GA4 Admin: @google-analytics/admin (AnalyticsAdminServiceClient)
Resilience: cockatiel (retry, circuit breaker, timeout policies)
Logging: pino with pino-pretty
Transport: MCP SDK stdio transport

License

MIT

Author

Built by Mark Harnett / drak-marketing

Available Tools

11 tools

gtm_audit_consentA

Scan all tags in the sandbox workspace and report consent compliance. Returns tags with no consent, NOT_NEEDED tags, properly configured tags, and recommendations.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.1/5.0

Behavior3/5

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

With no annotations provided, the description must convey behavioral traits. It states that the tool scans tags and returns categorized results, implying a read-only, non-destructive operation. However, it does not explicitly confirm idempotency or lack of side effects, which would be beneficial for confidence.

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

Conciseness5/5

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

The description is a single, well-structured sentence that efficiently conveys the tool's action, scope, and output categories without any extraneous information.

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?

Given the tool has no parameters and no output schema, the description fully covers its functionality and return structure. It explains both the action and the four categories of results, making it complete for an agent to understand and invoke.

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

Parameters4/5

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

The input schema has zero parameters with 100% coverage, so the description adds value by confirming that the tool takes no input and performs a comprehensive scan. This clarity goes beyond the schema, which only indicates an empty object.

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?

The description clearly states the verb 'Scan', the specific resource 'all tags in the sandbox workspace', and the objective 'report consent compliance'. This effectively distinguishes it from sibling tools like gtm_list_tags (which lists tags without compliance analysis) and gtm_create_tag (which creates tags).

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?

The description implies usage for consent compliance auditing but does not explicitly state when to use it versus alternatives, nor does it mention prerequisites (e.g., existence of a sandbox workspace) or when it should not be used. Given the simplicity of a parameterless tool, some guidance on context would be helpful.

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

gtm_ga4_list_custom_dimensionsA

List all registered custom dimensions for the GA4 property linked to this GTM container.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4/5.0

Behavior3/5

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

No annotations are provided, so the description carries the burden. 'List' implies a read-only operation, which is accurate. However, no additional behavioral traits (e.g., pagination, rate limits) are disclosed.

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

Conciseness5/5

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

The description is a single sentence of 14 words with no fluff. It front-loads the action and resource.

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

Completeness4/5

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

For a zero-parameter list tool with no output schema, the description is sufficient. It clearly states what the tool does and its scope. Minor improvement could mention the return format, but not required.

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

Parameters4/5

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

There are zero parameters, and the schema coverage is 100%. The description adds context by specifying 'for the GA4 property linked to this GTM container', which helps the agent understand the implicit scope.

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?

The description clearly specifies the action (list), resource (custom dimensions), and scope (GA4 property linked to this GTM container). It distinguishes from sibling tools like gtm_list_variables and gtm_list_tags by focusing on custom dimensions.

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?

The description implies usage context (when you need to see registered custom dimensions for the GA4 property), but lacks explicit when-not-to-use or alternative tools. It does not mention exclusions or prerequisites.

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

gtm_ga4_realtime_reportA

Query GA4 Realtime Report (last 30 minutes) for the property linked to this GTM container.

ParametersJSON Schema

Name	Required	Description
`metrics`	No	Comma-separated metrics
`dimensions`	No	Comma-separated dimensions
`dimension_filter`	No	Optional equality filter

TDQS

A3.7/5.0

Behavior3/5

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

The description indicates a read-only query (safe), but without annotations, it lacks details on authentication requirements, rate limits, or error handling. It does not disclose what happens when the property is not linked or when filters are invalid.

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

Conciseness5/5

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

Single sentence is concise and front-loaded, no redundant words. Every word adds value.

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

Completeness3/5

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

No output schema, so description should ideally hint at return format (e.g., rows, columns). It does not, leaving the agent uncertain about the response structure. For a realtime report tool, this is a gap.

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 100% with descriptions for all parameters. The description adds no additional meaning beyond the schema, e.g., no examples of valid metric/dimension formats or filter syntax.

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?

The description clearly states the tool queries a GA4 Realtime Report for the last 30 minutes, specifically for the property linked to the GTM container. It effectively distinguishes from sibling gtm_ga4_run_report by emphasizing the realtime aspect.

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?

No explicit guidance on when to use versus alternatives like gtm_ga4_run_report. The realtime constraint is implied by the name and description, but no exclusions or prerequisites are stated.

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

gtm_ga4_run_reportB

Query GA4 historical report for the property linked to this GTM container.

ParametersJSON Schema

Name	Required	Description
`limit`	No	Max rows (default 100)
`metrics`	No	Comma-separated metrics (e.g., "eventCount,activeUsers")
`end_date`	No	End date (YYYY-MM-DD or "today")
`dimensions`	No	Comma-separated dimensions (e.g., "eventName,date")
`start_date`	No	Start date (YYYY-MM-DD or "7daysAgo")
`dimension_filter`	No	Optional equality filter (e.g., "eventName==page_view")

TDQS

B3.2/5.0

Behavior2/5

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

No annotations are provided, so the description must fully disclose behavioral traits. It does not mention read-only nature, permissions, rate limits, or side effects. For a query tool, it is minimally transparent.

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

Conciseness5/5

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

Single sentence, 12 words, front-loaded. No wasted words. Efficiently communicates the core purpose.

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?

The description is minimal for a tool with 6 parameters and no output schema. It does not describe the return format, error handling, or what 'linked to this GTM container' implies. More context would be beneficial for agent invocation.

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 100%, baseline is 3. The description adds no parameter-level information beyond what the schema already provides. It does not clarify usage of parameters like start_date or dimension_filter.

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?

The description clearly states the tool queries a GA4 historical report for a specific GTM container. The verb 'Query' and the resource 'GA4 historical report' are specific, and it distinguishes from sibling like gtm_ga4_realtime_report.

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

Usage Guidelines2/5

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 does not mention exclusions or context. The tool name implies historical vs realtime, but the description lacks explicit usage context.

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

gtm_get_client_contextA

Health check and status overview. Returns GTM container path, workspace ID, GA4 property ID, and server version. Use this to verify connectivity.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.8/5.0

Behavior4/5

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

Describes that it returns specific fields and is a status check. No annotations provided, so the description carries full burden. It clearly indicates it's a non-destructive read operation, though it could explicitly state 'read-only' or 'no side effects'.

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

Conciseness5/5

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

Two sentences with zero waste. First sentence defines purpose and output, second sentence states when to use. Front-loaded with key information.

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?

Tool has no parameters and no output schema. The description completely covers the tool's behavior, output fields, and usage scenario. No additional information is necessary.

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

Parameters5/5

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

No parameters expected, schema coverage 100%. Description goes beyond by enumerating the returned data fields, which is useful context for understanding the tool's output beyond the empty schema.

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?

Explicitly states it's a 'Health check and status overview' and lists specific resources returned (GTM container path, workspace ID, GA4 property ID, server version). This clearly distinguishes it from sibling tools that create, update, or delete resources.

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

Usage Guidelines5/5

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

Explicitly says 'Use this to verify connectivity', which tells the agent exactly when to invoke this tool. No other sibling tool serves this connectivity check purpose.

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

gtm_get_tagA

Get full details of a single tag by ID from the sandbox workspace.

ParametersJSON Schema

Name	Required	Description	Default
`tag_id`	Yes	The tag ID

TDQS

A4/5.0

Behavior3/5

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

No annotations are provided, so the description carries the burden. It indicates a read operation ('Get') but does not disclose additional traits like rate limits, authentication, or what 'full details' entails. However, for a simple get, the minimal info is acceptable.

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

Conciseness5/5

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

The description is a single, clear sentence of 14 words with no redundancy. It is front-loaded with the primary action and resource.

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

Completeness4/5

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

For a simple tool with one parameter and no output schema, the description adequately specifies the scope (sandbox workspace) and action. It could mention that the tag must exist or describe the return format, but it is mostly complete.

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?

The input schema has 100% coverage with one parameter (tag_id) described as 'The tag ID'. The description repeats 'by ID' but adds no new meaning beyond the schema, earning the baseline score.

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?

The description clearly states the verb 'Get', the resource 'full details of a single tag', and the scope 'by ID from the sandbox workspace'. It effectively distinguishes from sibling tools like gtm_list_tags and gtm_update_tag.

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 description implies usage when a specific tag ID is known and full details are needed. While it doesn't explicitly exclude alternatives, the context of sibling tools (e.g., gtm_list_tags) makes usage clear.

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

gtm_get_variableA

Get full details of a single variable by ID from the sandbox workspace.

ParametersJSON Schema

Name	Required	Description	Default
`variable_id`	Yes	The variable ID

TDQS

A3.6/5.0

Behavior3/5

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

Without annotations, the description carries the full burden. It correctly implies read-only access ("Get full details") but omits any discussion of error states (e.g., if variable_id doesn't exist), authentication needs, rate limits, or side effects. For a simple get, this is minimally adequate.

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

Conciseness5/5

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

A single, direct sentence with no superfluous words. Front-loaded with the key action and resource.

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

Completeness4/5

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

For a straightforward 1-parameter, no-output-schema tool, the description is sufficient. It specifies the workspace context. Could optionally mention the return format but is not required.

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 100% and the description adds no additional meaning beyond the schema's 'The variable ID'. Baseline 3 is appropriate.

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?

The description clearly states the action (Get), resource (variable), and scope (single by ID, from sandbox workspace), effectively distinguishing it from sibling tools like list, create, delete, or update.

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

Usage Guidelines2/5

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

The description limits scope to the sandbox workspace but provides no guidance on when to use this tool versus alternatives like gtm_list_variables (to find IDs) or why to fetch a single variable. No when-not-to-use or exclusion criteria.

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

gtm_list_tagsA

List all tags in the sandbox GTM workspace with name, type, consent status, and firing triggers.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.7/5.0

Behavior2/5

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

No annotations are provided, so the description must disclose behavioral traits. It mentions the fields returned but lacks details on pagination, rate limits, or the read-only nature of the operation.

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

Conciseness5/5

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

The description is a single, efficient sentence that conveys the essential information without any wasted words.

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

Completeness3/5

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

For a simple list tool with no output schema, the description covers the basics but could be more complete by mentioning pagination or the structure of fields like firing triggers.

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

Parameters4/5

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

There are no parameters in the input schema, and schema coverage is 100%. Per guidelines, baseline for 0 parameters is 4, and the description adds value by listing return fields.

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?

The description clearly states the action (list), resource (tags), and scope (sandbox GTM workspace), and distinguishes from sibling tools like gtm_list_triggers and gtm_list_variables.

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?

The description implies usage for listing all tags but does not provide explicit guidance on when to use this tool versus alternatives like gtm_get_tag for a single tag.

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

gtm_list_triggersA

List all triggers in the sandbox GTM workspace.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.7/5.0

Behavior2/5

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

No annotations are provided, so the description must disclose behavioral traits. It only states the action without mentioning side effects, permissions, rate limits, or return format. For a read operation, this is acceptable but minimal; a higher score would require more context.

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

Conciseness5/5

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

The description is a single concise sentence that front-loads the key information. Every word is meaningful, and there is no extraneous content.

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

Completeness3/5

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

Given the tool's zero-parameter simplicity and lack of output schema, the description is minimally adequate. However, it could be enriched by noting what fields are returned or any limitations (e.g., pagination). With more context from annotations or output schema, this score could be higher.

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

Parameters4/5

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

The tool has zero parameters, and schema coverage is effectively 100%. According to the rubric, 0 parameters earns a baseline of 4. The description adds no parameter information, but none is needed.

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?

The description clearly states the verb 'List', the resource 'triggers', and the specific scope 'in the sandbox GTM workspace'. This effectively differentiates it from sibling list tools like gtm_list_tags and gtm_list_variables.

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?

The description implies usage for listing triggers but provides no explicit guidance on when to use this tool versus alternatives. It does not mention exclusions or prerequisites, leaving the agent to infer context from the tool name alone.

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

gtm_list_variablesA

List all variables in the sandbox GTM workspace.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4/5.0

Behavior3/5

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

No annotations provided, so description must carry burden. Describes the scope ('all variables in sandbox GTM workspace') but omits potential behavioral traits such as authorization needs, rate limits, or return format. The simplicity of the operation partially mitigates this.

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

Conciseness5/5

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

Single front-loaded sentence with no wasted words. Efficiently conveys the tool's purpose.

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

Completeness4/5

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

Given no parameters and no output schema, the description is sufficient for a simple list tool. It specifies the scope ('sandbox GTM workspace'), but could mention if there are any implicit constraints (e.g., pagination).

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

Parameters4/5

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

No parameters exist; schema coverage is 100%. The description correctly adds no param info. Baseline for zero parameters is 4.

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?

Clearly states the verb 'List' and the resource 'variables in the sandbox GTM workspace'. This distinguishes from siblings like gtm_get_variable (single variable) or gtm_list_tags (different resource).

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?

Implies usage as a list operation but provides no explicit guidance on when to use versus alternatives like gtm_get_variable for a specific variable. No when-not-to-use or context clues.

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

gtm_previewA

Generate a GTM Preview URL for the sandbox workspace.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.8/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. It does not disclose whether the operation is read-only, has side effects, requires authentication, or any other behavioral traits. For a tool generating a URL, basic safety info is missing.

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

Conciseness5/5

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

The description is a single concise sentence that is front-loaded. Every word earns its place with no redundancy.

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

Completeness4/5

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

Given zero parameters and no output schema, the description covers the essential purpose and scope. It could mention that the tool returns a URL or is limited to sandbox, but is largely complete for its simplicity.

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

Parameters4/5

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

There are 0 parameters, so schema coverage is 100%. The description adds no parameter info but does not need to. Per guidelines, baseline 4 is appropriate.

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?

The description clearly states the action ('Generate'), the resource ('GTM Preview URL'), and the scope ('sandbox workspace'). It differentiates from siblings which are about audit, creation, deletion, etc.

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?

The description implies usage for previewing, but does not explicitly state when to use this tool vs alternatives (e.g., gtm_list_tags, gtm_get_tag). No exclusion criteria or prerequisites mentioned.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

7 tool updatesv1.3.0Sep 8, 2026
- Removedgtm_create_tag
- Removedgtm_create_variable
- Removedgtm_create_version
- Removedgtm_delete_variable
- Removedgtm_ga4_create_custom_dimension
- Removedgtm_update_tag
- Removedgtm_update_variable
18 tool updatesv1.1.0Jul 8, 2026
- First observedgtm_audit_consent
- First observedgtm_create_tag
- First observedgtm_create_variable
- First observedgtm_create_version
- First observedgtm_delete_variable
- First observedgtm_ga4_create_custom_dimension
- First observedgtm_ga4_list_custom_dimensions
- First observedgtm_ga4_realtime_report
- First observedgtm_ga4_run_report
- First observedgtm_get_client_context
- First observedgtm_get_tag
- First observedgtm_get_variable
- First observedgtm_list_tags
- First observedgtm_list_triggers
- First observedgtm_list_variables
- First observedgtm_preview
- First observedgtm_update_tag
- First observedgtm_update_variable

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.9/5.0

Scored 2026-09-09 18:21 across 11 tools

Disambiguation5/5

Each tool targets a distinct GTM or GA4 resource/action: list/get operations are clearly separated by resource type, audit/consent and preview have unique purposes, and the two GA4 report tools are differentiated by live vs. historical data. No two tools appear to do the same thing.

Naming Consistency4/5

Most tools consistently follow the gtm_<verb>_<object> pattern, with list and get verbs used predictably across resources. Minor deviations like gtm_get_client_context and gtm_preview, plus gtm_ga4_run_report vs. gtm_ga4_realtime_report, introduce slight inconsistency but the overall convention remains readable.

Tool Count5/5

11 tools is a well-scoped size for a GTM/GA4 server covering listing, retrieval, auditing, preview, and reporting. Each tool has a clear purpose and the count does not feel bloated or insufficient.

Completeness4/5

The set covers the main read-only workflows for GTM inspection, consent auditing, preview URL generation, and GA4 reporting. Missing pieces like a get_trigger operation and write/management operations are minor relative to the apparent read-only/audit-focused intent.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

climbpast
io.github.archievi
Read and edit GA4, Search Console and Google Tag Manager from any MCP client. 29 tools.
Marketing Search Data Platforms
1
Google Ads + Meta Ads + GA4 MCPOAuth
io.github.irinabuht12-oss
Google Ads, Meta Ads & GA4 MCP server - 250+ tools for campaigns, creatives, audiences & reports.
Marketing Social Media
11,644
LemonadoOAuth
io.github.lemonadolabs
MCP server for querying and analyzing data from ad platforms, analytics tools, and spreadsheets
Marketing Research & Data Databases
3
GTM MCP ServerOAuth
io.github.paolobietolini
Let AI manage your Google Tag Manager containers — tags, triggers, variables, and more.
Marketing App Automation Developer Tools
2

Related MCP Servers

Tag Manager API MCP Server
RAG Systems Content Management Systems
ag2-mcp-servers
F
license
Not graded
quality
D
maintenance
An MCP Server that provides a conversational interface to Google Tag Manager API, allowing users to manage tags, triggers, variables, and containers through natural language.
Updated a year ago (2025-07-16 14:05 UTC)
-
Analytics MCP
Marketing Monitoring Developer Tools
abhishekshankar
A
license
Not graded
quality
B
maintenance
Automates Google Analytics 4 and Google Tag Manager setup, management, and health monitoring with blueprints, multi-environment support, and MCP tools for AI agents.
Updated 2 months ago (2026-06-29 23:19 UTC)
MIT
tagmanager-mcp
Marketing Developer Tools
jinchliu
A
license
A
quality
B
maintenance
An MCP server for the Google Tag Manager API v2 that enables AI assistants to query GTM accounts, containers, tags, triggers, variables, and unpublished changes.
Updated a month ago (2026-08-10 15:55 UTC)
24
2
Apache 2.0
@ainative/gtm-mcp
Marketing Autonomous Agents
AINative-Studio
A
license
Not graded
quality
C
maintenance
MCP server for Google Tag Manager and Google Ads, enabling AI agents to audit, fix, and manage GTM containers and Google Ads campaigns programmatically.
Updated a month ago (2026-08-01 02:18 UTC)
126 npm
MIT

mcp-gtm-ga4

Features

Installation

Configuration

Authentication

Precedence & mechanism

1. Service account (primary, recommended for unattended/server use)

2. User OAuth (interactive, for users without a service account)

OAuth scopes requested

Usage

Claude Code (.mcp.json)

npx

Safety

Workspace sandbox protection

Tools

GTM Tags

GTM Structure

GTM Consent

GTM Workspace

GA4 Reports

GA4 Admin

Architecture

License

Author

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers