LW IT Solutions logo LW IT Solutions logo LW IT Solutions
« Blog-Übersicht /Cloud & AI / GTM-Integrationen für Claude Code: Drei MCP-Server, ihre...
Diesen Artikel in anderen Sprachen lesen:

GTM-Integrationen für Claude Code: Drei MCP-Server, ihre Werkzeugzahl und ihr Kontextpreis

GTM-Integrationen für Claude Code: Drei MCP-Server, ihre Werkzeugzahl und ihr Kontextpreis

Management Summary

KI-Assistenten können die Website-Messung im Google Tag Manager vorbereiten, etwa das Erfassen abgeschlossener Käufe. MCP-Anbindungen stellen dafür die Verbindung zwischen Claude Code und diesen Einstellungen her. Die drei verglichenen Pakete organisieren ihre Werkzeuge unterschiedlich; deren Zahl allein erklärt weder Nutzen noch laufende Kosten. Wichtiger sind passende Zugriffsrechte, die Trennung von Entwurf und Veröffentlichung sowie verlässliche Änderungen. Tatsächliche Nutzung sagt über Kosten mehr aus als die Länge einer Werkzeugliste.

Inhalt
  1. Werkzeuge, direkte API-Aufrufe und Skills
  2. Was die historischen Größen aussagen
  3. Entwurf und Veröffentlichung auseinanderhalten
  4. Workspace-Tags und veröffentlichte Version lesen
  5. Drei Prüfungen für Zugriffsrechte
  6. GTM_SCOPES wirkt nicht bei jeder Anmeldung
  7. Änderungen ohne versehentlichen Datenverlust
  8. Im Browser prüfen und die Änderung erklären
  9. Fragen und Antworten
  10. Quellen

Ein KI-Assistent kann im Google Tag Manager beispielsweise einen Tag für abgeschlossene Käufe vorbereiten. Dafür braucht die Anbindung Zugriff auf den richtigen Container. Ein Container bündelt Tags, Auslöser und Variablen; ein JSON-Export beschreibt diese Einstellungen als Text. Die Entscheidung über Zugriffsrechte ist wichtiger als die Zahl der angebotenen Werkzeuge.

Dieser Vergleich betrachtet drei MCP-Pakete. MCP ist ein Protokoll, über das ein Assistent Werkzeuge aufrufen kann. Die ursprüngliche Messung vom 9. September 2026 nennt Werkzeugzahlen und Antwortgrößen für feste Paketversionen. Die damaligen Rohprotokolle liegen für diese Nachprüfung nicht vor. Die Werte bleiben als historische Angaben gekennzeichnet; aktuelle API-Regeln und Paketquellen wurden separat geprüft.

Google-Scopes, Kontorechte und Claude-Code-Regeln prüfen verschiedene Teile des Zugriffs. Die Werkzeuglistengröße misst nicht direkt die Kontextnutzung.
Google-Scopes, Kontorechte und Claude-Code-Regeln prüfen verschiedene Teile des Zugriffs. Die Werkzeuglistengröße misst nicht direkt die Kontextnutzung.

Werkzeuge, direkte API-Aufrufe und Skills

Ein MCP-Server bietet beispielsweise ein Werkzeug zum Lesen eines Tags an. Claude Code übermittelt die Argumente, der Server ruft die Tag-Manager-API auf und liefert das Ergebnis zurück. Ein lokaler Server kann über die Ein- und Ausgabe seines Prozesses kommunizieren (stdio); ein entfernter Server kann HTTP verwenden.

Der direkte Weg über curl kommt ohne MCP aus. Dafür müssen API-Adresse, Zugriffstoken und Datenformat stimmen. Auch dieser Weg verbraucht Kontext für Anweisungen und Ergebnisse. Der Zugriffstoken ist ein zeitlich begrenzter Zugangsnachweis; enthaltene OAuth-Scopes legen die beantragten Arten von Zugriff fest.

Ein Skill kann Vorgehen, Prüfschritte und Hilfsskripte mitbringen. In Claude Code können Skill-Einstellungen auch Werkzeugaufrufe vorab erlauben. Ein Skill erzeugt jedoch keine fehlenden Google-Berechtigungen. Entscheidend bleiben die tatsächlich verfügbaren Werkzeuge, Zugangsdaten und Rechte.

Was die historischen Größen aussagen

Historische Angaben vom 9. September 2026; Rohprotokolle für diese Nachprüfung nicht verfügbar.
Paketversion Angegebene Werkzeuge Angegebene tools/list-Bytes
google-tag-manager-mcp-server 5.1.1 18 108201
gtm-mcp 1.0.0 104 49656
@theethosteam/gtm-mcp 1.1.1 33 19797

Die Bytewerte bezeichnen die damals angegebene Antwort auf tools/list, also die Beschreibung aller angebotenen Werkzeuge. Eine Werkzeugdefinition enthält unter anderem Name, Beschreibung und Eingabefelder. Wenige Werkzeuge können deshalb mehr Text benötigen als viele kleine Werkzeuge.

Der damalige Vergleich beschreibt den ersten Server als Sammlung von Werkzeugen je Objektart: gtm_tag bündelt etwa Lesen und Ändern über einen Parameter action. Der zweite Server trennt wesentlich mehr API-Aufrufe in einzelne Werkzeuge. Beim dritten Paket bestätigt der geprüfte Quelltext Aufgabenrezepte sowie gtm_raw für direkte API-Methoden.

Die früher genannten rund 27.000, 12.400 und 4.900 Token sind lediglich grobe Schätzungen nach Bytegröße, keine Messung mit dem Tokenizer eines bestimmten Modells. Token sind die Textbausteine, mit denen ein Modell arbeitet. JSON-Formatierung, Zeichensatz und Tokenizer beeinflussen das Ergebnis.

Claude Code kann MCP-Werkzeuge inzwischen über eine Werkzeugsuche erst bei Bedarf laden. Dann landet nicht automatisch jede vollständige Definition in jeder Modellanfrage. Einstellungen, Clientversion und Plattform entscheiden über das tatsächliche Verhalten. Deshalb ergibt sich aus 108.201 Byte Werkzeugliste weder ein fester Platzverbrauch noch ein fester Preis je Gesprächsrunde.

Prompt-Caching kann bereits geladene, wiederholte Eingaben günstiger machen. Ein Cachetreffer verkleinert aber nicht die Zahl der dabei verarbeiteten Kontexttoken. Treffer, Schreibkosten und Ersparnis hängen vom Modell, der Anfrage und der Cache-Konfiguration ab. Für einen Kostenvergleich sind die tatsächlichen Nutzungswerte wichtiger als eine Byte-Schätzung.

Entwurf und Veröffentlichung auseinanderhalten

Die öffentlich abgerufene API-Beschreibung vom 25. Oktober 2026 trägt die Revision 20261021. Das Dokument umfasst 270.858 Byte und 106 Methoden: 38 GET, 38 POST, 15 PUT und 15 DELETE. Diese Zählung beschreibt die API, nicht die Anzahl der Werkzeuge eines MCP-Servers.

Ein Workspace ist ein Entwurf innerhalb eines Containers. Eine dort geänderte Tag-Konfiguration ersetzt die veröffentlichte Standardversion nicht automatisch. Üblicherweise entsteht zunächst mit workspaces.create_version eine Version; versions.publish veröffentlicht eine Version. Vorschau und benutzerdefinierte Umgebungen sind gesondert zu betrachten.

Dieser Ablauf macht andere API-Rechte nicht harmlos. Container löschen, Benutzerrechte ändern und Umgebungen bearbeiten sind keine bloßen Tag-Entwürfe. Im geprüften Discovery-Dokument verwenden genau zwei Methoden den Scope tagmanager.publish. Daraus folgt nicht, dass alle übrigen Methoden ohne Folgen für einen laufenden Betrieb bleiben.

Workspace-Tags und veröffentlichte Version lesen

Für die Tag-Liste eines Workspace wird dessen ID benötigt. Die veröffentlichte Version lässt sich dagegen über versions:live lesen; die Antwort enthält auch die Tags dieser Version. Folgendes Beispiel liest nur Daten. IDs und Token sind Platzhalter für einen berechtigten Zugriff.

# Beispiel-IDs; TOKEN muss einen berechtigten Zugriffstoken enthalten.
ACC=6012345678
CONT=123456789
WS=42
: "${TOKEN:?Zugriffstoken erforderlich}"

# Tag-Entwürfe eines Workspace
curl --silent --show-error --fail-with-body \
  --connect-timeout 10 --max-time 30 \
  -H "Authorization: Bearer $TOKEN" \
  "https://tagmanager.googleapis.com/tagmanager/v2/accounts/$ACC/containers/$CONT/workspaces/$WS/tags"

# Veröffentlichte Version samt Tags; ohne Workspace-ID
curl --silent --show-error --fail-with-body \
  --connect-timeout 10 --max-time 30 \
  -H "Authorization: Bearer $TOKEN" \
  "https://tagmanager.googleapis.com/tagmanager/v2/accounts/$ACC/containers/$CONT/versions:live"

Ein fehlender oder abgelaufener Token und unzureichende Rechte können zu unterschiedlichen Fehlern führen. Ein bestimmter Fehlertext ist keine Zusicherung für jede API-Methode. --fail-with-body lässt HTTP-Fehler am Exit-Code erkennen und behält den Antworttext; die Option setzt eine passende curl-Version voraus.

Drei Prüfungen für Zugriffsrechte

Erstens muss der Zugriffstoken den benötigten OAuth-Scope enthalten. Zweitens braucht das zugehörige Google-Konto passende Tag-Manager-Rechte. Ein Veröffentlichungs-Scope allein gibt einem Konto ohne Veröffentlichungsrecht keinen Zugriff auf die Veröffentlichung. Diese beiden Prüfungen gelten auch außerhalb von Claude Code.

Drittens kann Claude Code bestimmte Werkzeugaufrufe sperren oder zur Bestätigung vorlegen. Eine Regel für mcp__gtm__gtm_version betrifft dieses Werkzeug. Ein PreToolUse-Hook kann zusätzlich Eingabefelder wie action prüfen. Ein Hook ist ein Skript, das vor dem Aufruf eine Entscheidung liefert.

Eine Sperre auf einen Werkzeugnamen kontrolliert keinen separaten curl-Aufruf. Sind dieselben Zugangsdaten über die Shell erreichbar, gelten dort weiterhin Google-Scopes und Kontorechte, aber nicht diese MCP-Namensregel. Auch ein offenes Rohaufruf-Werkzeug kann gesperrte Spezialwerkzeuge ersetzen. Alle tatsächlich erreichbaren Wege müssen zusammen betrachtet werden.

GTM_SCOPES wirkt nicht bei jeder Anmeldung

Die geprüfte CLI-Version google-tag-manager-mcp-server@5.1.1 verwendet das Core-Paket über einen Versionsbereich ab 2.1.1. Im ausdrücklich geprüften Core 2.1.1 wird GTM_SCOPES nur bei der Dienstkonto-Anmeldung an die Token-Erzeugung weitergegeben. Ohne eigene Auswahl werden sieben Tag-Manager-Scopes angefordert.

Beim Refresh-Token- oder Zugriffstoken-Zweig ändert dieselbe Umgebungsvariable die vorhandenen Rechte nicht. Für eine Beschränkung muss ein entsprechend eingeschränkter Google-Zugang vorliegen. Der folgende Konfigurationsausschnitt zeigt nur die Dienstkonto-Variante. Der Schlüsselwert ist ein Platzhalter; echte Schlüssel gehören nicht in ein öffentliches Repository.

Claude Code ersetzt ${GTM_SERVICE_ACCOUNT_KEY} in dieser Konfiguration durch den Wert der Umgebungsvariablen. Der Wert muss das vollständige Schlüssel-JSON des Dienstkontos enthalten, keinen Dateipfad. Das Konto braucht außerdem die passenden Tag-Manager-Rechte.

{
  "mcpServers": {
    "gtm": {
      "command": "npx",
      "args": [
        "-y",
        "google-tag-manager-mcp-server@5.1.1"
      ],
      "env": {
        "GOOGLE_SERVICE_ACCOUNT_KEY": "${GTM_SERVICE_ACCOUNT_KEY}",
        "GTM_SCOPES": "https://www.googleapis.com/auth/tagmanager.readonly"
      }
    }
  }
}

Die feste CLI-Version macht den Vergleich nachvollziehbarer, fixiert aber nicht automatisch alle abhängigen Pakete. Für eine genau reproduzierbare Installation braucht auch die Abhängigkeitsauflösung einen festgehaltenen Stand. Die unterschiedlichen MCP-Pakete verwenden zudem unterschiedliche Namen und Verfahren für Zugangsdaten.

Änderungen ohne versehentlichen Datenverlust

Vor einer Aktualisierung wird das aktuelle Objekt gelesen. Anschließend wird nur die beabsichtigte Stelle geändert und das für die Methode erforderliche vollständige Objekt übertragen. Ein PUT-Aufruf ist nicht automatisch eine partielle Ergänzung. Welche Felder fehlen dürfen, hängt von der konkreten Methode und dem Server ab.

Ein fingerprint kennzeichnet den gelesenen Objektstand. Bei tags.update ist dieser Prüfparameter in der API optional. Wird der alte Fingerprint mitgesendet und inzwischen geändert, stimmt der Wert nicht mehr überein. Ohne dieses Mitsenden besteht dieser Schutz nicht. Auch ein passender Fingerprint beweist keine fachlich richtige Tag-Konfiguration.

Tag-Parameter können Listen und verschachtelte Objekte enthalten. Eine Messungs-ID, eine Variablenreferenz und eine Tag-Referenz sind unterschiedliche Werte. Ein vorhandener, aktueller Export des richtigen Tag-Typs ist deshalb die bessere Vorlage als ein beliebiges GA4-JSON-Beispiel. Zusätzlich müssen referenzierte Variablen und Auslöser im Zielcontainer vorhanden sein.

Im Browser prüfen und die Änderung erklären

quick_preview erzeugt eine Vorschauversion. Der Aufruf öffnet keine Website und beweist nicht, dass ein Kaufereignis zur richtigen Zeit ankommt. Eine Browserprüfung muss unter anderem Auslöser, Data-Layer-Werte und Einwilligungszustände abdecken. Eine zusätzliche Browseranbindung kann dabei helfen, ersetzt diese Prüfung aber nicht durch einen API-Aufruf.

Versionsname und Beschreibung können den Grund einer Änderung festhalten. Solche Angaben entstehen nicht automatisch aus einem Prompt und lassen sich auch später über die Versionsverwaltung ändern. Ein Export vor und nach der Änderung zeigt zusätzlich den tatsächlichen Unterschied. Der Vergleich allein benötigt keine weiteren Google-Zugangsdaten, sobald beide Dateien vorliegen.

Fragen und Antworten

Ist eine kleinere Werkzeugliste immer besser?

Nein. Kleine Definitionen können weniger Informationen zur korrekten Eingabe liefern. Ausführliche Definitionen können Fehler vermeiden. Entscheidend sind Aufgabe, Qualität der Beschreibungen und tatsächlich geladener Kontext. Eine feste API-Antwortzeit lässt sich daraus nicht ableiten.

Kann ein einzelnes Werkzeug zugleich lesen und veröffentlichen?

Ja. Bei gebündelten Aktionen sperrt eine reine Namensregel möglicherweise beide Vorgänge. Eine Prüfung des Aktionsparameters ist genauer, muss aber zur eingesetzten Serverversion passen. Ein separates Veröffentlichungswerkzeug ist leichter einzeln zu sperren.

Warum ein eigener Workspace?

Ein eigener Entwurf trennt zusammengehörige Änderungen und erleichtert Prüfung oder Verwerfen. Änderungen aus anderen Workspaces können trotzdem einen Abgleich und eine Konfliktlösung erfordern. workspaces.sync unterstützt diesen Abgleich. Die verfügbare Anzahl paralleler Workspaces hängt vom Tag-Manager-Angebot ab.

Was belegt ein fehlgeschlagener Paketstart?

Ein Startfehler wegen fehlender Datenbank- oder Schlüsselkonfiguration belegt zunächst nur fehlende Voraussetzungen dieses Starts. Daraus folgt nicht, dass das Paket grundsätzlich nie lokal laufen kann. Die Paketdokumentation und die tatsächlich benötigten Dienste klären den Einsatzweg.

Quellen

Lukas Wojcik

Lukas Wojcik

Systems architect and technology enthusiast specializing in scalable tracking solutions, GMP Stack (GA4 & GTM), and robust backend architectures. Advocate for clean code and privacy-first design.

Kontakt

Eine Frage oder eine Idee für ein Webprojekt? Schreib mir kurz, worum es geht. Das Formular nutzt reCAPTCHA zum Schutz vor Spam.

Kommentar schreiben

Erfahrungen mit anderen Modellen oder Anbietern und Rückfragen zur Umsetzung sind hier willkommen.

Die E-Mail-Adresse wird nicht veröffentlicht. Pflichtfelder sind mit einem Stern versehen.