Google Ads MCP Server
Provides tools for interacting with the Google Ads API, enabling AI agents to search advertising account data, retrieve metadata about Google Ads resources (e.g. campaigns), and list accessible customer accounts.
Integrates with Google Cloud credentials and APIs, using Application Default Credentials and enabling the Google Ads API in Google Cloud projects to authenticate requests.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@Google Ads MCP Serverwhat Google Ads accounts do I have access to?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Google Ads MCP Server
This repo contains the source code for running an MCP server that interacts with the Google Ads API.
Tools
The server uses the Google Ads API to provide several Tools and Resources for use with LLMs and AI agents.
Tools available
search: Retrieves information about the Google Ads account.get_resource_metadata: Retrieves metadata about a Google Ads API resource type, for example "campaign". This is useful to understand the structure of the data and what fields are available for querying.list_accessible_customers: Returns ids of customers directly accessible by the user authenticating the call.
Configuring and Namespacing Tools
The Google Ads MCP server uses the tools_config.yaml to let you selectively enable or disable individual tools or tool categories (namespaces) and customize their namespace prefixes.
A default tools_config.yaml with all tools enabled is bundled with the package, so the server works out of the box with no extra setup. To customize your installation, the server resolves the configuration in the following order:
An explicit path set via the
GOOGLE_ADS_MCP_TOOLS_CONFIGenvironment variable.A
tools_config.yamlfile in the current working directory.The default
tools_config.yamlbundled with the package.
If an explicitly requested configuration file (via the environment variable) is missing, or any resolved file is invalid, the server raises an error and fails to start.
Configuration Example:
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: trueResources available
discovery-document: Retrieve the Google Ads API discovery document. Provides the discovery document for the latest version of the Google Ads API, which describes the API surface, including resources, methods, and schemas. Host LLMs should access this resource to understand the structure of the Google Ads API and discover available features.metrics: Retrieve information about the metrics available for reporting in the Google Ads API.segments: Retrieve information about the segments available for reporting in the Google Ads API.release-notes: Retrieve the release notes for the latest version of the Google Ads API.
Related MCP server: google-ads-mcp
Notes
The MCP Server will expose your data to the Agent or LLM that you connect to it.
If you have technical issues, please use the GitHub issue tracker.
To help us collect usage data, you will notice an extra header has been added to your API calls: this data is used to improve the product.
Setup instructions
Setup involves the following steps:
Configure Python.
Configure Developer Token.
Enable APIs in your project
Configure Credentials.
Configure your MCP client.
Configure Python
After a version has been published to PyPI, you can run that exact version instead of following the latest repository state:
pipx run --spec "google-ads-mcp==X.Y.Z" google-ads-mcpConfigure Developer Token (Optional)
If your setup requires a developer token, follow the instructions for Obtaining a Developer Token.
Your developer token must have at least Explorer access to query production accounts. New tokens may be automatically upgraded to Explorer access; if not, you can apply through the API Center. See the access levels documentation for details.
If you see the error "The developer token is only approved for use with test accounts", your token does not yet have access to production accounts. See the access levels documentation for how to request the access level you need.
Enable APIs in your project
Follow the instructions to enable the following APIs in your Google Cloud project:
Configure Credentials
Option 1: Using FastMCP OAuth Proxy
The server supports FastMCP's OAuth proxy feature for dynamic user authentication. This is useful when running the server as a web service.
To enable it, set the following environment variables:
GOOGLE_ADS_MCP_OAUTH_CLIENT_ID: Your Google Cloud OAuth 2.0 Client ID.GOOGLE_ADS_MCP_OAUTH_CLIENT_SECRET: Your Google Cloud OAuth 2.0 Client Secret.GOOGLE_ADS_MCP_BASE_URL: (Optional) The base URL where the server is accessible (defaults tohttp://localhost:8080).GOOGLE_ADS_MCP_JWT_SIGNING_KEY: (Optional) Secret key used to sign FastMCP JWT tokens across multiple server instances or deployments.GOOGLE_ADS_MCP_STORAGE_TYPE: (Optional) Storage backend for OAuth state (filetree,redis,firestore, ormemory).GOOGLE_ADS_MCP_STORAGE_PATH: (Optional) Directory path forfiletreepersistent storage.GOOGLE_ADS_MCP_STORAGE_REDIS_URL: (Optional) Redis URL forredispersistent storage.GOOGLE_ADS_MCP_STORAGE_FIRESTORE_PROJECT: (Optional) Google Cloud project forfirestorepersistent storage. Defaults to the project inferred from Application Default Credentials. Setting it selects thefirestorebackend even ifGOOGLE_ADS_MCP_STORAGE_TYPEis unset.GOOGLE_ADS_MCP_STORAGE_FIRESTORE_DATABASE: (Optional) Firestore database name forfirestorepersistent storage. Defaults to(default).GOOGLE_ADS_MCP_STORAGE_ENCRYPTION_KEY: (Optional) Encryption key for stored OAuth tokens.GOOGLE_ADS_MCP_STORAGE_DISABLE_ENCRYPTION: (Optional) Set totrueto disable token encryption.
The redis and firestore backends need their storage library installed
alongside the server: pip install py-key-value-aio[redis] and
pip install google-ads-mcp[firestore] respectively.
Once this is enabled, you can authenticate to the API through your MCP client.
When these variables are set, the server automatically switches to the streamable-http transport (SSE/HTTP) instead of stdio.
You will need to run the server as a separate process and configure your MCP client to connect to the SSE endpoint (e.g., http://localhost:8080/mcp).
Option 2: Configure credentials using Application Default Credentials
Configure your Application Default Credentials (ADC). Make sure the credentials are for a user with access to your Google Ads accounts or properties.
Credentials must include the Google Ads API scope:
https://www.googleapis.com/auth/adwordsCheck out Manage OAuth Clients for how to create an OAuth client.
Here are some sample gcloud commands you might find useful:
Set up ADC using user credentials and an OAuth desktop or web client after downloading the client JSON to
YOUR_CLIENT_JSON_FILE.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_FILESet up ADC using service account impersonation.
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
When the gcloud auth application-default command completes, copy the
PATH_TO_CREDENTIALS_JSON file location printed to the console in the
following message. You will need this for a later step!
Credentials saved to file: [PATH_TO_CREDENTIALS_JSON]Option 3: Configure credentials using the Google Ads API Python client library.
Follow the instructions to setup and configure the Google Ads API Python client library
If you have already done this and have a working google-ads.yaml , you can reuse this file!
In the utils.py file, change get_googleads_client() to use the load_from_storage() method.
Configure your MCP client
Add the server to your MCP client's configuration. Below are examples for popular clients.
Antigravity CLI / Antigravity Code Assist
Install Antigravity CLI or Antigravity Code Assist.
Configure your server. Refer to the docs at https://antigravity.google/docs/mcp for details on setting up MCP servers.
Option 1: Using FastMCP OAuth Proxy (Streamable HTTP)
You can run the server as a separate process and configure your MCP client to connect to the SSE endpoint (e.g.,
http://localhost:8080/mcp). This also allows using FastMCP's OAuth proxy feature for dynamic user authentication.{ "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: the Application Default Credentials method
Replace
PATH_TO_CREDENTIALS_JSONwith the path you copied in the previous step.We also recommend that you add a
GOOGLE_CLOUD_PROJECTattribute to theenvobject. ReplaceYOUR_PROJECT_IDin the following example with the project ID of your Google Cloud project.{ "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: the Python client library method
{ "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" } } } }
Login Customer Id
If your access to the customer account is through a manager account, you will need to add the customer ID of the manager account to the settings file.
See here for details.
The final file will look like this:
{
"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"
}
}
}
}Other MCP clients (Claude Code, Cursor, VS Code, etc.)
The mcpServers block format is the same across all MCP clients. Add the configuration shown above to the appropriate settings file for your client (e.g., ~/.claude/settings.json for Claude Code, .cursor/mcp.json for Cursor, .vscode/mcp.json for VS Code with Copilot).
Deployment to Google Cloud Platform
Instead of hosting this MCP server locally, you can host it on Google Cloud Run or on any other cloud-based infrastructure. This is useful if you want to share the server across different agents or run it as a web service.
Note that this only supports authentication with an OAuth Client ID and Client Secret pair through the OAuth proxy (Option #1 above).
Prerequisites
A Google Cloud project.
The
gcloudCLI installed, authenticated, and active project set.gcloud config set project YOUR_PROJECT_ID
Step 1: Build and Push Docker Image
You can use Cloud Build to build and push the image to Artifact Registry without needing Docker installed locally.
Create a repository in Artifact Registry:
gcloud artifacts repositories create mcp-servers --repository-format=docker --location=us-central1Build and submit the image:
gcloud builds submit --tag us-central1-docker.pkg.dev/YOUR_PROJECT_ID/mcp-servers/google-ads-mcp:latest .Replace
YOUR_PROJECT_IDwith your Google Cloud project ID.
Step 2: Deploy to Google Cloud Run
Make sure to set the required environment variables:
GOOGLE_PROJECT_ID: Your Google Cloud project ID.GOOGLE_ADS_DEVELOPER_TOKEN: (Optional) The developer token you want the MCP server to use (see above).GOOGLE_ADS_MCP_OAUTH_CLIENT_ID: The OAuth Client ID you want the MCP server to use.GOOGLE_ADS_MCP_OAUTH_CLIENT_SECRET: The OAuth Client secret you want the MCP server to use.GOOGLE_ADS_MCP_BASE_URL: The base URL where your MCP server is accessible: this will be automatically assigned by Google Cloud Run after your first deployment. You can update the environment variables after deployment.GOOGLE_ADS_MCP_JWT_SIGNING_KEY: (Recommended for production) Persistent JWT signing key across Cloud Run instances.GOOGLE_ADS_MCP_STORAGE_TYPE: (Recommended for production) Storage backend to persist OAuth tokens across instances. Set it tofirestoreto use Firestore through Application Default Credentials, which needs no VPC connector, or toredisalong withGOOGLE_ADS_MCP_STORAGE_REDIS_URL.Using
firestorerequires three things: build the image with the extra installed (change the Dockerfile touv pip install --system .[firestore]), create a Firestore database in the project, since one is not provisioned automatically, and grant the Cloud Run service accountroles/datastore.user. Note that entries are not expired automatically: the store filters expired entries on read but never deletes them, andexpires_atis written as a string, so a Firestore TTL policy cannot collect them either. Plan on a periodic cleanup job for long-running deployments. Redis expires entries on its own.FASTMCP_HOST: Set this to0.0.0.0to allow FastMCP to accept connections from all IP addresses.GOOGLE_ADS_LOGIN_CUSTOMER_ID: Required if your access to the customer account is through a manager account. Set it to the customer ID of the manager account. See Login Customer Id above for details.
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"Step 3: Configure MCP Client
Once deployed, update your MCP client configuration (refer to the docs at https://antigravity.google/docs/mcp) to use the Cloud Run URL.
{
"mcpServers": {
"google-ads-mcp": {
"httpUrl": "https://your-cloud-run-url.a.run.app/mcp"
}
}
}Deployment to Azure App Service
The existing Dockerfile can be deployed as a Linux custom container to
Azure App Service and connected to Claude as a remote custom connector. See
the Azure App Service deployment guide for the
Azure Container Registry commands, required App Service settings, Google
OAuth callback configuration, and Claude setup.
Try it out
Launch your MCP client. You should see google-ads-mcp listed in the
available servers.
Here are some sample prompts to get you started:
Ask what the server can do:
what can the ads-mcp server do?Ask about customers:
what customers do I have access to?Ask about campaigns
How many active campaigns do I have?How is my campaign performance this week?
Note about Customer ID
Your agent will need and ask for a customer id for most prompts. If you are moving between multiple customers, including the customer ID in the prompt may be simpler.
How many active campaigns do I have for customer id 1234567890Contributing
Contributions welcome! See the Contributing Guide. Project maintainers can find the Trusted Publishing and release procedure in the release guide.
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.
Returns: List[str]: A list of customer IDs.
| 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 declare readOnlyHint=true, which aligns with the description's read-only nature. The description adds value beyond annotations by noting that it returns only directly accessible customershare, implying a permission filter, and that the output is a list of IDs (though this is also in the output schema). It does not contradict 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 concise, with a brief purpose statement and a usage hint, followed by a return type section. It is front-loaded with the key action and avoids unnecessary detail.
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 parameterless tool with a simple output (a list of strings), the description is fully sufficient. It explains what the tool does, when to use it, and what it returns. The output schema already documents the return type, so no additional return detail is needed.
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 has zero parameters, so there is no parameter semantics to clarify. The description correctly focuses on the output and usage context, which is appropriate for a parameterless tool.
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 clearly states it returns IDs of customers directly accessible by the authenticated user, with a specific verb ('Returns') and resource ('customers'). It is distinct from siblings like search_search and metadata_get_resource_metadata, as it lists customer IDs rather than performing search or fetching metadata.
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 tells the agent to use this tool first to discover customer IDs if the user hasn't provided one, and notes that most other tools require a valid customer ID. It does not explicitly mention when not to use it or name alternatives, but the guidance is clear enough for this context.
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'). |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description correctly aligns with that. It adds behavioral context beyond the annotation: field name prefixes ('metrics.' and 'segments.'), the relationship to query construction, and that responses should be cached because they don't change frequently. No contradiction or hidden side effects.
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 well-structured and front-loaded with the core function, followed by usage guidance, a mandatory instruction, and caching advice. There is minor redundancy between the first sentence's 'including compatible metrics and segments' and the later sentence repeating that metrics/segments are returned, but overall every sentence contributes.
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?
The tool is simple (one fully documented parameter, read-only annotation, output schema present), and the description covers what the tool returns, how to use it, why it must be used before `search`, and caching behavior. Nothing an agent needs to call it correctly 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 schema already covers the only parameter fully with a description and example. The description reinforces the example ('campaign', 'ad_group') but does not add much beyond what the schema provides. With 100% schema_description_coverage, 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') with a clear resource ('selectable, filterable, and sortable fields for a specific Google Ads resource') and explicitly mentions metrics and segments. It distinguishes itself from the sibling `search` tool by framing itself as the discovery step before querying.
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 gives explicit when-to-use guidance: 'Use this tool to find out which fields you can select, filter by, or sort by when querying a specific resource.' It also states a hard rule: 'Do not guess fields, you MUST use this tool to discover them before constructing a query for the `search` tool.' This clearly routes an agent to the correct workflow.
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 |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already indicates this is a read operation, and the description adds no behavioral detail beyond that: no mention of pagination, rate limits, result shape, or side effects. 'Fetches data' essentially restates the annotation rather than enriching it.
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 a single concise sentence with no filler and the key verb is front-loaded. It could have packed in more useful detail without becoming bloated, but as written it is appropriately sized for a minimal definition.
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?
Despite a rich schema and an output schema, the description leaves out critical context: why to use this instead of the siblings, what 'search method' means in practice, and any constraints or caveats about the query. For a generic data-fetching tool with six parameters, this is under-specified.
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 description coverage is 100%, so the parameters are already well documented. The description does not add any extra meaning about how parameters like fields, resource, or conditions should be used, so the baseline of 3 applies.
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 ('Fetches') and identifies the resource ('data from the Google Ads API') with a named method ('search method'). It is clear enough to understand the basic operation, but it does not distinguish this tool from the sibling tools customers_list_accessible_customers or metadata_get_resource_metadata, so it earns a 4 rather than a 5.
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 gives no guidance about when to use this tool versus the listed sibling tools, and it does not mention any exclusions or alternative approaches. An agent cannot tell from the description whether to choose this tool or one of its siblings in a given situation.
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.
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
Each tool has a clearly distinct purpose: listing customer IDs, retrieving metadata for a resource, and executing a search query. There is no overlap or ambiguity between them.
All tool names use snake_case with a resource prefix followed by an action (customers_list_accessible_customers, metadata_get_resource_metadata, search_search). The pattern is mostly consistent, though search_search is slightly redundant and the action structures vary a bit.
Three tools is on the low side but reasonable for a focused read-only server that uses a generic search tool to cover many query scenarios. Each tool earns its place, though the surface feels minimal for the breadth of Google Ads.
The tool set covers read-only discovery and querying well, but lacks any create, update, or delete operations. For a Google Ads management server, this is a notable gap, even though the search tool can handle many read queries.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Read-only MCP tools for AI agent discovery, structured resources, and NIULAI information.
Google Ads MCP server — manage campaigns, keywords, and metrics.
Google Ads, Meta Ads & GA4 MCP server - 250+ tools for campaigns, creatives, audiences & reports.
Pay-per-use tool marketplace for AI agents. Search, price-check, and call APIs via MCP.
Related MCP Servers
- AlicenseNot gradedqualityCmaintenanceEnables LLMs to interact with the Google Ads API to retrieve account information, list accessible customers, and query campaign performance. It allows users to manage and analyze Google Ads data through natural language interfaces.Apache 2.0

google-ads-mcpofficial
AlicenseAqualityAmaintenanceMCP server that provides tools and resources for interacting with Google Ads API, enabling search, metadata retrieval, and account management through natural language.3929Apache 2.0- AlicenseNot gradedqualityAmaintenanceEnables LLMs to query Google Ads accounts, search for information, and list accessible customers.Apache 2.0
- AlicenseNot gradedqualityDmaintenanceEnables AI agents and LLMs to interact with Google Ads accounts, allowing search, retrieval of resource metadata, and listing accessible customers via the Google Ads API.Apache 2.0