# Google Ads MCP: Manage Google Ads With Claude (2026)

> Google Ads MCP explained: the official server is read-only. How to safely let Claude add negatives and edit campaigns with a preview-then-execute flow.

Published: 2026-07-17
Author: Simon (alloq.digital)
HTML version: https://alloq.digital/en/blog/google-ads-mcp/

---

You want to stop clicking through the Google Ads UI for routine work and just talk to your campaigns. Ask which ones are over target CPA this week, add ten negatives, clean up your conversion goals - all in a chat window. That is exactly what a **Google Ads MCP** promises. People want to *manage* their accounts, not just read them.

Here is the honest catch that most pages skip: Google's official Google Ads MCP server is read-only by design ([Google for Developers](https://developers.google.com/google-ads/api/docs/developer-toolkit/mcp-server)). It diagnoses and reports. It changes nothing. Real write access - the part where money moves - needs a different setup with a human confirming every change. This guide walks through both: what reading your account by chat looks like today, and what safe write access actually requires.

## What a Google Ads MCP Server Actually Is

MCP stands for Model Context Protocol. An open standard that lets large language models like Claude securely interact with external data and applications. Instead of every tool inventing its own way to talk to an LLM, MCP gives them a shared language for exposing structured tools the model can call.

A Google Ads MCP server is the bridge between Claude and the Google Ads API. It exposes a set of tools - things like "run this query" or "list my accounts" - that the model invokes when you describe what you want in plain English. Google's own docs frame it as a standardized bridge that lets AI agents analyze and retrieve campaign data using natural language.

The interaction loop is simple. You submit a request, the model inspects the available tools, the MCP server executes the underlying Python logic against the Google Ads API, the results land back in the context, the model responds. Want the deeper mental model of how a model chains tool calls like this? We cover [how AI agents work](/en/blog/ai-agents-explained/) separately.

Fewer tabs. No dashboard hunting. A conversation instead of a click path - that part of the promise is real. But it sets up the tension this whole article resolves. Reading data is easy and safe. Writing changes touches live ad spend, and that is where the picture gets more careful.

## The Official Google Ads MCP Server Is Read-Only

![Chart showing the official Google Ads MCP server exposes three read tools and zero write tools](/blog/google-ads-mcp-chart-1.svg)

*The official Google Ads MCP server ships exactly three retrieval tools and no mutate operation.*

Let us state it plainly, because no neutral source really does: the current version of the official Google Ads MCP server operates in read-only mode. It cannot add negatives, pause campaigns, or edit conversion goals. Full stop.

The GitHub repository lists exactly three tools, and all three retrieve information ([GitHub](https://github.com/googleads/google-ads-mcp)):

- **search** - runs a query against your account and returns the data (this is your GAQL entry point)
- **get_resource_metadata** - retrieves metadata about a Google Ads API resource type
- **list_accessible_customers** - returns the account IDs you can reach with your credentials

That is the entire surface. No mutate operation exists in the toolset.

Why build it this way? Because a mutate operation against a live account carries real financial risk if a model misfires. A read query that returns the wrong number wastes your time. A write operation that pauses the wrong campaign or adds the wrong negatives wastes your budget - sometimes silently. Google shipped the safe half first.

That constraint is actually the most useful part of this article. The winnable, honest story is not "look how much the official server does." It is understanding precisely what it *cannot* do yet, so you know where the risk lives when you go looking for write access elsewhere.

## How to Set Up the Google Ads MCP With Claude

![Illustration of the three prerequisites for setting up the Google Ads MCP: a Cloud project, a developer token and OAuth credentials](/blog/google-ads-mcp-illustration-2.webp)

At a high level you need three things before anything works: a Google Cloud project, a Google Ads developer token, and OAuth 2.0 credentials. The developer token is your own 22-character access string; the OAuth credentials are a client ID and secret pair. The full setup also involves configuring Python, enabling the API in your Cloud project, and pointing your MCP client at the server.

Where does it plug in? Into your MCP host's config. That is a JSON entry in Claude Desktop or in Claude Code - the same client where you'd run [Claude Code and other AI coding tools](/en/blog/best-ai-coding-tools/). Google's docs show the entry using `pipx` to run the server straight from the GitHub repository. You can also host the server on Google Cloud Run instead of running it locally, which lets you share it across agents or run it as a web service.

Keep the OAuth tokens server-side. The MCP server holds the credentials, and Claude only ever sees tool inputs and outputs - never the raw account keys. Far safer than putting ad-account keys into a client config, and the easiest thing here to get right. Be aware, too, that the MCP server exposes your connected account's data to whatever agent or LLM you attach, so treat that connection with the same care as any credential.

Two more things gate your risk. Your developer token needs at least Explorer access to query production accounts. And you can - and while you are validating, should - work against a test account first. The exact CLI commands and OAuth flow shift over time, so follow Google's official docs for the current steps rather than trusting a copy-pasted snippet from any blog, including this one. For the broader concept behind all of this, we go deep on [MCP and the Claude Agent SDK](/en/blog/claude-agent-sdk/).

## Reading Your Account by Chat: Practical Use Cases

![Illustration of reviewing Google Ads campaign performance through a natural-language chat instead of a dashboard](/blog/google-ads-mcp-illustration-3.webp)

Read-only is not a consolation prize. It removes the dashboard from a whole class of daily work, with zero risk to your spend. Here is what that looks like in practice.

**Campaign performance triage.** Ask: "Which campaigns are over target CPA this week, ranked by spend?" The model turns that into a query, pulls the numbers, hands you a ranked list. No filters, no column pickers, no exporting to a spreadsheet.

**Search-term report review.** Instead of scrolling the search terms report line by line, describe what you are hunting for - "show me search terms with spend but no conversions in the last 14 days" - and let the model surface the irrelevant queries eating budget.

**Keyword and match-type audit.** Ask it to find broad-match keywords bleeding money, or to break down performance by match type. The audit that normally means several tabs and a mental tally becomes one question.

**GAQL without writing GAQL.** The `search` tool retrieves information about your Google Ads account, and you can drive it in plain English. Describe what you want; the model writes the query. Already know GAQL? Hand it precise queries and get clean tables back.

The value is fast diagnosis. You catch the problem in a conversation. What read-only cannot do is fix it - and that is the frontier worth understanding properly.

## The Write Frontier: Safe Changes Through Preview-Then-Execute

![Illustration of a preview-then-execute safety pattern for Google Ads MCP write changes with a human confirmation step](/blog/google-ads-mcp-illustration-4.webp)

Where the official server stops is exactly where the real question begins: how do you let an agent change a live account without handing it a loaded weapon?

The answer is a pattern, not a product. Call it **preview-then-execute**. The agent proposes a change, shows you a preview or a diff, you confirm, and only then does the server execute the mutation. Nothing touches the account before an explicit human "yes."

A good preview is specific. Not "I'll add some negatives." It contains:

- **The exact entities affected** - which ad groups, which lists, which campaigns
- **Before and after values** - the current state and the proposed state, side by side
- **A count** - how many items land, so a mistake that touches 400 objects instead of 4 is obvious at a glance

Concretely, a preview for a pause request reads like a plain diff: `campaign "Brand - Exact"` with `status: ENABLED -> PAUSED`, and nothing else moves until you type your confirm. A negatives preview reads the same way - each proposed term listed against the ad group or shared list it will join, with its match type spelled out - so you see the actual account state that would result, not a vague summary of it.

The human approval gate sits between the preview and the mutation. That single gate is what separates assisted management from a runaway agent. A well-built write flow tends to follow exactly this shape: propose, show the diff, wait for a human confirm, then execute. Not because it is elegant. Because the alternative is trusting a language model with a live budget on a one-shot command.

Write-capable third-party MCP servers exist as a category. Some vendor pages pitch "draft-first" campaign management as the fix for Google's read-only limit. Treat that category with the same skepticism you apply to any tool touching your money: ask what the preview actually shows, where the confirm step sits, what happens when a write silently fails. A page that asserts "draft-first" but shows zero real prompts, payloads, or before-and-after account states has not earned your credentials. We built [AdPlug](https://adplug.app) as exactly this kind of write-capable Google Ads MCP: every mutation - negatives, goal changes, bid edits - returns a preview you confirm before anything touches the account.

### Real Write Jobs: Negatives, Conversion Goals, Values

Here is what preview-then-execute looks like on three high-value jobs, each running as prompt, then preview, then human confirm, then execute - never a blind one-shot mutation.

**Bulk negative keyword addition.** You describe the list: "Add these 30 terms as negatives to my Search campaigns' shared list." The preview shows exactly which negatives land in which ad groups or shared lists and how many. You scan it for close-variant junk that would block valuable traffic, confirm, and the server executes. The preview is the whole point - it stops a careless list from quietly strangling your best queries.

**Conversion-goal cleanup.** A common mess: GA4-import conversion goals dragging smart bidding toward soft signals. The job is to move those imported goals to non-biddable and keep only the ones that matter - lead-form submissions, bookings, calls. The preview lists every goal and its proposed biddable state. You confirm before smart bidding's inputs change.

**Setting conversion values.** If your conversions carry no values, smart bidding optimizes toward volume, not business outcomes. Setting values - a booking is worth more than a newsletter signup - lets the algorithm chase revenue. Again: describe the values, preview the mapping, confirm, execute.

One detail matters more than it sounds. After every write, the server should read the object back and return the persisted state, not the payload you sent. MCP servers over other money-touching APIs can hit a nasty failure mode: a controller accepts fields it does not understand, returns a success code, and silently applies nothing. Every tool call comes back green while nothing actually changed. A read-after-write check catches that. The model sees the diff, notices the change did not stick, and tells you - one extra call that saves hours of debugging a "successful" write that did nothing.

Managing a live account this way can feel uneasy at first, because a chat window now sits between you and your budget - but the preview step is generally what earns trust. It can surface a proposed negative that would block a converting brand term, letting you reject it at the confirm step, and it removes the manual hunt through the search-terms report. The result tends to be faster mechanical work, with the operator still owning every "yes." That is the honest trade-off.

## Safety: You Are Handing an LLM Access to Live Ad Spend

![Illustration representing safety when giving an LLM access to live Google Ads spend through the MCP](/blog/google-ads-mcp-illustration-5.webp)

This is the section every ranking page skips. Give an agent write access to a live account, and you are handing a language model the ability to spend your money. That deserves a real safety playbook, not a reassuring sentence.

**Start with least privilege.** Scope the access to a single account. Prefer test accounts while you validate the flow - your developer token controls whether you can even query production, and there is no reason to point an unproven setup at a live budget. Limit which mutate operations you expose at all; an agent cannot pause a campaign it has no tool to pause.

Now the failure modes worth naming, because they are how money actually gets lost:

- **Misread metrics.** The model confuses CPA and ROAS, decides a strong campaign is failing, proposes pausing it. The numbers looked authoritative. They were the wrong numbers.
- **Junk negatives.** Close-variant and low-quality terms get added as negatives and accidentally block valuable traffic. This one is silent - you do not see the lost impressions, only a slow bleed in volume.
- **Destructive mutation with no undo.** The agent pauses the wrong campaign, and there is no clean one-click reversal. By the time you notice, the day's traffic is gone.

The mitigations map directly onto those risks: a mandatory preview so you catch the wrong action before it runs; a human confirm as the hard gate; read-after-write checks to expose silent failures; change caps so no single command can touch hundreds of entities; an audit trail recording what the agent did and when. None of these is optional if real spend is involved. Together they turn "the agent changed my account" into "the agent proposed a change, I approved it, and I can see exactly what happened."

## MCP vs Google Ads Scripts vs the Raw REST API

MCP is one of three ways to program against Google Ads, and they solve different problems. Here is how they compare.

| | MCP with Claude | Google Ads Scripts | Raw REST API |
|---|---|---|---|
| **Interaction** | Conversational, ad hoc | Scheduled, deterministic | Programmatic, integrated |
| **Best-fit task** | Analysis + human-approved changes | Recurring rule-based jobs | Building custom software |
| **Human in the loop** | Yes, by design | No, runs unattended | Depends on what you build |
| **Skill needed** | Low - describe what you want | Medium - JavaScript | High - full engineering |
| **Weakest at** | Unattended automation | Conversational flexibility | Cost and responsibility |

**MCP** shines when a human stays in the loop. Fastest for ad-hoc analysis and for changes you want to approve before they run. Wrong tool for unattended, run-every-night automation.

**Google Ads Scripts** live inside the account and run on a schedule. Deterministic - same input, same output - which makes them ideal for recurring rule-based jobs like "pause any keyword over this CPA every morning." No human required. No conversation either.

**The raw REST API** gives you full control and the ability to integrate Google Ads into your own software. It also carries the highest engineering cost and the most responsibility - you own the auth, the retries, the error handling, everything.

The guidance is simple. Use MCP when a human stays in the loop. Use Scripts for repeatable automation. Reach for the REST API when you are building a product on top of Google Ads. For most KMU teams handling their own campaigns, MCP plus a human confirm covers the highest-value work - which is why [AdPlug](https://adplug.app) is built around that exact preview-then-execute gate.

## Honest Limits: No True Autonomy Yet

Let us close where the hype usually will not. Agents make mistakes with money. Not a temporary bug to engineer away by next quarter - it is the reason human approval should stay in the loop for anything that mutates a live account.

MCP does not grant judgment. It speeds up execution, not strategy. The model can pull your search-term report in seconds, but deciding whether a rising CPA reflects a bad keyword or a seasonal shift is still your call. The agent is a very fast pair of hands, not a media buyer.

So the realistic 2026 setup is assisted management, not a hands-off autopilot. You get through the diagnostic and mechanical work far faster - reading the account, drafting negative lists, cleaning up conversion goals - while you keep the decisions and the final "yes."

Where is this heading? Better guardrails, richer previews, tighter change caps. The tooling will keep improving. But accountability stays with the human operator. When money moves, someone has to have approved it - and for now, that someone should be you.

## FAQ

**Can the official Google Ads MCP server change my campaigns?**
No. The official server is read-only in its current release. It runs GAQL queries, fetches resource metadata, lists accessible accounts, but it cannot add negatives, pause campaigns, or edit goals. Write access requires a different, write-capable server with a confirmation flow.

**Is it safe to give an AI agent write access to live ad spend?**
Only with guardrails. Use least-privilege access, prefer test accounts while validating, and require a preview-then-execute flow where a human confirms every change before it runs. Add read-after-write checks and an audit trail. Never let an agent mutate a live account one-shot without approval.

**How do I let Claude add negative keywords in bulk safely?**
Describe the list to the agent, then review a preview showing exactly which negatives land in which ad groups or lists and how many. Confirm, then let the server execute and verify the result. The confirm step is what keeps close-variant junk from silently blocking valuable traffic.

**What do I need to set up a Google Ads MCP with Claude?**
A Google Cloud project, a Google Ads developer token, and OAuth 2.0 credentials, plus an MCP entry in your Claude Desktop or Claude Code config. Keep tokens server-side so Claude only sees tool inputs and outputs. Follow Google's official docs for exact, current steps.

**When should I use Google Ads Scripts instead of an MCP?**
Use Scripts for scheduled, deterministic automation that runs without a human, like recurring rule-based jobs. Use an MCP for conversational analysis and human-approved changes. Use the raw REST API when you are building custom software and need full control.