google-ads-mcp
OfficialGoogle Ads MCP Server
Dieses Repository enthält den Quellcode für einen MCP-Server, der mit der Google Ads API interagiert.
Tools
Der Server verwendet die Google Ads API, um mehrere Tools und Ressourcen für die Verwendung mit LLMs und KI-Agenten bereitzustellen.
Verfügbare Tools
search: Ruft Informationen über das Google Ads-Konto ab.get_resource_metadata: Ruft Metadaten über einen Google Ads API-Ressourcentyp ab, z. B. „campaign“. Dies ist nützlich, um die Struktur der Daten und die verfügbaren Felder für Abfragen zu verstehen.list_accessible_customers: Gibt die IDs der Kunden zurück, auf die der den Aufruf authentifizierende Benutzer direkt zugreifen kann.
Konfigurieren und Namespacing von Tools
Der Google Ads MCP Server verwendet die tools_config.yaml, um Ihnen die selektive Aktivierung oder Deaktivierung einzelner Tools oder Tool-Kategorien (Namespaces) sowie die Anpassung ihrer Namespace-Präfixe zu ermöglichen.
Eine standardmäßige tools_config.yaml mit allen aktivierten Tools ist im Paket enthalten, sodass der Server ohne zusätzliche Einrichtung sofort einsatzbereit ist. Um Ihre Installation anzupassen, löst der Server die Konfiguration in der folgenden Reihenfolge auf:
Ein expliziter Pfad, der über die Umgebungsvariable
GOOGLE_ADS_MCP_TOOLS_CONFIGfestgelegt wurde.Eine
tools_config.yaml-Datei im aktuellen Arbeitsverzeichnis.Die standardmäßige
tools_config.yaml, die im Paket enthalten ist.
Wenn eine explizit angeforderte Konfigurationsdatei (über die Umgebungsvariable) fehlt oder eine aufgelöste Datei ungültig ist, gibt der Server einen Fehler aus und startet nicht.
Konfigurationsbeispiel:
namespaces:
# Option 1: Enable category 'customers' with default prefix -> "customers_list_accessible_customers"
customers: true
# Option 2: Enable category 'search' with a custom prefix -> "query_search"
search: "query"
# Option 3: Fine-grained control over tools in a category
metadata:
enabled: true
prefix: "metadata"
enabled_tools:
- get_resource_metadata: trueVerfügbare Ressourcen
discovery-document: Ruft das Google Ads API Discovery-Dokument ab. Stellt das Discovery-Dokument für die neueste Version der Google Ads API bereit, das die API-Oberfläche einschließlich Ressourcen, Methoden und Schemata beschreibt. Host-LLMs sollten auf diese Ressource zugreifen, um die Struktur der Google Ads API zu verstehen und verfügbare Funktionen zu entdecken.metrics: Ruft Informationen über die für die Berichterstellung in der Google Ads API verfügbaren Metriken ab.segments: Ruft Informationen über die für die Berichterstellung in der Google Ads API verfügbaren Segmente ab.release-notes: Ruft die Versionshinweise für die neueste Version der Google Ads API ab.
Related MCP server: gads
Hinweise
Der MCP Server gibt Ihre Daten an den Agenten oder das LLM weiter, mit dem Sie ihn verbinden.
Bei technischen Problemen nutzen Sie bitte den GitHub Issue Tracker.
Um uns bei der Erfassung von Nutzungsdaten zu helfen, werden Sie einen zusätzlichen Header in Ihren API-Aufrufen bemerken: Diese Daten werden zur Verbesserung des Produkts verwendet.
Einrichtungsanleitung
Die Einrichtung umfasst die folgenden Schritte:
Python konfigurieren.
Entwickler-Token konfigurieren.
APIs in Ihrem Projekt aktivieren.
Anmeldedaten konfigurieren.
Ihren MCP-Client konfigurieren.
Python konfigurieren
Entwickler-Token konfigurieren
Befolgen Sie die Anweisungen zum Erhalten eines Entwickler-Tokens.
Ihr Entwickler-Token muss mindestens über Explorer-Zugriff verfügen, um Produktionskonten abfragen zu können. Neue Token werden möglicherweise automatisch auf Explorer-Zugriff hochgestuft; falls nicht, können Sie über das API Center einen Antrag stellen. Weitere Informationen finden Sie in der Dokumentation zu Zugriffsstufen.
Wenn Sie den Fehler "The developer token is only approved for use with test accounts" sehen, hat Ihr Token noch keinen Zugriff auf Produktionskonten. Informationen zur Beantragung der benötigten Zugriffsstufe finden Sie in der Dokumentation zu Zugriffsstufen.
APIs in Ihrem Projekt aktivieren
Befolgen Sie die Anweisungen, um die folgenden APIs in Ihrem Google Cloud-Projekt zu aktivieren:
Anmeldedaten konfigurieren
Option 1: Verwendung des FastMCP OAuth Proxy
Der Server unterstützt die OAuth-Proxy-Funktion von FastMCP für die dynamische Benutzerauthentifizierung. Dies ist nützlich, wenn der Server als Webdienst ausgeführt wird.
Um dies zu aktivieren, setzen Sie die folgenden Umgebungsvariablen:
GOOGLE_ADS_MCP_OAUTH_CLIENT_ID: Ihre Google Cloud OAuth 2.0-Client-ID.GOOGLE_ADS_MCP_OAUTH_CLIENT_SECRET: Ihr Google Cloud OAuth 2.0-Client-Geheimnis.GOOGLE_ADS_MCP_BASE_URL: (Optional) Die Basis-URL, unter der der Server erreichbar ist (Standardwert:http://localhost:8080).GOOGLE_ADS_MCP_JWT_SIGNING_KEY: (Optional) Geheimer Schlüssel zum Signieren von FastMCP JWT-Tokens über mehrere Serverinstanzen oder Bereitstellungen hinweg.GOOGLE_ADS_MCP_STORAGE_TYPE: (Optional) Speicher-Backend für den OAuth-Status (filetree,redis,firestoreodermemory).GOOGLE_ADS_MCP_STORAGE_PATH: (Optional) Verzeichnispfad für den dauerhaftenfiletree-Speicher.GOOGLE_ADS_MCP_STORAGE_REDIS_URL: (Optional) Redis-URL für den dauerhaftenredis-Speicher.GOOGLE_ADS_MCP_STORAGE_FIRESTORE_PROJECT: (Optional) Google Cloud-Projekt für den dauerhaftenfirestore-Speicher. Standardmäßig wird das aus den Application Default Credentials abgeleitete Projekt verwendet. Die Einstellung wählt dasfirestore-Backend aus, auch wennGOOGLE_ADS_MCP_STORAGE_TYPEnicht gesetzt ist.GOOGLE_ADS_MCP_STORAGE_FIRESTORE_DATABASE: (Optional) Firestore-Datenbankname für den dauerhaftenfirestore-Speicher. Standardwert:(default).GOOGLE_ADS_MCP_STORAGE_ENCRYPTION_KEY: (Optional) Verschlüsselungsschlüssel für gespeicherte OAuth-Tokens.GOOGLE_ADS_MCP_STORAGE_DISABLE_ENCRYPTION: (Optional) Auftruesetzen, um die Token-Verschlüsselung zu deaktivieren.
Die Backends redis und firestore benötigen die Installation ihrer Speicherbibliothek zusammen mit dem Server: pip install py-key-value-aio[redis] bzw. pip install google-ads-mcp[firestore].
Sobald dies aktiviert ist, können Sie sich über Ihren MCP-Client bei der API authentifizieren.
Wenn diese Variablen gesetzt sind, wechselt der Server automatisch zum streamable-http-Transport (SSE/HTTP) anstelle von stdio.
Sie müssen den Server als separaten Prozess ausführen und Ihren MCP-Client so konfigurieren, dass er eine Verbindung zum SSE-Endpunkt herstellt (z. B. http://localhost:8080/mcp).
Option 2: Anmeldedaten mit Application Default Credentials konfigurieren
Konfigurieren Sie Ihre Application Default Credentials (ADC). Stellen Sie sicher, dass die Anmeldedaten für einen Benutzer mit Zugriff auf Ihre Google Ads-Konten oder -Eigenschaften sind.
Die Anmeldedaten müssen den Google Ads API-Bereich enthalten:
https://www.googleapis.com/auth/adwordsInformationen zum Erstellen eines OAuth-Clients finden Sie unter OAuth-Clients verwalten.
Hier sind einige Beispiel-gcloud-Befehle, die Sie nützlich finden könnten:
ADC mit Benutzeranmeldedaten und einem OAuth-Desktop- oder Web-Client einrichten, nachdem Sie das Client-JSON in
YOUR_CLIENT_JSON_FILEheruntergeladen haben.gcloud auth application-default login \ --scopes https://www.googleapis.com/auth/adwords,https://www.googleapis.com/auth/cloud-platform \ --client-id-file=YOUR_CLIENT_JSON_FILEADC mithilfe der Dienstkonto-Impersonierung einrichten.
gcloud auth application-default login \ --impersonate-service-account=SERVICE_ACCOUNT_EMAIL \ --scopes=https://www.googleapis.com/auth/adwords,https://www.googleapis.com/auth/cloud-platform
Wenn der Befehl gcloud auth application-default abgeschlossen ist, kopieren Sie den Speicherort der Datei PATH_TO_CREDENTIALS_JSON, der in der folgenden Nachricht auf der Konsole ausgegeben wird. Sie benötigen dies für einen späteren Schritt!
Credentials saved to file: [PATH_TO_CREDENTIALS_JSON]Option 3: Anmeldedaten mit der Python-Clientbibliothek der Google Ads API konfigurieren.
Befolgen Sie die Anweisungen, um die Python-Clientbibliothek der Google Ads API einzurichten und zu konfigurieren.
Wenn Sie dies bereits getan haben und eine funktionierende google-ads.yaml besitzen, können Sie diese Datei wiederverwenden!
Ändern Sie in der Datei utils.py die Methode get_googleads_client() so, dass sie die Methode load_from_storage() verwendet.
Ihren MCP-Client konfigurieren
Fügen Sie den Server zur Konfiguration Ihres MCP-Clients hinzu. Nachfolgend finden Sie Beispiele für gängige Clients.
Antigravity CLI / Antigravity Code Assist
Installieren Sie Antigravity CLI oder Antigravity Code Assist.
Konfigurieren Sie Ihren Server. Details zur Einrichtung von MCP-Servern finden Sie in der Dokumentation unter https://antigravity.google/docs/mcp.
Option 1: Verwendung des FastMCP OAuth Proxy (Streamable HTTP)
Sie können den Server als separaten Prozess ausführen und Ihren MCP-Client so konfigurieren, dass er eine Verbindung zum SSE-Endpunkt herstellt (z. B.
http://localhost:8080/mcp). Dies ermöglicht auch die Verwendung der OAuth-Proxy-Funktion von FastMCP für die dynamische Benutzerauthentifizierung.{ "mcpServers": { "google-ads-mcp": { "httpUrl":"http://localhost:8080/mcp", "env": { "GOOGLE_PROJECT_ID": "YOUR_PROJECT_ID", "GOOGLE_ADS_DEVELOPER_TOKEN": "YOUR_DEVELOPER_TOKEN" } } } }Option 2: Die Methode mit Application Default Credentials
Ersetzen Sie
PATH_TO_CREDENTIALS_JSONdurch den Pfad, den Sie im vorherigen Schritt kopiert haben.Wir empfehlen außerdem, dem Objekt
envein AttributGOOGLE_CLOUD_PROJECThinzuzufügen. Ersetzen SieYOUR_PROJECT_IDim folgenden Beispiel durch die Projekt-ID Ihres Google Cloud-Projekts.{ "mcpServers": { "google-ads-mcp": { "command": "pipx", "args": [ "run", "--spec", "git+https://github.com/googleads/google-ads-mcp.git", "google-ads-mcp" ], "env": { "GOOGLE_APPLICATION_CREDENTIALS": "PATH_TO_CREDENTIALS_JSON", "GOOGLE_PROJECT_ID": "YOUR_PROJECT_ID", "GOOGLE_ADS_DEVELOPER_TOKEN": "YOUR_DEVELOPER_TOKEN" } } } }Option 3: Die Methode mit der Python-Clientbibliothek
{ "mcpServers": { "google-ads-mcp": { "command": "pipx", "args": [ "run", "--spec", "git+https://github.com/googleads/google-ads-mcp.git", "google-ads-mcp" ], "env": { "GOOGLE_PROJECT_ID": "YOUR_PROJECT_ID", "GOOGLE_ADS_DEVELOPER_TOKEN": "YOUR_DEVELOPER_TOKEN" } } } }
Kunden-ID für die Anmeldung
Wenn Ihr Zugriff auf das Kundenkonto über ein Verwaltungskonto erfolgt, müssen Sie die Kunden-ID des Verwaltungskontos zur Einstellungsdatei hinzufügen.
Details finden Sie hier.
Die endgültige Datei sieht wie folgt aus:
{
"mcpServers": {
"google-ads-mcp": {
"command": "pipx",
"args": [
"run",
"--spec",
"git+https://github.com/googleads/google-ads-mcp.git",
"google-ads-mcp"
],
"env": {
"GOOGLE_APPLICATION_CREDENTIALS": "PATH_TO_CREDENTIALS_JSON",
"GOOGLE_PROJECT_ID": "YOUR_PROJECT_ID",
"GOOGLE_ADS_DEVELOPER_TOKEN": "YOUR_DEVELOPER_TOKEN",
"GOOGLE_ADS_LOGIN_CUSTOMER_ID": "YOUR_MANAGER_CUSTOMER_ID"
}
}
}
}Andere MCP-Clients (Claude Code, Cursor, VS Code usw.)
Das Format des Blocks mcpServers ist bei allen MCP-Clients gleich. Fügen Sie die oben gezeigte Konfiguration zur entsprechenden Einstellungsdatei Ihres Clients hinzu (z. B. ~/.claude/settings.json für Claude Code, .cursor/mcp.json für Cursor, .vscode/mcp.json für VS Code mit Copilot).
Bereitstellung auf Google Cloud Platform
Anstatt diesen MCP-Server lokal zu hosten, können Sie ihn auf Google Cloud Run oder einer anderen cloudbasierten Infrastruktur hosten. Dies ist nützlich, wenn Sie den Server für verschiedene Agenten freigeben oder als Webdienst ausführen möchten.
Beachten Sie, dass dies nur die Authentifizierung mit einem OAuth-Client-ID- und Client-Geheimnis-Paar über den OAuth-Proxy (Option #1 oben) unterstützt.
Voraussetzungen
Ein Google Cloud-Projekt.
Die
gcloudCLI ist installiert, authentifiziert und das aktive Projekt ist gesetzt.gcloud config set project YOUR_PROJECT_ID
Schritt 1: Docker-Image erstellen und pushen
Sie können Cloud Build verwenden, um das Image zu erstellen und in Artifact Registry zu pushen, ohne dass Docker lokal installiert sein muss.
Erstellen Sie ein Repository in Artifact Registry:
gcloud artifacts repositories create mcp-servers --repository-format=docker --location=us-central1Erstellen und übermitteln Sie das Image:
gcloud builds submit --tag us-central1-docker.pkg.dev/YOUR_PROJECT_ID/mcp-servers/google-ads-mcp:latest .Ersetzen Sie
YOUR_PROJECT_IDdurch Ihre Google Cloud-Projekt-ID.
Schritt 2: Auf Google Cloud Run bereitstellen
Stellen Sie sicher, dass die erforderlichen Umgebungsvariablen gesetzt sind:
GOOGLE_PROJECT_ID: Ihre Google Cloud-Projekt-ID.GOOGLE_ADS_DEVELOPER_TOKEN: Das Entwickler-Token, das der MCP-Server verwenden soll (siehe oben).GOOGLE_ADS_MCP_OAUTH_CLIENT_ID: Die OAuth-Client-ID, die der MCP-Server verwenden soll.GOOGLE_ADS_MCP_OAUTH_CLIENT_SECRET: Das OAuth-Client-Geheimnis, das der MCP-Server verwenden soll.GOOGLE_ADS_MCP_BASE_URL: Die Basis-URL, unter der Ihr MCP-Server erreichbar ist: Diese wird nach der ersten Bereitstellung automatisch von Google Cloud Run zugewiesen. Sie können die Umgebungsvariablen nach der Bereitstellung aktualisieren.GOOGLE_ADS_MCP_JWT_SIGNING_KEY: (Empfohlen für die Produktion) Persistenter JWT-Signierschlüssel über Cloud Run-Instanzen hinweg.GOOGLE_ADS_MCP_STORAGE_TYPE: (Empfohlen für die Produktion) Speicher-Backend zum Persistieren von OAuth-Tokens über Instanzen hinweg. Setzen Sie es auffirestore, um Firestore über die Standardanmeldeinformationen der Anwendung zu verwenden, was keinen VPC-Connector benötigt, oder aufrediszusammen mitGOOGLE_ADS_MCP_STORAGE_REDIS_URL.Die Verwendung von
firestoreerfordert drei Dinge: Erstellen Sie das Image mit der zusätzlichen Installation (ändern Sie die Dockerfile inuv pip install --system .[firestore]), erstellen Sie eine Firestore-Datenbank im Projekt, da diese nicht automatisch bereitgestellt wird, und gewähren Sie dem Cloud Run-Dienstkonto die Rolleroles/datastore.user. Beachten Sie, dass Einträge nicht automatisch ablaufen: Der Speicher filtert abgelaufene Einträge beim Lesen, löscht sie jedoch nie, undexpires_atwird als Zeichenfolge geschrieben, sodass eine Firestore-TTL-Richtlinie sie ebenfalls nicht einsammeln kann. Planen Sie für langlebige Bereitstellungen einen regelmäßigen Bereinigungsauftrag ein. Redis läuft Einträge von selbst ab.FASTMCP_HOST: Setzen Sie dies auf0.0.0.0, um FastMCP zu erlauben, Verbindungen von allen IP-Adressen zu akzeptieren.
gcloud run deploy google-ads-mcp \
--image us-central1-docker.pkg.dev/YOUR_PROJECT_ID/mcp-servers/google-ads-mcp:latest \
--platform managed \
--region us-central1 \
--allow-unauthenticated \
--set-env-vars="GOOGLE_PROJECT_ID=YOUR_PROJECT_ID,GOOGLE_ADS_DEVELOPER_TOKEN=YOUR_DEVELOPER_TOKEN,GOOGLE_ADS_MCP_OAUTH_CLIENT_ID=YOUR_CLIENT_ID,GOOGLE_ADS_MCP_OAUTH_CLIENT_SECRET=YOUR_CLIENT_SECRET,GOOGLE_ADS_MCP_BASE_URL=YOUR_BASE_URL,GOOGLE_ADS_MCP_JWT_SIGNING_KEY=YOUR_JWT_SIGNING_KEY,GOOGLE_ADS_MCP_STORAGE_TYPE=firestore,FASTMCP_HOST=0.0.0.0"Schritt 3: MCP-Client konfigurieren
Aktualisieren Sie nach der Bereitstellung Ihre MCP-Client-Konfiguration (siehe die Dokumentation unter https://antigravity.google/docs/mcp), um die Cloud Run-URL zu verwenden.
{
"mcpServers": {
"google-ads-mcp": {
"httpUrl": "https://your-cloud-run-url.a.run.app/mcp"
}
}
}Testen Sie es
Starten Sie Ihren MCP-Client. Sie sollten google-ads-mcp in der Liste der verfügbaren Server sehen.
Hier sind einige Beispielaufforderungen für den Einstieg:
Fragen Sie, was der Server kann:
what can the ads-mcp server do?Fragen Sie nach Kunden:
what customers do I have access to?Fragen Sie nach Kampagnen:
How many active campaigns do I have?How is my campaign performance this week?
Hinweis zur Kunden-ID
Ihr Agent wird für die meisten Aufforderungen eine Kunden-ID benötigen und danach fragen. Wenn Sie zwischen mehreren Kunden wechseln, kann es einfacher sein, die Kunden-ID in die Aufforderung aufzunehmen.
How many active campaigns do I have for customer id 1234567890Mitwirken
Beiträge sind willkommen! Siehe den Leitfaden zum Mitwirken.
Available Tools
3 toolscustomers_list_accessible_customersCustomers List Accessible CustomersARead-only
Returns ids of customers directly accessible by the user authenticating the call.
Use this tool first to discover available customer IDs if the user hasn't provided one. Most other tools require a valid customer ID as input.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so safety is covered by structured data. The description still adds genuine behavioral context by clarifying that results are scoped to the authenticated caller's direct access, which matters for interpreting the returned IDs. It says nothing about pagination or result ordering, so it is not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, no filler, and the primary guidance ('use this tool first') is front-loaded in the second sentence before the reason. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter discovery tool with an output schema already covering the return shape, the description supplies everything needed: what it returns, its auth scope, and its role as the entry point before other customer-ID-dependent tools. Nothing required for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, which is the baseline-4 case; there is no parameter behavior left to explain. The description correctly implies the call is fully parameterless and derived from the caller's auth context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource (returns IDs of accessible customers) and adds the scoping constraint that access is limited to the authenticating user. It does not explicitly name or contrast the siblings (metadata_get_resource_metadata, search_search), so it is clear but not fully differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states exactly when to reach for this tool: 'Use this tool first to discover available customer IDs if the user hasn't provided one,' plus the rationale that most other tools need a valid customer ID. The sequencing and trigger condition are unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
metadata_get_resource_metadataMetadata Get Resource MetadataARead-only
Retrieves the selectable, filterable, and sortable fields for a specific Google Ads resource, including compatible metrics and segments.
Use this tool to find out which fields you can select, filter by, or sort by when querying a specific resource (e.g., 'campaign', 'ad_group'). This tool also returns metrics and segments that can be selected with the resource. Their names start with 'metrics.' and 'segments.' respectively.
Do not guess fields, you MUST use this tool to discover them before constructing a query for the
search tool.
The responses of this tool should be cached, as they don't change frequently.
| Name | Required | Description | Default |
|---|---|---|---|
| resource_name | Yes | The name of the Google Ads resource (e.g., 'campaign', 'ad_group'). | |
| login_customer_id | No | Optional manager customer ID to use as the login-customer-id header. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true already covers the safety profile, and the description complements it by disclosing the response contents (fields, metrics, segments) and the naming convention for metrics/segments. It also adds an operational trait: 'responses ... should be cached, as they don't change frequently'. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and adds concise, actionable guidance. There is minor redundancy: the first sentence says 'including compatible metrics and segments' and the third sentence repeats that metrics and segments can be selected. Still, it is well-structured and every section adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a metadata-lookup tool with an output schema and readOnlyHint annotation, the description covers everything an agent needs: what the tool returns, naming conventions, mandatory usage before querying, and caching guidance. No significant gaps remain for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes both parameters comprehensively (100% coverage), so the description need not repeat them. It adds a small amount of extra context with examples like 'campaign', 'ad_group', but this does not significantly exceed what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Retrieves') and names a clear resource: the selectable, filterable, and sortable fields for a Google Ads resource, including metrics and segments. This clearly distinguishes the tool from the siblings: search_search executes queries, while this tool provides metadata for building them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: before constructing a query for the `search` tool, and it warns 'Do not guess fields, you MUST use this tool to discover them'. This gives the agent an unambiguous directive and contextual placement relative to the sibling search tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_searchSearch SearchCRead-only
Fetches data from the Google Ads API using the search method
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | The maximum number of rows to return | |
| fields | Yes | The fields to fetch | |
| resource | Yes | The resource to return fields from | |
| orderings | No | How the data is ordered | |
| conditions | No | List of conditions to filter the data, combined using AND clauses | |
| customer_id | Yes | The id of the customer | |
| login_customer_id | No | Optional manager customer ID to use as the login-customer-id header. |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The only annotation is readOnlyHint=true, which already tells the agent this is a safe read operation. The description adds no additional behavioral context—nothing about pagination, limits, error handling, or response format. It fails to enrich the annotation-provided information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only one sentence and is technically concise, but it is under-specified to the point of being nearly useless. It does not front-load critical information or structure the content in a way that helps an agent understand the tool's scope. The brevity is a deficiency, not a virtue.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a 7-parameter tool with 3 required parameters, yet the description provides no context about what the tool actually accomplishes beyond a generic 'search'. It lacks any explanation of the query syntax, the relationship between fields and resource, or expected output. Given the complexity, the description is grossly incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, meaning all parameters have descriptions in the schema. The description adds no extra meaning beyond what the schema already provides, so the baseline of 3 applies. It does not compensate with any additional clarifications about parameter relationships or formatting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a verb ('Fetches data') and a resource ('Google Ads API') but is extremely vague about what kind of data or which resources are searchable. It does not differentiate from sibling tools like metadata_get_resource_metadata or customers_list_accessible_customers, making it unclear when this tool is the right choice.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus the siblings. No mention of alternatives, exclusions, or prerequisites. An agent has to infer that this is a general search tool, but the description gives no contextual hints about when it should be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
2 tool updates
v0.0.4- Changed
metadata_get_resource_metadata1 field changed- added
Input schema / properties / login_customer_idAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Optional manager customer ID to use as the login-customer-id header." +}
- Changed
search_search1 field changed- added
Input schema / properties / login_customer_idAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Optional manager customer ID to use as the login-customer-id header." +}
3 tool updates
v0.0.3- First observed
customers_list_accessible_customers - First observed
metadata_get_resource_metadata - First observed
search_search
TDQS
Scored across 3 tools
The three tools have clearly distinct purposes: discovering customer IDs, retrieving resource metadata, and executing queries. There is no overlap, though the generic name 'search_search' is slightly vague.
All names use snake_case, but the pattern is inconsistent: 'customers_list_accessible_customers' and 'metadata_get_resource_metadata' include a resource prefix and redundant object, while 'search_search' repeats the verb and omits any prefix.
Three tools is quite thin for the vast Google Ads API, but the search tool is broad enough to cover many query use cases. It's borderline under-scoped for the domain.
The surface is read-only and lacks any mutation, creation, or deletion operations, plus no customer detail retrieval beyond listing IDs. These are significant gaps for a general Google Ads server.
Maintenance
Related MCP Connectors
Google Ads MCP server — manage campaigns, keywords, and metrics.
MCP server for querying and analyzing data from ad platforms, analytics tools, and spreadsheets
Hosted Google Ads MCP server for Claude, ChatGPT and Cursor, with each action switched per account.
Meta Ads and Google Ads MCP server: 250+ tools for Claude, ChatGPT, Cursor and Codex.
Related MCP Servers
- AlicenseAqualityFmaintenanceA read-write MCP server for managing Google Ads campaigns, ad groups, keywords, and ads via natural language.122-
- FlicenseNot gradedqualityDmaintenanceA Google Ads API MCP server that enables searching and listing accessible customers via natural language queries.2-
- AlicenseNot gradedqualityCmaintenanceMCP server for managing Google Ads campaigns through the official Google Ads API, covering accounts, campaigns, budgets, keywords, search terms, and keyword ideas. It provides tools for both reading and mutating live ads data, such as pausing campaigns, updating budgets, and adding keywords.MIT
- AlicenseNot gradedqualityBmaintenanceMCP server for Google Ads API that enables LLMs to search and query Google Ads accounts, retrieve resource metadata, and generate keyword ideas.Apache 2.0