Wer Google Ads mit Claude, ChatGPT oder einem anderen KI-Assistenten verbinden will, landet schnell beim Begriff Google Ads MCP. Die Erwartung ist meistens dieselbe: im Chat fragen, welche Kampagne Geld verbrennt, und danach gleich die Negative Keywords setzen lassen.
Der erste Teil klappt. Der zweite nicht mit dem offiziellen Werkzeug. Googles eigener Google Ads MCP Server kann Daten lesen, aber nichts ändern. Für Änderungen braucht es einen anderen Weg, und genau dort wird es heikel, weil ab dann echtes Werbebudget im Spiel ist.
Ich steuere unser eigenes Google-Ads-Konto seit dem Sommer 2026 größtenteils über Claude. Erst über einen gehosteten MCP-Anbieter, inzwischen über die Google Ads API direkt. Dieser Artikel beschreibt, was der offizielle Server kann, wie die Einrichtung aussieht und welche Regeln ich mir für Schreibzugriffe gegeben habe. Inklusive eines Fehlers, bei dem die API “Erfolg” meldete und nichts passiert ist.
Was ein Google Ads MCP Server ist
MCP steht für Model Context Protocol. Das ist ein offener Standard, über den ein Sprachmodell externe Werkzeuge aufrufen kann. Statt dass jede Anwendung eine eigene KI-Schnittstelle erfindet, beschreibt ein MCP Server seine Werkzeuge in einem einheitlichen Format, und der KI-Client (Claude Desktop, Claude Code, Cursor und andere) kann sie nutzen.
Ein Google Ads MCP Server ist also die Brücke zwischen dem Modell und der Google Ads API. Man schreibt im Chat “Welche Suchbegriffe hatten in den letzten 14 Tagen Kosten, aber keine Conversion?”, das Modell wählt das passende Werkzeug, der Server fragt die API ab, und das Ergebnis landet wieder im Chat. Wie Modelle solche Werkzeugketten grundsätzlich abarbeiten, erkläre ich ausführlicher im Artikel KI-Agent erklärt.
Der offizielle Google Ads MCP Server kann nur lesen
Der offizielle Server bringt drei Werkzeuge mit, alle zum Lesen.
Google hat den Server im Oktober 2025 als Open Source veröffentlicht. Laut GitHub-Repository gibt es genau drei Werkzeuge:
- search: führt eine Abfrage in GAQL (Google Ads Query Language) aus und liefert die Daten zurück
- get_resource_metadata: liefert Metadaten zu einem Ressourcentyp der Google Ads API
- list_accessible_customers: listet die Kundenkonten, auf die die Zugangsdaten Zugriff haben
Mehr gibt es nicht. Googles Entwicklerdokumentation formuliert es ohne Umschweife: “This implementation is strictly read-only.” Keine Gebote, kein Pausieren, keine neuen Anzeigen. Stand September 2026 ist auch keine Schreibfunktion angekündigt.
Das ist eine bewusste Entscheidung. Eine falsche Leseabfrage kostet Zeit. Eine falsche Änderung an einem laufenden Konto kostet Geld, oft ohne dass man es sofort merkt. Google hat den ungefährlichen Teil zuerst gebaut.
Einrichtung: Was man für Google Ads MCP mit Claude braucht
Die Voraussetzungen sind dieselben wie für jede Arbeit mit der Google Ads API:
- Ein Google-Cloud-Projekt mit aktivierter Google Ads API.
- Ein Developer Token aus dem Google-Ads-Verwaltungskonto. Für Produktivkonten braucht das Token mindestens die Zugriffsstufe “Explorer”. Für Testkonten reicht ein Token mit Testzugriff.
- OAuth-Zugangsdaten (Client-ID und Client-Secret) aus dem Cloud-Projekt.
- Die Login-Kundennummer, falls man über ein Verwaltungskonto (MCC) auf das Werbekonto zugreift.
Den Server selbst startet man laut Doku mit pipx direkt aus dem Python-Paket und trägt ihn in die MCP-Konfiguration von Claude Desktop oder Claude Code ein. Alternativ lässt er sich auf Google Cloud Run betreiben, wenn mehrere Personen oder Agenten ihn nutzen sollen. Die genauen Befehle ändern sich mit jeder Version, deshalb verlinke ich hier bewusst auf die offizielle Anleitung statt einen Codeblock abzudrucken, der in drei Monaten veraltet ist.
Zwei Punkte, die ich bei der Einrichtung ernst nehmen würde:
- Zugangsdaten gehören nicht in den Chat und nicht ins Repository. Bei mir liegt die
google-ads.yamlmit Token und Refresh-Token im Home-Verzeichnis, nur für meinen Benutzer lesbar (chmod 600), außerhalb jedes Git-Projekts. Das Modell sieht Werkzeugaufrufe und Ergebnisse, nie die Schlüssel. - Alles, was der Server lesen kann, kann auch das Modell lesen. Wer den Server an ein Konto hängt, gibt dem angeschlossenen Modell Einblick in Kosten, Keywords und Conversion-Daten. Bei Kundenkonten ist das eine Datenschutzfrage, die man vorher klären muss. Mehr dazu im Artikel ChatGPT und DSGVO im Unternehmen.
Wofür Lesen per Chat im Alltag reicht
Nur lesen klingt nach wenig. In der Praxis ist es der größere Teil der Arbeit. Bevor man etwas ändert, muss man wissen, was los ist, und genau dafür ist die Google-Ads-Oberfläche erstaunlich umständlich.
Suchbegriffe prüfen. Bei uns war das der wichtigste Anwendungsfall. Eine Kampagne für MVP-Entwicklung bekam im Juli fast nur Suchen wie “mvp abkürzung” oder “mvp bedeutung”. Das sind Leute, die eine Definition suchen, keinen Dienstleister. Im Chat war das in einer Frage sichtbar. In der Oberfläche hätte ich mich durch den Suchbegriffbericht klicken müssen.
Ursachen für fehlende Impressionen finden. Eine Frage wie “Warum bekommt Kampagne X kaum noch Impressionen?” führt zu Abfragen auf Impression Share, Rang-Verluste und Anzeigenrelevanz. Bei uns kam dabei heraus, dass 14 von 22 Keywords einer Kampagne eine unterdurchschnittliche Anzeigenrelevanz hatten. Ein höheres Gebot hätte das Problem nur teurer gemacht.
GAQL, ohne GAQL zu schreiben. Das Modell formuliert die Abfrage selbst. Wer GAQL kann, gibt präzise Abfragen vor und bekommt saubere Tabellen zurück.
Keyword-Recherche vor neuen Kampagnen. Der offizielle MCP Server deckt den Keyword Planner nicht ab. Über die Google Ads API geht es trotzdem. Wir fragen Suchvolumen und Keyword-Ideen per Skript ab, das Claude Code geschrieben hat.
Ehrlicherweise: Für ein kleines Konto braucht man keinen MCP Server. Unser Konto hat zwei aktive Kampagnen, die Oberfläche würde reichen. Ich nutze den Chat trotzdem, weil ich fast täglich nachsehe und eine Frage schneller gestellt ist als ein Bericht zusammengeklickt. Der Nutzen steigt mit der Zahl der Kampagnen und mit der Häufigkeit, mit der man nachschaut.
Schreibzugriff: Welche Wege es gibt
Wer Änderungen per Chat machen will, hat drei Möglichkeiten:
- Gehostete MCP-Anbieter mit Schreibfunktion. Es gibt inzwischen Dutzende. Man verbindet das Konto per OAuth und bekommt Werkzeuge zum Pausieren, für Negatives, Gebote und mehr. Vorteil: schnell eingerichtet. Nachteil: Ein Drittanbieter hält Schreibrechte auf das Werbekonto, und viele Tarife begrenzen die Zahl der Änderungen pro Monat.
- Einen eigenen MCP Server mit Schreibwerkzeugen. Volle Kontrolle, aber Entwicklungsaufwand.
- Die Google Ads API direkt, mit Skripten, die das Modell schreibt und ausführt.
Ich habe mit einem gehosteten Anbieter angefangen. Nach wenigen Wochen war das monatliche Änderungslimit aufgebraucht. Seitdem nutze ich den Anbieter nur noch zum Lesen und ändere über die API direkt: eigenes Developer Token mit Basic Access, OAuth, Refresh-Token, eine Python-Umgebung mit der offiziellen Google-Ads-Bibliothek. Claude Code schreibt die Skripte, ich gebe frei, das Skript läuft.
Für jemanden ohne Entwicklungshintergrund ist der gehostete Anbieter der realistische Weg. Die Regeln im nächsten Abschnitt gelten für beide Varianten.
Mein Ablauf: Vorschlag, Freigabe, Ausführen, Nachlesen
Jede Änderung am Konto läuft bei mir in vier Schritten ab. Nichts davon ist originell. Es ist einfach das, was jede ernsthafte Änderung an Produktivsystemen braucht.
1. Vorschlag mit konkreter Vorschau. Das Modell beschreibt nicht “ich würde ein paar Negatives setzen”, sondern listet jedes einzelne: welcher Begriff, welche Match-Type, auf welcher Kampagne oder Liste, wie viele insgesamt. Bei Geboten und Budgets steht der alte und der neue Wert daneben.
2. Menschliche Freigabe. Bis ich ausdrücklich zustimme, passiert nichts. Diese Freigabe ist nicht Formsache. Ein paar Beispiele aus unserem Konto:
- Nach einer Suchbegriffsanalyse schlug Claude sieben neue Negatives für die Kampagne zu App-Entwicklungskosten vor, darunter Namen von No-Code-Tools wie
flutterflowoderappsheet. Die habe ich freigegeben. Bewusst nicht als Negative gesetzt haben wirflutterallein: “flutter app entwickeln lassen” kann ein echter Auftrag sein. - Einen anderen vorgeschlagenen Negative-Begriff habe ich abgelehnt, weil wir die Kampagne kurz davor auf exakte Übereinstimmung umgestellt hatten. Der Begriff konnte gar nicht mehr matchen, das Negative wäre nur Ballast gewesen.
- Den Vorschlag, eine Kampagne ohne Conversions nach drei Wochen zu pausieren, habe ich zuerst abgelehnt. Einen Tag später, mit mehr Daten, habe ich zugestimmt.
3. Ausführen, möglichst mit Probelauf. Größere Änderungen laufen bei mir als Skript mit zwei Modi: --dry-run zeigt, was passieren würde, --apply führt es aus. Der Probelauf ist die Vorschau aus Schritt 1, nur maschinenlesbar.
Ein Detail am Rande: Als ich im September Geo-Ziele, Gebote und Gebotsstrategie für zwei Kampagnen in einem Schritt ändern wollte, hat der Auto-Modus von Claude Code den Schreibzugriff von sich aus blockiert. Begründung: eine Aktion mit echten finanziellen Folgen. Das Skript lag danach fertig im Repository und lief erst nach meiner ausdrücklichen Freigabe. Genau so sollte es sein.
4. Nachlesen statt der API glauben. Nach jeder Änderung fragt das Modell den tatsächlichen Zustand des Kontos ab und vergleicht ihn mit dem Ziel. Nicht die Antwort der API zählt, sondern was danach im Konto steht. Warum das kein übertriebener Ordnungssinn ist, zeigt der nächste Abschnitt.
Der stille Fehlschlag: Wenn die API “Erfolg” meldet und nichts passiert
Beim Wechsel zweier Kampagnen von “Klicks maximieren” auf manuelle CPC-Gebote meldete das Skript für beide Kampagnen “OK”. Beim Nachlesen standen beide weiterhin auf der alten Gebotsstrategie. Die API hatte eine Änderung ohne Inhalt angenommen und mit Erfolg quittiert.
Die Ursache lag in der sogenannten Field Mask. Bei Update-Aufrufen gibt man der Google Ads API mit, welche Felder sich ändern sollen. Die Hilfsfunktion der Python-Bibliothek erzeugt diese Liste automatisch, indem sie das neue Objekt mit einem leeren vergleicht. Der Wert, den wir setzen wollten (enhanced_cpc_enabled = False), ist aber genau der Standardwert. Die Funktion fand also keinen Unterschied, schickte eine leere Liste, und Google hat eine leere Änderung erfolgreich ausgeführt.
Der zweite Versuch mit dem Pfad manual_cpc scheiterte mit einer Fehlermeldung, weil die API einzelne Unterfelder verlangt. Funktioniert hat erst der explizite Pfad:
campaign.manual_cpc.enhanced_cpc_enabled = False
operation.update_mask.paths.append("manual_cpc.enhanced_cpc_enabled")Ohne das Nachlesen hätte ich angenommen, die Umstellung sei erledigt, und mich Tage später über das Verhalten der Kampagnen gewundert. Ein Modell, das der API-Antwort vertraut, hätte mir sogar noch eine saubere Erfolgsmeldung formuliert. Seitdem gilt im Skript die Regel: nach jedem Schreibvorgang den Zustand abfragen und vergleichen.
Was auch über die API nicht geht
Ein paar Dinge lassen sich weder per MCP noch per API ändern. In unserem Konto waren das zwei Conversion-Aktionen aus einer früheren Smart-Kampagne, die noch als primäre Conversion zählten. Die API antwortete auf jeden Änderungsversuch mit:
Mutates are not allowed for the requested resource.Conversion-Aktionen aus Smart-Kampagnen sind schreibgeschützt, auch wenn die Smart-Kampagne selbst längst gelöscht ist. Sie lassen sich nur in der Weboberfläche umstellen. Das ist kein Randthema: Wer später auf eine Smart-Bidding-Strategie wie “Conversions maximieren” wechselt, lässt Google gegen diese Aktionen optimieren, wenn er sie nicht vorher bereinigt. Ein Agent kann das Problem finden. Beheben muss es ein Mensch.
Sicherheit: Ein Sprachmodell mit Zugriff auf Werbebudget
Wer einem Modell Schreibrechte auf ein Werbekonto gibt, gibt ihm die Möglichkeit, Geld auszugeben. Das verdient mehr als einen beruhigenden Satz.
Minimale Rechte. Das Token nur für das eine Konto nutzen, das bearbeitet werden soll. Neue Abläufe erst an einem Testkonto ausprobieren. Bei gehosteten Anbietern nachsehen, welche Schreibwerkzeuge überhaupt freigeschaltet sind, und nicht benötigte abschalten. Was es als Werkzeug nicht gibt, kann das Modell auch nicht falsch benutzen.
Prompt Injection über Kontodaten. Suchbegriffe sind Text, den fremde Menschen in Google eingetippt haben. Anzeigentexte, Landingpage-Inhalte und Kommentare in Tabellen können ebenfalls von Dritten stammen. All das landet im Kontext des Modells. Ein Suchbegriff, der wie eine Anweisung formuliert ist, ist unwahrscheinlich, aber nicht unmöglich. Deshalb gilt: Daten aus dem Konto sind Daten, keine Befehle, und keine Änderung läuft ohne menschliche Freigabe.
Fehlinterpretationen. Modelle verwechseln Kennzahlen, rechnen mit falschen Zeiträumen oder ziehen aus drei Klicks weitreichende Schlüsse. Bei uns sah ein erster Plan im September vor, eine Kampagne wegen null Conversions zu pausieren. Die Daten stammten aber aus einer Phase, in der wir die Kampagne auf Österreich beschränkt hatten. Den Fehlschluss haben wir vor der Ausführung korrigiert. Mehr zu diesem Fehlerbild im Artikel über KI-Halluzinationen im Unternehmen.
Stille Schäden bei Negatives. Ein zu breites Negative Keyword blockiert gute Anfragen, und man sieht es nicht. Es fehlen einfach Impressionen. Deshalb prüfe ich bei jedem vorgeschlagenen Negative, welche echten Kaufanfragen es mit abschneiden würde.
Obergrenzen und Protokoll. Kein einzelner Befehl sollte Hunderte Objekte ändern können. Und jede Änderung gehört in ein Protokoll: was, wann, warum, wer hat freigegeben. Bei uns ist das eine Markdown-Datei im Repository, die nach jeder Sitzung aktualisiert wird. Unspektakulär, aber nach sechs Wochen weiß man sonst nicht mehr, warum ein Gebot auf 3,50 Euro steht.
Google Ads MCP, Google Ads Scripts oder die API direkt
| MCP mit Claude | Google Ads Scripts | Google Ads API direkt | |
|---|---|---|---|
| Arbeitsweise | Im Gespräch, nach Bedarf | Zeitgesteuert, immer gleich | Programmiert, eingebunden |
| Gut für | Analyse und freigegebene Änderungen | Wiederkehrende Regeln | Eigene Software, Stapeländerungen |
| Mensch beteiligt | Ja, bei jeder Änderung | Nein, läuft unbeaufsichtigt | Je nach Umsetzung |
| Aufwand | Gering beim Lesen | Mittel (JavaScript) | Hoch |
| Schwäche | Keine unbeaufsichtigte Automatisierung | Keine Flexibilität im Gespräch | Verantwortung liegt komplett bei dir |
MCP passt, wenn ein Mensch bei jeder Änderung dabei ist und Fragen spontan entstehen. Google Ads Scripts passen für Regeln, die jeden Morgen gleich laufen sollen, zum Beispiel eine Benachrichtigung, wenn eine Kampagne ihr Budget vor Mittag verbraucht. Die API direkt lohnt sich, wenn man ohnehin Code schreibt oder viele Änderungen in einem Durchgang braucht. In der Praxis mische ich: lesen und diskutieren im Chat, ändern per Skript mit Probelauf.
Wo die Grenzen liegen
Ein Google Ads MCP macht die mechanische Arbeit schneller. Suchbegriffe sichten, Negative-Listen entwerfen, Gebotsänderungen vorbereiten, Kontozustand prüfen. Die Entscheidungen macht er nicht besser. Ob ein steigender CPC an einem schlechten Keyword liegt, an der Saison oder an einem neuen Mitbewerber, muss weiterhin jemand beurteilen, der das Geschäft kennt.
Autonome Kontosteuerung ist 2026 keine gute Idee, zumindest nicht für ein Konto, in dem echtes Geld steckt. Realistisch ist assistierte Steuerung: Das Modell analysiert und schlägt vor, der Mensch gibt frei, das System prüft nach.
Wenn du einen solchen Ablauf für dein eigenes Konto oder für Kundenkonten aufsetzen willst, mit sauberer Rechtevergabe, Probelauf und Protokoll, ist das ein typisches Projekt für unsere KI-Automatisierung.
Häufige Fragen zu Google Ads MCP
Kann der offizielle Google Ads MCP Server Kampagnen ändern? Nein. Der Server von Google ist ausdrücklich nur lesend. Er führt GAQL-Abfragen aus, liefert Metadaten und listet erreichbare Konten. Pausieren, Gebote ändern oder Negatives setzen geht nur über andere MCP Server mit Schreibfunktion oder über die Google Ads API direkt.
Was brauche ich, um Google Ads mit Claude zu verbinden? Ein Google-Cloud-Projekt mit aktivierter Google Ads API, einen Developer Token mit mindestens Explorer-Zugriff, OAuth-Zugangsdaten und einen Eintrag in der MCP-Konfiguration von Claude Desktop oder Claude Code. Bei Zugriff über ein Verwaltungskonto zusätzlich dessen Kundennummer.
Ist es sicher, einer KI Schreibzugriff auf Google Ads zu geben? Nur mit Leitplanken: minimale Rechte, Test am Testkonto, eine konkrete Vorschau jeder Änderung, menschliche Freigabe, Nachlesen nach dem Schreiben und ein Änderungsprotokoll. Ohne Freigabeschritt sollte kein Modell ein Konto mit echtem Budget verändern.
Warum sollte man nach einer Änderung den Kontozustand nachlesen? Weil die Google Ads API Änderungen ohne Inhalt als Erfolg bestätigen kann, etwa bei einer leeren Field Mask. Die Antwort sagt dann “OK”, im Konto hat sich aber nichts geändert. Nur eine Abfrage nach dem Schreiben zeigt den echten Zustand.
Lohnt sich ein Google Ads MCP für kleine Konten? Nötig ist er für ein Konto mit ein oder zwei Kampagnen nicht, die Weboberfläche reicht. Er spart Zeit, wenn man oft nachsieht, regelmäßig Suchbegriffe analysiert oder mehrere Kundenkonten betreut.
