Google Ads MCP Server: Was „Read-Only" für Media-Teams bedeutet

Wer schon einmal ein Monday-Morning-Pacing-Review durchgeführt hat, kennt das Bild: drei Analysten, sechs Tabs der Google Ads UI und ein Slack-Kanal voller „Kannst du das mal für mich ziehen?"-Anfragen. Googles neuer Ads MCP Server zielt genau auf diesen Workflow ab. Für Platform Leads lautet die Frage nicht, ob man ihn sich anschauen sollte, sondern wo der Agent-Zugriff im Stack verankert sein muss, bevor ihn jemand über ein Wochenende einfach verdrahtet.

Das Problem

Jedes Performance-Team, mit dem ich je gearbeitet habe, baut letztendlich denselben Haufen an Skripten. Eines zieht Kampagnen-Metriken. Ein anderes verknüpft Budgetdaten. Ein drittes parst GAQL-Responses in eine Form, die das BI-Tool versteht. Der Klebecode verottet. Auth-Tokens laufen zu ungünstigen Zeiten ab. Ein Junior-Analyst erbt 400 Zeilen Python, die niemand anfassen will.

Genau diese operative Realität adressiert das Model Context Protocol. Wie ContentGrip berichtete, hat Google einen Integrationsleitfaden für einen Ads MCP Server veröffentlicht, der als standardisierte Brücke zur Google Ads API fungiert und dafür ausgelegt ist, benutzerdefinierten Klebecode für Authentifizierung, Datenabruf und Parsing zu reduzieren. MCP selbst ist als offener Standard positioniert, der es großen Sprachmodellen ermöglicht, über eine definierte Tool-Schnittstelle mit externen Daten und Anwendungen zu interagieren.

In Produktionsbegriffen ist das eine andere Art von Integration als das, was die meisten Teams heute ausliefern. Anstatt einen maßgeschneiderten Connector pro Workflow zu schreiben, entdeckt ein AI-Host eine feste Menge an Tools, ruft diese auf und erhält strukturierte Ergebnisse zurück. Der Server übernimmt OAuth 2.0 oder Service-Account-Auth, Transport und Schema. Der Agent übernimmt die Frage.

Die entscheidende Einschränkung: Die Schnittstelle zu Ihren Ad-Accounts ist nicht mehr nur die Plattform-UI plus ein selbst gebauter ETL-Job. Es ist eine Tool-Oberfläche, die jeder kompatible Agent aufrufen kann – gesteuert durch das Berechtigungsmodell, das Sie dahinterschalten. Das klingt abstrakt, bis man bemerkt, dass ein einziger falsch konfigurierter Service-Account einem internen Assistenten ermöglichen könnte, jeden Brand innerhalb einer Holding-Company abzufragen.

Produktionsvorfälle, die ich in Fintech- und iGaming-Reporting-Stacks gesehen habe, lassen sich fast immer auf zwei Dinge zurückführen: Credential-Sprawl und undokumentierte Skripte. MCP Server lösen beides nicht standardmäßig. Sie verlagern das Problem nur auf eine neue Schicht.

Die Optionen im Überblick

Für ein Performance- oder Platform-Team, das dies abwägt, gibt es realistisch gesehen vier Wege.

Weg eins: Googles Server as-is, lokal deployen. Die Referenzimplementierung ist Python, nutzt stdio-Transport und unterstützt OAuth 2.0 oder Service-Account-Auth. Auf dem Rechner eines Analysten oder einem gemeinsamen Server betreiben, einen kompatiblen Agent darauf richten – fertig. Günstig zum Ausprobieren. Schwer zu steuern. Gut als Proof of Concept, gefährlich als Produktionsmuster, weil kein zentrales Audit darüber existiert, wer was gefragt hat.

Weg zwei: Als gemeinsamer Dienst auf Google Cloud Run deployen. Der Leitfaden erwähnt Cloud Run ausdrücklich als Deployment-Option für die gemeinsame Nutzung durch mehrere Agents oder den Betrieb als Service. Diese Variante beginnt, wie echte Infrastruktur auszusehen: ein Server, zentral verwaltete Credentials, Request-Logs, die man tatsächlich einsehen kann. Der Trade-off: Man hat nun einen langlebigen Service, der dieselbe Sorgfalt benötigt wie jede andere interne API – inklusive Incident-Response, wenn die Ads API einen drosselt.

Weg drei: Bestehendes ETL- und BI-Stack behalten, MCP vorerst ignorieren. Read-only-Diagnosefragen sind bei den meisten reifen Reporting-Setups bereits gelöst. Wenn die Analysten Dashboards haben, die beantworten „Wie läuft Kampagne X?", gewinnt man nicht viel durch das Aufschrauben eines Agents oben drauf. Meine Einschätzung: Das ist die richtige Entscheidung für Teams, deren Engpass die Entscheidungsfindung ist, nicht der Datenabruf.

Weg vier: Eine schlanke interne MCP-Schicht aufbauen, die mehrere Ad-Plattformen kapselt. Google hat einen Server veröffentlicht. Meta wird ebenfalls etwas liefern. Die DSPs auch. Für Agenturen oder Multi-Plattform-Werbetreibende ist das langfristige Spiel eine einheitliche Tool-Oberfläche, die vor Google Ads, der Meta Marketing API und allem anderen, worauf man Geld ausgibt, sitzt. Das ist mehr Aufwand, aber die einzige Version, die über den Release-Rhythmus eines einzelnen Anbieters hinaus skaliert.

Die unbequeme Lesart: Die meisten Teams werden Weg eins wählen, es Innovation nennen und stillschweigend eine Shadow-Integration schaffen, die das Security-Team beim nächsten SOC 2 Audit entdeckt.

Was Performance Marketing wirklich tun sollte

Die pragmatische Abfolge ist wenig glamourös. Beginnen Sie damit, die Fragen zu katalogisieren, die Ihr Team jede Woche an Google Ads stellt. Pacing-Checks. Anomalie-Untersuchungen. Cross-Account-Rollups. Budget-Burn gegenüber Forecast. Ist diese Liste kurz und stabil, ist ein MCP Server ein echter Produktivitätsgewinn. Ist sie lang und chaotisch, haben Sie ein Prozess-Problem, und kein Agent wird Sie retten.

Entscheiden Sie als Nächstes, wo der Agent-Zugriff angesiedelt sein soll. Innerhalb einer internen Analytics-Umgebung mit read-only Service-Accounts ist der risikoärmste Einstieg. Innerhalb eines Agentur-Reporting-Stacks brauchen Sie von Tag eins an eine credential-Isolation pro Kunde. Innerhalb eines kundengerichteten Assistenten müssen Sie über Prompt Injection nachdenken, weil ein Angreifer, der die Nutzereingabe kontrolliert, nun indirekt API-Anfragen steuert.

Die drei Tools, die Google ausliefert, bilden eine vernünftige Ausgangsfläche: list_accessible_customers zur Account-Erkennung, search für GAQL-Abfragen gegen Metriken, Budgets und Status sowie get_resource_metadata zur Inspektion verfügbarer Felder für einen Ressourcentyp wie „campaign". Das reicht aus, um die meisten Diagnosefragen zu beantworten, die ein Account-Team in einer Woche stellt. Es reicht nicht für die Optimierung, weil das aktuelle Release read-only ist.

Betrachten Sie die read-only-Einschränkung als Feature, nicht als Limitierung. Sie ermöglicht es, etwas Nützliches auszuliefern, während Sie die Governance-Kompetenz aufbauen, die Sie brauchen werden, bevor Write-Access hinzukommt. Machen Sie sich mit der Ads API-Dokumentation vertraut, damit die GAQL-Abfragen Ihres Agents nicht versehentlich bei jedem Aufruf sechs Monate historische Daten abrufen.

Fallstricke und Sonderfälle

Einige Dinge werden Sie kalt erwischen. Erstens: OAuth 2.0 versus Service-Account-Auth ist keine reine Konfigurationsentscheidung. Service-Accounts machen die Agent-Automatisierung sauberer, konzentrieren aber den Schadenradius. Ein einziger geleakter Key und ein Angreifer kann jede zugängliche Customer-ID aufzählen.

Zweitens: stdio-Transport ist für die lokale Entwicklung geeignet und für gemeinsame Deployments fragwürdig. Wenn Sie den Cloud-Run-Weg gehen, verstehen Sie, wie Ihr Agent-Host tatsächlich mit dem Server kommuniziert und wo die Trust-Boundary liegt.

Drittens: GAQL ist ausdrucksstark genug, um teure Abfragen zu schreiben. Ein Agent, der hilfsbereit „alle Kampagnen, alle Metriken, alle Datumsbereiche" abruft, weil ein Nutzer eine vage Frage gestellt hat, wird API-Quota verbrennen und Kosten aufblähen. Implementieren Sie Query-Cost-Guardrails, bevor Sie den Assistenten vor Stakeholder stellen.

Viertens: Auditierbarkeit. Wenn ein CMO fragt, warum die Ausgaben seltsam aussehen, und die Antwort lautet „der Agent hat es mir gesagt", brauchen Sie Request-Logs, die eine natürlichsprachliche Frage mit dem exakten GAQL verknüpfen, das ausgeführt wurde. Bauen Sie das von Tag eins ein, oder Sie werden es während eines Incidents rückwärts rekonstruieren müssen.

Fünftens: Multi-Brand- und Agentur-Kontexte. Das Tool list_accessible_customers gibt jeden Account zurück, den ein Credential sehen kann. Das ist praktisch – und genau das, was Sie nicht dem falschen User-Prompt aussetzen wollen.

Die wichtigsten Erkenntnisse

• Googles Ads MCP Server ist read-only, in Python geschrieben, nutzt stdio-Transport und unterstützt OAuth 2.0 oder Service-Account-Auth. Nützlich für Diagnostik, noch nicht für Optimierung.
• Die drei exponierten Tools (list_accessible_customers, search, get_resource_metadata) decken die meisten wöchentlichen Reporting-Fragen eines Account-Teams ab.
• Cloud-Run-Deployment ist der Weg zu einem gesteuerten gemeinsamen Service. Lokales stdio ist ein Prototyp, kein Produktionsmuster.
• Credential-Management, tool-level Berechtigungen und Query-Auditierbarkeit sind jetzt Teil Ihres Media-Ops-Stacks, kein nachträglicher Sicherheitsgedanke.
• Der dauerhafte Vorteil sind nicht schnellere Dashboards. Es geht darum, bessere Measurement-Fragen und Pacing-Logik zu kodieren, die Agents konsistent ausführen können.