{"id":17823,"date":"2026-09-13T14:30:00","date_gmt":"2026-09-13T12:30:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=17823"},"modified":"2026-09-09T21:29:27","modified_gmt":"2026-09-09T19:29:27","slug":"claude-code-gtm-integrationen-mcp-server-kontextpreis","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/de\/cloud-ai-de\/claude-code-gtm-integrationen-mcp-server-kontextpreis\/","title":{"rendered":"GTM-Integrationen f\u00fcr Claude Code: Drei MCP-Server, ihre Werkzeugzahl und ihr Kontextpreis"},"content":{"rendered":"

Ein Google-Tag-Manager-Container ist ein JSON-Dokument, das dar\u00fcber entscheidet, welche Skripte eine Website l\u00e4dt und wann. Diesen Container per Prompt zu \u00e4ndern hei\u00dft, einem Sprachmodell Schreibzugriff auf dieses Dokument zu geben. Die interessante Frage ist nicht, ob das funktioniert \u2014 das tut es \u2014, sondern was das Modell genau anfassen darf und was die Anbindung kostet, bevor ein einziges Tag entsteht.<\/p>\n

F\u00fcr diesen Artikel wurden am 9. September 2026 drei Integrationen gemessen: drei MCP-Server, jeder mit npx<\/code> \u00fcber stdio auf einem Raspberry Pi 5 mit Node 20.19.2 gestartet und nach seiner Werkzeugliste gefragt, dazu die Tag-Manager-API v2, auf der alle drei aufsetzen. Die Zahlen unten stammen aus diesen L\u00e4ufen und aus dem Discovery-Dokument der API, nicht aus den READMEs.<\/p>\n

\n\"Der
Der Weg einer \u00c4nderung, die Gr\u00f6\u00dfe dreier gemessener Werkzeuglisten und die Verteilung der 106 API-Methoden auf sieben Scopes.<\/figcaption><\/figure>\n

Drei Wege, auf denen ein Container zum Modell kommt<\/h2>\n

Claude Code wei\u00df von sich aus nichts \u00fcber den Tag Manager. Alles, was mit einem Container m\u00f6glich wird, kommt \u00fcber einen von drei Wegen, und nur zwei davon f\u00fcgen \u00fcberhaupt eine F\u00e4higkeit hinzu.<\/p>\n

Ein MCP-Server<\/strong> ist ein Prozess, den Claude Code startet und mit dem es \u00fcber stdio oder HTTP spricht. Er ver\u00f6ffentlicht eine Liste von Werkzeugen, und jedes davon erscheint in der Sitzung unter dem Namen mcp__<server>__<werkzeug><\/code>. Auf genau diesen Namen greifen sp\u00e4ter Berechtigungsregeln und Hooks zu \u2014 deshalb lohnt es sich, ihn zu kennen.<\/p>\n

Der direkte Weg \u00fcber die Kommandozeile<\/strong> braucht gar keinen Server. Ein Zugriffstoken und curl<\/code> gen\u00fcgen, und das Modell schreibt die Anfrage selbst. Vorab landet nichts im Kontext, daf\u00fcr verschwindet auch nichts hinter einer H\u00fclle \u2014 der Tausch lautet Bequemlichkeit gegen Durchsicht.<\/p>\n

Eine Skill oder ein Slash-Befehl<\/strong> f\u00fcgt \u00fcberhaupt keine F\u00e4higkeit hinzu. Darin steht ein Rezept: eine Namenskonvention, eine Pr\u00fcfliste, die Reihenfolge, in der ein Trigger existieren muss, bevor ein Tag ihn referenzieren kann. Das \u00e4ndert, was das Modell auf den anderen beiden Wegen tut, nie aber, was es tun darf. Diese beiden Dinge zu verwechseln ist das h\u00e4ufigste Missverst\u00e4ndnis am Wort \u201eIntegration”.<\/p>\n

Was darunter liegt: 106 Methoden, sieben Scopes, ein Workspace<\/h2>\n

Alle Wege enden an derselben Stelle. Das Discovery-Dokument der Tag-Manager-API v2, Fassung 20260902 und 270.858 Byte gro\u00df, beschreibt 106 Methoden in 18 Ressourcen<\/strong>: 38 GET, 38 POST, 15 PUT und 15 DELETE.<\/p>\n

Zehn dieser Ressourcen liegen innerhalb eines Workspace \u2014 Tags, Trigger, Variablen, integrierte Variablen, Ordner, Vorlagen, Clients, Transformationen, Zonen und die gtag-Konfiguration. Ein Workspace ist ein Entwurf. Was dort hineingeschrieben wird, erreicht keinen einzigen Besucher, ganz gleich wie falsch es ist.<\/p>\n

Zwischen Entwurf und Live-Seite stehen zwei weitere Schritte. workspaces.create_version<\/code> friert einen Workspace zu einer Containerversion ein, und versions.publish<\/code> macht diese Version live. Der Scope tagmanager.publish<\/code> deckt genau zwei der 106 Methoden<\/strong> ab: den Ver\u00f6ffentlichungsaufruf und environments.reauthorize<\/code>. Alles andere, was eine Integration anstellen kann, bleibt bauartbedingt f\u00fcr Besucher unsichtbar, bis ein eigener Aufruf etwas anderes bestimmt.<\/p>\n

# Tags lesen: der Pfad traegt Konto, Container und Workspace.\n# Eine Workspace-ID ist Pflicht - zu den Live-Tags fuehrt keine Route.\nACC=6012345678; CONT=123456789; WS=42\ncurl -s -H \"Authorization: Bearer $TOKEN\" \\\n  \"https:\/\/tagmanager.googleapis.com\/tagmanager\/v2\/accounts\/$ACC\/containers\/$CONT\/workspaces\/$WS\/tags\"\n\n# Ohne Token antwortet jede Methode gleich:\n# {\"error\":{\"code\":401,\"status\":\"UNAUTHENTICATED\",\n#   \"details\":[{\"reason\":\"CREDENTIALS_MISSING\"}]}}<\/code><\/pre>\n
F\u00fcnfzehn Schemas der API f\u00fchren ein Feld fingerprint<\/code>, dessen Wert sich mit jeder \u00c4nderung des Objekts \u00e4ndert. Eine Aktualisierung mit veraltetem Fingerabdruck wird abgewiesen, statt eine Bearbeitung zu \u00fcberschreiben, die inzwischen jemand im Browser vorgenommen hat.<\/p>\n
Drei MCP-Server, drei Zuschnitte derselben API<\/h2>\n\n\n\n\n\n
Server<\/th>\nWerkzeuge<\/th>\ntools\/list<\/th>\n\u2248 Token<\/th>\nZuschnitt<\/th>\n<\/tr>\n
google-tag-manager-mcp-server<\/code> 5.1.1<\/td>\n18<\/td>\n108.201 B<\/td>\n27.000<\/td>\nein Werkzeug je Objektart, Aktion als Parameter<\/td>\n<\/tr>\n
gtm-mcp<\/code> 1.0.0<\/td>\n104<\/td>\n49.656 B<\/td>\n12.400<\/td>\netwa ein Werkzeug je API-Methode<\/td>\n<\/tr>\n
@theethosteam\/gtm-mcp<\/code> 1.1.1<\/td>\n33<\/td>\n19.797 B<\/td>\n4.900<\/td>\naufgabennah, f\u00fcnf Rezepte und ein Rohaufruf<\/td>\n<\/tr>\n<\/table>\n
Der erste packt die ganze API hinter 18 Werkzeuge. Siebzehn davon nehmen einen Parameter action<\/code> entgegen, der zusammen 101 Aktionen tr\u00e4gt, von denen 38 nur lesen; allein gtm_tag<\/code> deckt create, get, list, update, remove und revert ab. Das achtzehnte, gtag_destination<\/code>, listet nur.<\/p>\n
Der zweite bildet die API fast eins zu eins ab: 104 Werkzeuge gegen\u00fcber 106 Methoden, 37 davon hei\u00dfen get_\u2026<\/code> oder list_\u2026<\/code>.<\/p>\n
Der dritte folgt dem Zuschnitt der API gar nicht. Neben den gew\u00f6hnlichen Aufrufen f\u00fchrt er f\u00fcnf Rezepte \u2014 gtm_recipe_ga4_config<\/code>, gtm_recipe_ga4_event<\/code>, gtm_recipe_meta_pixel<\/code> und zwei Trigger-Rezepte \u2014 und einen 215 Byte kleinen Notausgang namens gtm_raw<\/code> f\u00fcr alles, was die \u00fcbrigen 32 Werkzeuge nicht erreichen.<\/p>\n
Ein vierter Kandidat startete \u00fcberhaupt nicht. @yoryoboy\/gtm-mcp<\/code> 4.1.0 brach mit Missing required configuration: DATABASE_URL, DB_ENCRYPTION_KEY<\/code> ab, weil er als gehosteter Mehrmandantendienst mit PostgreSQL dahinter gebaut ist und nicht als lokaler Prozess. Eine Ver\u00f6ffentlichung auf npm mit \u201eMCP server” in der Beschreibung sagt nichts dar\u00fcber, ob ein Paket auf einem Arbeitsplatzrechner l\u00e4uft.<\/p>\n
Der Kontextpreis steht nicht in der Werkzeugzahl<\/h2>\n
Die drei Werkzeuglisten unterscheiden sich um den Faktor 5,5 in der Gr\u00f6\u00dfe, und die Reihenfolge folgt nicht der Zahl der Werkzeuge. Der Server mit 18 Werkzeugen sendet 108.201 Byte Definitionen, der mit 33 nur 19.797.<\/p>\n
Zwei Werkzeuge machen fast die H\u00e4lfte der gr\u00f6\u00dften Liste aus: gtm_version<\/code> mit 28.212 Byte und gtm_workspace<\/code> mit 24.594, zusammen 48,8 Prozent von 108.201. Der Grund ist die Ressource ContainerVersion. In ihr stecken Tags, Trigger, Variablen, Clients, Ordner, Zonen, Vorlagen, Transformationen und die gtag-Konfiguration, ein vollst\u00e4ndig typisiertes Schema davon ist also zwangsl\u00e4ufig gro\u00df \u2014 und es wird mitgeschickt, ob je eine Version angefasst wird oder nicht.<\/p>\n
Das ist keine einmalige Ausgabe beim Verbinden. Werkzeugdefinitionen geh\u00f6ren zur Anfrage und reisen deshalb bei jedem Zug der Sitzung mit. Daraus folgen zwei Dinge. Mehrere Server dieses Zuschnitts gleichzeitig anzubinden f\u00fcllt einen betr\u00e4chtlichen Teil des Kontextfensters, bevor die Arbeit beginnt. Und ein Server mit lockereren Schemas ist nicht selbstverst\u00e4ndlich die schw\u00e4chere Wahl: einen falschen Feldtyp f\u00e4ngt die API binnen einer Sekunde ab, w\u00e4hrend ein genaues Schema in jedem einzelnen Zug bezahlt wird.<\/p>\n
Was eine Integration \u00e4ndern darf, entscheidet das Token<\/h2>\n
Alle drei Server melden sich auf dieselbe Weise bei Google an, und das eigentliche Gel\u00e4nder ist der OAuth-Scope. Die Voreinstellung des gr\u00f6\u00dften Servers fordert alle sieben an, Ver\u00f6ffentlichen und Containerl\u00f6schung eingeschlossen \u2014 nachzulesen in seiner src\/constants\/scopes.ts<\/code> als schlichte Liste.<\/p>\n
Diese Menge l\u00e4sst sich einengen. Der Server liest GTM_SCOPES<\/code> aus seiner Umgebung und trennt an Leerzeichen oder Kommas. Die Einengung wirkt allerdings nur in einer der drei Anmeldearten<\/strong>. Im Quelltext \u00fcbergibt createAuthFromEnv<\/code> die gelesenen Scopes ausschlie\u00dflich an den Zweig f\u00fcr Dienstkonten; der Zweig f\u00fcr Refresh-Token bekommt Client-ID, Geheimnis und Token, der Zweig f\u00fcr Zugriffstoken bekommt das Token. Ein Refresh-Token tr\u00e4gt die Scopes bereits in sich, mit denen es ausgestellt wurde, und ein daneben gesetztes GTM_SCOPES<\/code> \u00e4ndert nichts und meldet nichts.<\/p>\n
{\n  \"mcpServers\": {\n    \"gtm\": {\n      \"command\": \"npx\",\n      \"args\": [\"-y\", \"google-tag-manager-mcp-server\"],\n      \"env\": {\n        \"GOOGLE_SERVICE_ACCOUNT_KEY\": \"{...}\",\n        \"GTM_SCOPES\": \"https:\/\/www.googleapis.com\/auth\/tagmanager.readonly\"\n      }\n    }\n  }\n}<\/code><\/pre>\n
Ein zweites Tor sitzt im Tag Manager selbst. Ein Dienstkonto erreicht einen Container erst, nachdem seine Adresse dort als Benutzer eingetragen wurde, und diese Berechtigung ist je Container abgestuft: lesen, bearbeiten, genehmigen, ver\u00f6ffentlichen. Ein Konto mit Bearbeitungsrecht und Ver\u00f6ffentlichungs-Scope kann trotzdem nicht ver\u00f6ffentlichen.<\/p>\n
Das dritte Tor steht auf der Seite von Claude Code und greift am Werkzeugnamen an. Eine Sperrregel auf mcp__gtm__gtm_version<\/code> nimmt das Ver\u00f6ffentlichungswerkzeug aus der Reichweite, auch wo das Token den Aufruf erlauben w\u00fcrde, und ein PreToolUse<\/code>-Hook auf denselben Namen kann stattdessen eine Best\u00e4tigung verlangen. Drei voneinander unabh\u00e4ngige Tore also, und sinnvoll ist es, das \u00e4u\u00dferste zu schlie\u00dfen \u2014 das Token \u2014, weil allein dieses auch dann h\u00e4lt, wenn der Container von anderswo als aus dieser Sitzung erreicht wird.<\/p>\n
Wo es schiefgeht<\/h2>\n
Update ersetzt, es erg\u00e4nzt nicht.<\/strong> F\u00fcnfzehn der 18 Werkzeugbeschreibungen sagen es selbst: Jedes Feld, das in der Nutzlast fehlt, wird gel\u00f6scht. Ein Modell, das nur das zu \u00e4ndernde Feld schickt, r\u00e4umt den Rest des Tags ab. Elf der Werkzeuge verlangen zus\u00e4tzlich den Fingerabdruck des zuletzt gelesenen Standes, was vor jedem Schreiben ein Lesen erzwingt und aus einer unachtsamen \u00c4nderung eine Fehlermeldung statt eines Verlusts macht.<\/p>\n
Ein Tag ist kein flaches Objekt.<\/strong> Seine Einstellungen liegen in einem Feld parameter<\/code> aus Schl\u00fcssel, Typ und Wert, mit acht Typen in der Aufz\u00e4hlung \u2014 template<\/code>, integer<\/code>, boolean<\/code>, list<\/code>, map<\/code>, triggerReference<\/code>, tagReference<\/code> und dem unbestimmten \u2014, wobei list<\/code> und map<\/code> weitere Parameter in sich verschachteln. An dieser Struktur, nicht am Tag-Namen, scheitern erzeugte Nutzlasten.<\/p>\n
{\n  \"name\": \"GA4 - purchase\",\n  \"type\": \"gaawe\",\n  \"parameter\": [\n    { \"type\": \"template\", \"key\": \"eventName\", \"value\": \"purchase\" },\n    { \"type\": \"tagReference\", \"key\": \"measurementId\",\n      \"value\": \"GA4 Configuration\" },\n    { \"type\": \"list\", \"key\": \"eventParameters\", \"list\": [\n      { \"type\": \"map\", \"map\": [\n        { \"type\": \"template\", \"key\": \"name\",  \"value\": \"value\" },\n        { \"type\": \"template\", \"key\": \"value\", \"value\": \"{{DLV - value}}\" }\n      ]}\n    ]}\n  ],\n  \"firingTriggerId\": [\"17\"]\n}<\/code><\/pre>\n
\u201eGTM” ist im Paketverzeichnis mehrdeutig.<\/strong> Eine Suche nach gtm-mcp<\/code> liefert neben den Tag-Manager-Servern auch solche f\u00fcr Go-to-Market-Frameworks; @shashwatgtmalpha\/craft-gtm-mcp<\/code> f\u00fchrt go-to-market<\/code> unter seinen Schlagworten, und growth-mcp<\/code> bezeichnet sich als \u201eopen-source GTM MCP server”, ohne den Tag Manager \u00fcberhaupt zu meinen. Die Schlagwortliste trennt die beiden schneller als die Beschreibung.<\/p>\n
Was das nicht l\u00f6st<\/h2>\n
Keine dieser Integrationen kann feststellen, ob ein Tag tats\u00e4chlich ausl\u00f6st. quick_preview<\/code> \u00fcbersetzt einen Workspace in eine Vorschauversion; eine Seite l\u00e4dt es nicht, und \u00fcber einen zu sp\u00e4t eintreffenden Data Layer sagt es nichts. Das Urteil \u00fcber die Richtigkeit bleibt bei einer Vorschausitzung im Browser, genau wie zuvor.<\/p>\n
Ebenso wenig h\u00e4lt die API fest, warum etwas ge\u00e4ndert wurde. Eine Containerversion tr\u00e4gt Namen und Beschreibung, und beide bleiben leer, sofern sie nicht im selben Aufruf gef\u00fcllt werden \u2014 was die Versionsbeschreibung zur billigsten Stelle macht, um festzuhalten, welcher Prompt welche \u00c4nderung ausgel\u00f6st hat, und zugleich zum Ersten, was bei einem eilig angelegten Tag fehlt.<\/p>\n
Und der Dateiweg ist nicht \u00fcberholt. Ein exportierter Container ist eine einzige JSON-Datei, und sie gegen einen Diff zu pr\u00fcfen braucht weder Token noch Scope noch Server. F\u00fcr eine \u00c4nderung, die ein Modell schreibt und ein Mensch liest, bleibt der Export der k\u00fcrzere Weg \u2014 der Vorteil der API beginnt dort, wo die \u00c4nderung angewendet werden muss, nicht dort, wo sie verstanden werden muss.<\/p>\n
\n
Quellen<\/h2>\n