Claude Code for Google Ads: how it works and where it stops

The value lies in analysis, the risk in write access

For Google Ads, Claude Code is worth it first as an analysis tool that combines account data with numbers the account does not have. My assessment follows from a simple cost calculation: a read error costs review time, a write error costs budget. If you start with automation inside the account, you carry the more expensive risk for the smaller part of the benefit.

Mechanically, the tool is not a Google Ads product. Claude Code runs locally and, with your permission, runs commands and reads files. It only knows about Google Ads once you give it a route to the data.

Three routes to the account data

Google's official MCP server offers three tools: query account data, read metadata about resources, list accessible accounts. According to Google, it is strictly read-only and can neither change bids nor pause campaigns. What else it can do is covered in the article on the Google Ads MCP server.

To get started, I recommend the export. Without any setup, it shows whether the question is worth asking at all, and nothing in the account can change in the process.

Which API access you need

Many guides are out of date here. Google retired developer tokens on 9 September 2026: tokens sent along are ignored, and the access level is tied to the Google Cloud project. The sequence, as of November 2026:

1. Create a Google Cloud project and enable the Google Ads API. That gives you Test access with 15,000 operations per day, but only on test accounts.
2. Apply for Explorer access. According to Google, this is usually reviewed and approved automatically, with up to 2,880 operations per day on live accounts.
3. Set up an OAuth login with the adwords scope and add the MCP server to Claude Code.
4. You only need a manager account if you want to link and manage several accounts through the API.

For analyses on a single account, I consider the Explorer quota sufficient. If you query many accounts continuously, work out the numbers beforehand.

Why read-only access only appears to protect your budget

The read-only mode sits in the server, not in the credential. Google states in the server's code that there is no separate read-only scope: the server restricts access only by not offering any write tools. The same scope also allows changes.

Then there is the shell. Anthropic points out that Claude can still reach arbitrary addresses through Bash if Bash is allowed, even when individual tools are blocked. The documentation itself calls rules that try to constrain command arguments fragile. My conclusion: if the credentials sit on the same machine and the shell is allowed, the agent can write a change itself even though the MCP server only reads. Google's Developer Assistant for Claude Code even explicitly generates such code for changes.

Three measures narrow this gap; I would proceed in this order:

• A separate user with the Read-only role. This access level cannot edit campaigns in Google Ads. Test it: a change request with this login must return an error.
• Approve shell commands one at a time. In manual mode, Claude Code asks before Bash commands. "Yes, and don't ask again" applies permanently to the project and the command, so do not click it out of convenience.
• A sandbox instead of command patterns. It limits file system and network regardless of the command text, as long as the Google Ads API is not among the allowed domains. Commands inside it run without confirmation by default.

How to set up approvals and dry runs in detail is covered under securing AI agents in the account.

What it is good for: calculating against numbers the account does not have

The account knows neither margin nor returns nor stock. An agent that only sees account data therefore optimises neatly towards a value that does not reflect contribution margin. A worked example with invented numbers, each based on €1,000 of revenue after returns:

Without margin data the budget moves to B, with margin data to A. This combination is the tool's strength: it reads the report and the margin file, calculates break-even ROAS per product group and lists where the reported ROAS falls below it. The same works with stock lists or a search terms report analysed in commercial terms.

This only partly applies if your conversion value already contains contribution margin. The account then sees more, but returns and stock are usually still missing.

What it is not good for

In my assessment, four tasks are poorly suited:

• Proving causes. A model finds patterns in reports. That does not prove why ROAS has fallen. Every statement needs a cross-check, see checking AI analyses of account data.
• Fixed rules in continuous operation. Anything that always runs the same way is handled more cheaply and predictably by a script; see scripts or AI agents.
• Unsupervised changes to bid strategies. Here the damage does not end when you reset the change.
• Numbers with no route back to the source. An analysis you cannot trace back to the query does not belong in a budget decision.

Set the approval limit by damage, not by convenience

For each type of change, define how much it can cost at most before anyone notices. The formula: affected daily value × days until the next check. Invented examples:

With an assumed limit of €300, spot checks are enough for the negative keyword, while budget and pause each get individual approval. The limit itself is a commercial decision that no tool takes off your hands.

The formula underestimates two cases: changes to bid strategies, because the consequences can outlast the reset, and promotional periods, when the daily value is a multiple of normal. Both always need individual approval.

Technically, the validate_only parameter helps: the request is validated but not executed, and only errors are returned. That protects against broken requests. A valid request can still be commercially wrong.

Which risks remain besides the budget

Data flow. Running locally does not mean that nothing leaves the machine. Claude Code sends prompts and model outputs over the network, and Google warns that the MCP server exposes account data to the connected model. On Free, Pro, Max and Ultra plans, model training depends on a setting; on Team, Enterprise and API, according to the documentation, Anthropic does not train on this data by default. So check your plan and your data protection obligations before client data is involved. The context is covered under account data in AI tools.

Prompt injection. OWASP lists indirect injection via external content as a risk, considers reliable prevention unresolved and names least privilege and human approval as countermeasures. My conclusion: search terms are text that strangers write into the account, as is content from landing pages the agent fetches. I would therefore not let an agent with write access read such data. With a login that has been shown in a test to be unable to write, what remains of an injection is a wrong analysis that you have to cross-check, and, with unrestricted network access, a possible leak of account data.