Gtm Ga4 MCP server

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

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.

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 GOOGLEAPPLICATIONCREDENTIALS runtime path.

Precedence & mechanism

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

file that plugs into the exact same slot.

• a service-account JSON key (option 1 below), or
• the authorizeduser keyfile** the auth subcommand writes (option 2) — a

So the only real precedence rule is failure handling: an explicitly-configured keyfile is used; when GOOGLEAPPLICATIONCREDENTIALS 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 GOOGLEAPPLICATIONCREDENTIALS 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

Shortened. The full README is on GitHub.