Claude Code für Google Ads: Mechanik und Grenzen

Der Nutzen liegt in der Analyse, das Risiko im Schreibzugriff

Claude Code lohnt sich für Google Ads zuerst als Analysewerkzeug, das Kontodaten mit Zahlen zusammenführt, die das Konto nicht hat. Meine Einschätzung folgt aus einer einfachen Kostenrechnung: Ein Lesefehler kostet Prüfzeit, ein Schreibfehler kostet Budget. Wer mit Automatik im Konto anfängt, trägt das teurere Risiko für den kleineren Teil des Nutzens.

Mechanisch ist das Werkzeug kein Google-Ads-Produkt. Claude Code läuft lokal und führt mit deiner Erlaubnis Befehle aus und liest Dateien. Google Ads kennt es erst, wenn du ihm einen Weg zu den Daten gibst.

Drei Wege an die Kontodaten

Googles offizieller MCP-Server bietet drei Werkzeuge: Kontodaten abfragen, Metadaten zu Ressourcen lesen, erreichbare Konten auflisten. Laut Google ist er ausschließlich lesend und kann weder Gebote ändern noch Kampagnen pausieren. Was er sonst noch kann, steht im Artikel zum Google-Ads-MCP-Server.

Für den Einstieg rate ich zum Export. Er zeigt ohne jede Einrichtung, ob die Fragestellung überhaupt etwas bringt, und nichts im Konto kann sich dabei ändern.

Welcher API-Zugang nötig ist

Viele Anleitungen sind hier veraltet. Google hat Developer Tokens am 9. September 2026 eingestellt: Mitgesendete Tokens werden ignoriert, die Zugriffsstufe hängt am Google-Cloud-Projekt. Die Reihenfolge, Stand November 2026:

1. Google-Cloud-Projekt anlegen und die Google Ads API aktivieren. Das ergibt Test-Zugriff mit 15.000 Operationen pro Tag, aber nur auf Testkonten.
2. Explorer-Zugriff beantragen. Laut Google wird das meist automatisch geprüft und freigegeben, bis 2.880 Operationen pro Tag auf echten Konten.
3. OAuth-Login mit dem Scope adwords einrichten und den MCP-Server in Claude Code eintragen.
4. Ein Verwaltungskonto brauchst du nur, wenn du mehrere Konten über die API verknüpfen und verwalten willst.

Für Analysen an einem einzelnen Konto halte ich das Explorer-Kontingent für ausreichend. Wer viele Konten dauerhaft abfragt, sollte es vorher nachrechnen.

Warum Lesezugriff das Budget nur scheinbar schützt

Der Lesemodus sitzt im Server und nicht im Schlüssel. Google schreibt im Code des Servers, dass es keinen eigenen Read-only-Scope gibt: Der Server beschränkt den Zugriff nur dadurch, dass er keine Schreibwerkzeuge anbietet. Derselbe Scope erlaubt auch Änderungen.

Dazu kommt die Shell. Anthropic weist darauf hin, dass Claude über Bash weiterhin beliebige Adressen erreichen kann, wenn Bash erlaubt ist, auch wenn einzelne Werkzeuge gesperrt sind. Regeln, die Befehlsargumente einschränken, nennt die Doku selbst fragil. Meine Ableitung daraus: Liegen die Zugangsdaten auf demselben Rechner und ist die Shell freigegeben, kann der Agent eine Änderung selbst schreiben, obwohl der MCP-Server nur liest. Googles Developer Assistant für Claude Code erzeugt solchen Code für Änderungen sogar ausdrücklich.

Drei Maßnahmen verkleinern diese Lücke, ich würde in dieser Reihenfolge vorgehen:

• Eigener Nutzer mit Nur-Lesen-Rolle. Diese Zugriffsstufe darf in Google Ads keine Kampagnen bearbeiten. Teste das: Eine Änderungsanfrage mit diesem Login muss einen Fehler zurückgeben.
• Shell-Freigaben einzeln halten. Im manuellen Modus fragt Claude Code vor Bash-Befehlen nach. „Nicht mehr fragen“ gilt dauerhaft für Repository und Befehl, also klicke das nicht aus Bequemlichkeit.
• Sandbox statt Befehlsmuster. Sie begrenzt Dateisystem und Netz unabhängig vom Befehlstext, solange die Google-Ads-API nicht zu den erlaubten Domains gehört. Befehle darin laufen standardmäßig ohne Rückfrage.

Wie du Freigaben und Trockenläufe im Detail aufbaust, steht unter KI-Agenten im Konto absichern.

Wofür es taugt: gegen Zahlen rechnen, die das Konto nicht hat

Das Konto kennt weder Marge noch Retouren noch Bestand. Ein Agent, der nur Kontodaten sieht, optimiert deshalb sauber auf einen Wert, der den Deckungsbeitrag nicht abbildet. Ein Rechenbeispiel mit erfundenen Zahlen, je 1.000 Euro Umsatz nach Retouren:

Ohne Margendaten wandert das Budget zu B, mit Margendaten zu A. Genau diese Zusammenführung ist die Stärke des Werkzeugs: Es liest Bericht und Margendatei, rechnet je Produktgruppe den Break-even-ROAS und listet auf, wo der ausgewiesene ROAS darunter liegt. Dasselbe funktioniert mit Bestandslisten oder einem wirtschaftlich ausgewerteten Suchbegriffsbericht.

Das gilt nur eingeschränkt, wenn dein Conversion-Wert bereits den Deckungsbeitrag enthält. Dann sieht das Konto mehr, Retouren und Bestand fehlen aber meist trotzdem.

Wofür es nicht taugt

Nach meiner Einschätzung sind vier Aufgaben schlecht aufgehoben:

• Ursachen belegen. Ein Modell findet Muster in Berichten. Warum der ROAS gefallen ist, beweist es damit nicht. Jede Aussage braucht eine Gegenprüfung, siehe KI-Analysen von Kontodaten prüfen.
• Feste Regeln im Dauerbetrieb. Was immer gleich abläuft, erledigt ein Skript günstiger und berechenbarer, dazu Skripte oder KI-Agenten.
• Unbeaufsichtigte Änderungen an Gebotsstrategien. Der Schaden endet hier nicht mit dem Zurücksetzen.
• Zahlen ohne Rückweg zur Quelle. Eine Auswertung, die du nicht bis zur Abfrage nachvollziehen kannst, gehört nicht in eine Budgetentscheidung.

Freigabegrenze nach Schaden statt nach Komfort

Lege für jede Änderungsart fest, wie viel sie maximal kosten kann, bevor es jemand merkt. Die Formel: betroffener Tageswert × Tage bis zur nächsten Kontrolle. Erfundene Beispiele:

Bei einer angenommenen Grenze von 300 Euro reicht beim negativen Keyword die Stichprobe, Budget und Pause bekommen eine Einzelfreigabe. Die Grenze selbst ist eine kaufmännische Entscheidung, die dir kein Tool abnimmt.

Die Formel unterschätzt zwei Fälle: Änderungen an Gebotsstrategien, weil die Folgen das Zurücksetzen überdauern können, und Aktionszeiten, in denen der Tageswert ein Vielfaches beträgt. Beides gehört immer in die Einzelfreigabe.

Technisch hilft der Parameter validate_only: Die Anfrage wird geprüft, aber nicht ausgeführt, zurück kommen nur Fehler. Das schützt vor kaputten Anfragen. Eine gültige Anfrage kann wirtschaftlich trotzdem falsch sein.

Welche Risiken neben dem Budget bleiben

Datenfluss. Lokal zu laufen heißt nicht, dass nichts den Rechner verlässt. Claude Code sendet Prompts und Modellantworten übers Netz, und Google warnt, dass der MCP-Server die Kontodaten dem angeschlossenen Modell offenlegt. Bei Free, Pro, Max und Ultra hängt das Modelltraining an einer Einstellung, bei Team, Enterprise und API trainiert Anthropic laut Doku standardmäßig nicht mit diesen Daten. Prüfe also Tarif und Datenschutzpflichten, bevor Kundendaten im Spiel sind. Die Einordnung dazu steht unter Kontodaten in KI-Tools.

Prompt Injection. OWASP führt indirekte Injection über externe Inhalte als Risiko, hält einen sicheren Schutz für ungeklärt und nennt minimale Rechte und menschliche Freigabe als Gegenmittel. Meine Ableitung: Suchbegriffe sind Text, den Fremde ins Konto schreiben, ebenso Inhalte von Landingpages, die der Agent abruft. Einen Agenten mit Schreibrechten würde ich solche Daten deshalb nicht lesen lassen. Mit einem Login, der im Test nachweislich nicht schreiben kann, bleibt von einer Injection eine falsche Auswertung, die du gegenprüfen musst, und bei freiem Netz ein möglicher Abfluss von Kontodaten.