Google Ads API MCP server: how to connect AI agents to your ad account

The Google Ads API MCP server gives AI agents a direct line into your ad account data. Google open-sourced it in October 2025, and it has quickly become the standard way teams connect Google Ads to Claude, Gemini, and other MCP-compatible assistants. This guide covers what the server does, what it still cannot do, how to set it up, and where it is headed.

What is the Google Ads API MCP server

The Model Context Protocol (MCP) is an open standard that lets large language models interact with external data sources and tools through a common interface. The Google Ads MCP server implements that standard on top of the Google Ads API, so an AI assistant can run GAQL queries and pull campaign, keyword, and budget data without custom glue code.

Google describes the server as a standardized bridge between LLMs and the Google Ads API. Instead of writing authentication flows, resource fetchers, and parsers by hand, you register the server with an MCP client and the assistant discovers its tools automatically. The official implementation is written in Python, uses standard input/output transport, and authenticates with OAuth 2.0 or a service account.

The server is open source and available on GitHub. You can run it locally, deploy it to Google Cloud Run, or use a third-party hosted option. For teams that already rely on AI assistants for reporting, this removes the biggest barrier to working with raw ad account data: getting the data out in the first place.

Google's developer blog announced the open-source server in October 2025 as part of a broader push to give AI tools first-class access to advertising data. The announcement positioned MCP as the open standard that lets large language models, including Google Gemini, connect with and act on external systems. That framing matters: Google is treating the server as a supported developer tool, not an experiment, which means it gets maintained, documented, and improved over time.

Why teams are wiring Google Ads to AI agents

Search Engine Land called the October 2025 release a major milestone in bringing AI agents closer to real-world marketing workflows. The logic is simple: ad accounts produce huge amounts of structured data, and LLMs are good at turning that data into analysis, summaries, and recommendations. The missing piece was a clean, secure way to connect the two.

A typical workflow looks like this. A marketer asks the assistant how campaign performance looked this week. The assistant sees the google-ads-mcp search tool, runs a GAQL query against the account, gets the structured rows back, and answers with a human-readable summary. No CSV exports, no dashboard tab-juggling, no manual reporting.

The same pattern scales to audits, budget checks, and creative performance reads. Agencies that manage multiple accounts can connect each one and let agents surface anomalies across the portfolio. For a deeper look at how MCP servers connect to ad platforms generally, see how MCP servers connect AI agents to ad platforms.

What the official server can do today (read-only tools)

The current release of the Google Ads MCP server is strictly read-only. It exposes three tools. list_accessible_customers returns the customer IDs and account names the authenticated user can reach. search executes Google Ads Query Language (GAQL) requests to fetch metrics, budgets, and status fields. get_resource_metadata explains the structure of a resource such as campaign, so the agent knows which fields it can query.

In practical terms, that covers most reporting and analysis needs. You can ask which campaigns are active, how a campaign performed last week, which keywords are eating budget, how spend breaks down by device, or how impression share has moved over time. The interaction loop is request, discovery, execution, context injection, response: the agent picks a tool, the server queries the API, and the results land in the model context window.

A sample prompt shows how direct this is. Ask the assistant for a report of the top spending campaigns split by device category over the last 7 days for account 1234567890, and it translates that request into the right GAQL query, runs it, and formats the result. The server even exposes resource metadata so the agent can learn which fields exist before it writes a query.

Because the server handles authentication and query formatting itself, you do not need to teach the model the Google Ads API. You also do not need to worry about parsing GAQL responses. The server returns structured results that the model can reason over directly.

What the official server cannot do yet

The read-only constraint is the single most important limitation to understand. The official server cannot modify bids, pause campaigns, create assets, or change budgets. Google built the first version for diagnostics and analytics, and it has said future iterations could expand beyond read-only functionality toward AI-driven optimization and campaign management. Search Engine Land's coverage of the open-source release framed it the same way: the initial server targets diagnostics and analytics, with optimization and management left for later versions.

If your goal is full agentic campaign management, the official server is not there yet. Teams that need write access today typically pair the read-only server with separate automation, or use community servers that add mutation capabilities. That said, most high-value use cases for performance marketers are analytical, and the read-only design makes it safe to connect in production from day one.

What you need before setup

Three credentials from the Google Ads developer console cover almost all of the setup. The developer token is your unique 22-character access string. The project ID identifies your Google Cloud project. The OAuth credentials are either a client ID and client secret pair or application default credentials. You also need a Google Ads customer ID with access to the account you want to query.

Before you build anything, check whether you already have API access enabled for the customer account. Google Ads requires a developer token approval process for production, and test accounts work well for early experimentation. For teams new to the Google Ads API, start with a test account, validate your queries, then move to production data.

How to set up the server (local and Cloud Run)

The fastest local setup uses pipx. In your MCP client configuration, usually settings.json or the equivalent for your host, register the server with a command that pulls the package directly from GitHub and passes the environment variables for your project ID and developer token. Most MCP-compatible hosts, including Claude Desktop and Gemini, read this configuration at startup.

The configuration block looks like a standard MCP server entry. The command is pipx run with the git URL for the google-ads-mcp repository, and the env object carries GOOGLE_PROJECT_ID and GOOGLE_ADS_DEVELOPER_TOKEN. Once the host restarts, the assistant can discover the tools and answer questions about the connected accounts.

For teams that want one shared instance, deploy the server to Google Cloud Run. Build the Docker image, push it to Artifact Registry, then deploy with environment variables for the project ID, developer token, OAuth client ID and secret, and base URL. Set FASTMCP_HOST to 0.0.0.0 so the service accepts connections, then point every MCP client at the deployed URL.

Hosting on Cloud Run has a real advantage for agencies: every agent and every user can share the same authorized service instead of each person managing local credentials. It also moves the OAuth dance to the server side, which simplifies onboarding for the rest of the team.

Real use cases for performance marketers and agencies

Weekly performance summaries are the most obvious win. Instead of exporting reports and pasting them into a prompt, the agent pulls the numbers itself and answers in plain language. You can ask for the top spending campaigns by device over the last seven days and get a structured breakdown in seconds.

Budget and spend monitoring is a close second. Ask which campaigns are pacing ahead of budget, which keywords have rising cost per conversion, or how auction insights have shifted for your main competitor terms. The answers come from live account data, not from a stale dashboard snapshot. For the bigger picture on competitor bidding, read our guide to Google Ads competitor research with AI agents.

Agencies can run the same analysis across every client account. With one Cloud Run deployment and per-account authorization, an agent can summarize account health, flag anomalies, and draft client-facing notes. That turns the MCP server into an internal analyst that never sleeps and never misses a week of data.

Creative and landing page reads fit the same workflow. Query impression share, CTR, and conversion data per ad group, then have the agent highlight the creatives that are losing steam before budget is wasted. Combined with the Meta Ads Library API for AI agents, you can cover Google and Meta from the same assistant.

Security and permissions best practices

Start with the principle of least privilege. Create a dedicated Google Cloud service account or OAuth app for the MCP server, grant it access only to the customer IDs it needs, and avoid reusing credentials from other integrations. The read-only nature of the official server limits blast radius, but access control still matters.

Treat the developer token like a production secret. It is a 22-character string that Google can reset if it is leaked, and a leaked token can affect your whole API project. Keep it in environment variables or a secret manager, never in client-side code, and rotate it on a schedule or after team changes.

For shared Cloud Run deployments, add an authentication layer at the service boundary. Google Cloud Run supports IAM-based access, and you can require a token or API key before the MCP endpoint responds. Review the audit logs periodically to see which accounts are being queried and how often. If you are building a full ad intelligence stack, our guide to an MCP-powered competitive ad intelligence stack covers the architecture in more depth.

Alternatives and what's next

The official server is not the only option. Community projects such as cohnen/mcp-google-ads connect Google Ads to Claude and Cursor with a conversational interface. Third-party services like Markifact offer safe write access on top of the same protocol, and directories such as mcpmarket list several Google Ads servers with different capabilities. Evaluate them on read versus write support, hosted versus self-hosted, and how they handle OAuth.

Google has hinted that write capabilities are coming. The October 2025 announcement positioned the read-only version as the first step, and the developer docs now describe deployment options for production workloads, which usually precedes broader feature sets. When mutation tools arrive, agents will be able to pause underperforming campaigns or adjust bids under human supervision.

The near-term play for most teams is unchanged: use the read-only server to make account data accessible to AI assistants, build the analysis workflows that actually move decisions, and keep humans in the loop for anything that changes money. The infrastructure is finally boring enough to build on. If you want to see how ad intelligence fits into your AI workspace, start with our adextract MCP server announcement.

The bottom line is that the Google Ads API MCP server turns a previously tedious integration into a configuration step. Connect it, ask questions in natural language, and let agents do the reporting legwork. That is a small change technically and a large one for how performance teams spend their time.

Frequently asked questions