Google Tag Manager MCP Server: Complete Guide (2026)

TL;DR + what you actually need

If you just want the connection details before reading the why:

• Canonical repo: github.com/stape-io/google-tag-manager-mcp-server (Apache-2.0, TypeScript, maintained by Stape).
• Remote endpoint: https://gtm-mcp.stape.ai/mcp — a hosted Streamable HTTP server with Google OAuth built in.
• How you connect: point your client at that endpoint through the mcp-remote bridge. First connect opens a browser for Google sign-in.
• Cost: Stape lists it as free. You bring a Google account that already has access to the GTM containers you want to manage.

One naming thing up front, because it trips people up: there are two “GTM MCP” projects floating around. The one with a hosted endpoint, active commits, and OAuth is Stape’s. We cover which repo to trust below.

What the GTM MCP server actually does

Google Tag Manager is configuration-heavy and click-heavy. A typical conversion-tracking change means opening a workspace, adding a tag, attaching a trigger, defining a data-layer variable, checking it in preview mode, then publishing a version. Every step is a form. Doing it through the GTM REST API instead means writing authenticated requests against a fiddly resource model (accounts contain containers contain workspaces contain tags, triggers, and variables).

The GTM MCP server collapses that. It wraps the Tag Manager API as a set of MCP tools, so an agent that speaks MCP can read and write those resources directly. You describe the change in plain language — “add a GA4 event tag that fires on the purchase-complete trigger” — and the agent makes the API calls. Stape’s product page frames it the same way: command execution and data access “without the need to write API requests manually.”

The honest version of the value: this is a power tool for people who already understand GTM. It doesn’t make tracking decisions for you, and it can publish to a live container, so it rewards reviewing what the agent proposes before approving it. Used that way, it turns a 20-minute clickfest into a sentence — and that’s the whole point.

If you’re still fuzzy on what “MCP” even means, our what-is-MCP explainer is the 10-minute version. Everything below assumes you’ve got a client like Claude Desktop, Cursor, or Codex already installed.

Which repo is canonical (read this first)

Search “gtm mcp server” and you’ll hit more than one project. That matters because they don’t install the same way and they aren’t maintained the same way.

• Stape’s stape-io/google-tag-manager-mcp-server is the one to use. It’s Apache-2.0, written in TypeScript, runs as a hosted remote server with Google OAuth built in, and has recent commits and active pull requests. Stape is a server-side tagging vendor, so GTM is squarely in their lane.
• The older paolobtl/gtm-mcp community package also appears in directory listings (including the install snippet you may see auto-generated on our own catalog card above, which still references an npx-style local config with client-ID/secret env vars). Treat that path as secondary. The Stape server is the one with the hosted endpoint and the interactive OAuth flow this guide documents.

Translation: trust the prose in this post and the Stape README over any auto-generated snippet. We flag this explicitly because the two configs look different and you don’t want to debug the wrong one.

The catalog card and the install panel below both link to the canonical Google Tag Manager server page; use the Stape connection details from this guide when the panel’s generated config doesn’t match.

Install and the OAuth flow

The hosted path is the simplest, and it’s what Stape’s README documents. You don’t install the server itself — you point your MCP client at Stape’s endpoint through the mcp-remote bridge, which proxies a local stdio connection to the remote Streamable HTTP server and handles the OAuth handshake.

For Claude Desktop, open Settings → Developer → Edit Config and add:

{
  "mcpServers": {
    "gtm-mcp-server": {
      "command": "npx",
      "args": [
        "-y",
        "mcp-remote",
        "https://gtm-mcp.stape.ai/mcp"
      ]
    }
  }
}

Restart Claude Desktop. A browser window opens showing Google’s OAuth consent screen. Sign in with a Google account that has access to your GTM containers and grant the requested scopes. Once you approve, the GTM tools become available in the client. There’s no key file to mount and no service-account JSON to manage on the hosted path — mcp-remote caches the credentials locally under ~/.mcp-auth.

The same mcpServers shape works for any client that reads that config format — Cursor (~/.cursor/mcp.json), VS Code, Windsurf, and Codex all accept the equivalent block. For Cursor and Codex specifically, keep the server name short (see common mistakes). Browse the exact config path per client on the Claude Desktop client page or the Cursor client page.

Our catalog also renders a one-line install panel for this server. Note the caveat from the section above: the auto-generated config can reflect the older community package rather than Stape’s hosted endpoint, so cross-check it against the mcp-remote snippet here.

One-line install · Google Tag Manager

Open server page

Install

Cursor

One-click install

VS Code

One-click install

Claude Desktop

Copy configuration

Claude Code

Copy CLI command

CLI

Gemini

Copy CLI command

CLI

Codex

Copy CLI command

CLI

Windsurf

Copy configuration

ChatGPT

Add via Settings → Connectors

M

Manual

Copy configuration

If your network blocks the remote endpoint or you need to run everything yourself, you can clone the Stape repo and run it locally — it’s a standard TypeScript MCP server, and it also ships a Cloudflare Worker configuration for self-hosting. The hosted endpoint is the path most people want; reach for self-hosting only when policy requires it.

The tool surface: what the agent can touch

This is where the GTM MCP server earns its place over a read-only docs lookup: it’s a full read/write interface to the Tag Manager API. Grouped by GTM resource, the tools cover:

The repo organizes these as separate action modules — account, container, workspace, tag, trigger, variable, built-in variable, client, template, folder, environment, version, user-permission, and a few server-side-specific ones like destinations, transformations, and zones. The practical takeaway: almost anything you can do in the GTM web UI, the agent can do through these tools, including the parts that change live behavior.

There’s also a session-cleanup tool (Stape’s code exposes a gtm_remove_session action) that wipes the stored MCP session data — useful when you’re done or switching Google accounts.

End-to-end recipe: ship a GA4 event tag

Here’s the workflow that justifies the setup. Goal: add a GA4 event tag that fires on a custom “purchase_complete” event, then publish it. Assume you’re connected and authenticated.

Step 1 — orient. Ask the agent to list your accounts and containers so it grabs the right IDs, then create or select a working workspace:

List my GTM accounts and containers, then
create a new workspace called "ga4-purchase-tag"
in the "www.example.com" web container.

The agent calls the account/container list tools, finds the right IDs, and creates the workspace. You don’t type a single ID.

Step 2 — build the trigger and tag. Now describe the tracking change:

In that workspace, create a Custom Event trigger
on the event name "purchase_complete". Then create
a GA4 Event tag named "GA4 - purchase" using
measurement ID G-XXXXXXX, event name "purchase",
firing on that trigger.

Under the hood the agent creates the trigger via the trigger tool, then creates the tag via the tag tool with the trigger attached. If the GA4 config relies on a variable you haven’t defined, ask it to create the variable first — the variable tools handle that.

Step 3 — review, then publish. This is the step to slow down on:

Show me a summary of every tag, trigger, and
variable changed in this workspace. Do NOT publish yet.

Read the diff. When it’s right, approve the publish explicitly: “Create a container version from this workspace named ‘Add GA4 purchase tag’ and publish it.” The agent calls the version tools to snapshot and publish. Your live container now fires the new tag — and you reviewed it before it went out, which is the difference between a power tool and a footgun.

Consent mode and the caveats that bite

Two areas deserve an honest warning, because the demo videos rarely show them.

Consent mode is not magic. Google Consent Mode v2 governs whether tags fire based on a visitor’s consent state, and the MCP server can configure the consent settings on a tag the same way the UI can — by setting the consent-type fields the GTM API exposes. But the agent only knows what you tell it. It won’t infer your legal requirements, and it can’t test the live consent banner behavior. Treat agent-written consent settings as a draft to verify in preview mode and against your actual CMP, not a compliance guarantee. Getting consent wrong has legal weight; this is the section to be conservative in.

OAuth scope and account hygiene. The agent acts as you — it inherits whatever GTM access your Google account has. If that account is an admin on production containers, so is the agent. For anything beyond a personal sandbox, connect with a Google account scoped to exactly the containers you want it to manage, and lean on GTM’s own user-permission model. When you’re done, run the session-removal tool or rm -rf ~/.mcp-auth to clear cached tokens.

Publishing is live. Said once more because it’s the highest-stakes capability: the version tools change what real visitors’ browsers do. Keep a review-then-approve gate on every publish.

What we got wrong the first time

Two assumptions cost us time, and they’re both easy to avoid.

We installed the wrong “gtm-mcp.” The first config we grabbed was a local npx package expecting a client ID, client secret, and project ID as environment variables. We spent a while wrangling Google Cloud OAuth credentials before realizing the maintained Stape server skips all of that with a hosted endpoint and an interactive login. If you’re configuring client-ID/secret env vars by hand, stop and check whether you’re on the hosted Stape path instead.

We let it publish before reviewing. Early on we asked the agent to “set up and publish” a tag in one instruction. It did — including a trigger condition we’d described loosely, which fired broader than intended. Nothing catastrophic, but it taught us to always split the build step from the publish step and read the workspace diff in between. The recipe above bakes that gate in.

Common mistakes (and the root cause)

Who this is for (and who it isn’t)

Reach for it if you:

• Already know GTM and do repetitive tag/trigger/variable work you’d love to describe instead of click.
• Run many similar containers (agency, multi-brand) and want to template setups conversationally.
• Live in an AI client already — Claude, Cursor, Codex — and want GTM in the same workflow as the rest of your work.

Skip it (for now) if you:

• Are new to GTM. The agent assumes you know what a correct setup looks like; it won’t catch a conceptually wrong tracking plan.
• Need a hard guarantee that nothing touches production without sign-off, and can’t enforce a review-then-approve discipline.
• Only need to read analytics data — that’s a GA4/reporting MCP job, not a Tag Manager one.

Community signal

Independent chatter specific to the GTM MCP server is still thin — “GTM” in developer threads usually means go-to-market, which muddies search. The clearest signal is upstream: the Stape repo carries active pull requests and a steady commit cadence (including the Oct 2025 migration to Streamable HTTP and later logging work), which is what you want to see in a server you’ll point at a live container.

On the marketing-ops side, the recurring sentiment in GTM circles is cautious optimism: the time savings on repetitive container work are real, but practitioners draw a firm line at unattended publishing to production — which matches our recipe’s review gate. We’ll refresh this section as more first-hand write-ups appear.

The verdict

For the broader marketing-ops MCP stack, the same pattern shows up across platforms — see our Meta Ads MCP guide for the ads-automation equivalent, and the best SEO MCP servers roundup for the search side. The Google Ads and Meta Ads server pages cover the paid-media half of the same toolkit.

Frequently asked questions

Sources & links

Primary

• GTM MCP server repo & README: github.com/stape-io/google-tag-manager-mcp-server (Apache-2.0, maintained by Stape)
• Remote endpoint: https://gtm-mcp.stape.ai/mcp
• Stape product page: stape.io/solutions/mcp-server-for-gtm

Docs & tooling

• Google Tag Manager API (the surface the server wraps) — developers.google.com/tag-platform/tag-manager/api/v2
• mcp-remote bridge — github.com/geelen/mcp-remote

Internal

• Google Tag Manager server page
• What is MCP?
• Meta Ads MCP complete guide
• Remote MCP servers