Google Ads MCP: what the official server does, how to set it up, and where it stops

Google Ads is where a mistake costs real money in real time, which is exactly why Google's official MCP server is read-only. That is the right design, and it still leaves a lot on the table: an agent that can query every account in an MCC and answer "what is bleeding budget this week" is worth more than most dashboards.

We run Google Ads for ourselves through MCP and have built the write side separately. This guide covers the official server, the prerequisites that trip people up, what to do with it, and how we handle changes. Client setup is in our guides for Claude Code, Cursor and Claude Desktop.

The official server

Google publishes the Google Ads MCP server in its googleads GitHub organisation. It exposes a small set of tools:

• list accessible customers: the accounts the credential can see.
• search: run a GAQL query against a customer ID and get rows back.
• get resource metadata: fields, metrics and segments for a resource, so the agent can write valid queries.

GAQL, the Google Ads Query Language, is SQL-like and the model is good at it once it has the metadata. Everything you can see in the UI's reports is reachable.

Prerequisites

This is where most setups stall, so in order:

1. A developer token. Created in a Google Ads manager account under API Center. New tokens start at test access, which only works against test accounts. To query real accounts you need Basic access or above, which requires an application to Google describing your use. Plan for a few days.

2. Credentials. Either OAuth as a user (a Google Cloud OAuth client, plus a refresh token generated once) or a service account with domain-wide delegation for Google Workspace accounts. OAuth is quicker for one person; a service account is better for a team.

3. Customer IDs. Ten-digit IDs of the accounts to query. If you access client accounts through a manager account (MCC), you also need the manager's ID as the login customer ID.

4. The API enabled in the Google Cloud project that holds the OAuth client.

The server takes these as environment variables or a config file; the README spells out the names.

Setup in Claude Code

With the prerequisites in place:

claude mcp add --transport stdio google-ads \
  -e GOOGLE_ADS_DEVELOPER_TOKEN=... \
  -e GOOGLE_ADS_LOGIN_CUSTOMER_ID=1234567890 \
  -e GOOGLE_ADS_CREDENTIALS_PATH=/path/to/credentials.json \
  -- <command that starts the server>

Start a session, run /mcp to confirm it connected, and ask it to list accessible customers. If that works, everything works.

What to ask

The questions that justify the setup:

• Wasted spend. "Search terms in the last 30 days with more than 20 clicks and zero conversions, by campaign. Propose negatives."
• Pacing. "For each campaign, month-to-date spend against monthly budget, and projected end-of-month spend at the current daily rate."
• Quality. "Keywords with quality score 5 or below and more than 100 impressions, with their landing pages."
• Change history. "What changed in this account in the last 14 days, by whom?"
• Cross-account. "Across all accounts in the MCC, CPA by campaign type this quarter versus last."

Packaged as a skill, that becomes a weekly Google Ads brief the agent produces the same way every time.

Where the official server stops

It cannot change anything. No budget edits, no pausing, no new negatives, no ad copy. For that you have three options:

1. The agent drafts, a human applies. The agent produces the list of negatives or the budget change; a person applies it in the UI. Simple, auditable, slow.
2. Direct API for writes, from a script or your own tool, with the agent calling the script. This is what we do: reads through MCP, writes through a narrow set of our own functions that each do one thing (add search themes, adjust a budget, pause a campaign) and require confirmation.
3. A community server with write tools. Several exist. Review them like production code, scope the credential, and put every write tool behind approval.

Whichever you choose, the rule is the same: a tool that spends money gets a human in the loop and a log entry.

Running it for a team

A developer token, an OAuth refresh token and an MCC login ID together grant read access to every client account. That belongs in one place, not in environment variables on laptops. In a team setup the credentials live in a gateway, users get the server through it, write tools require approval, and every call is logged with who asked.

That is how our own Google Ads access runs: behind Walma AI Hub in our Azure tenant, next to Search Console, GA4 and Ahrefs, with one policy and one log. If you manage ad accounts for more than one person or one client, book a walkthrough.