Build a Google Ads agent that can't wreck your account.

You open a terminal and type one sentence: pull last week's search terms with spend over $50 and no conversions, and draft me a negative keyword list. A few seconds later the account has been queried, the rows filtered, and a reviewed list handed back. Type again and the budget shift you described is staged, paused, waiting for you to confirm. This is not a demo. It runs today, and the setup takes an afternoon.

The question is no longer whether you can operate Google Ads from a conversation. You can. The question this guide answers is the practical one: which of the four available paths fits the job, how to wire the safe read path in ten minutes, what the July v25 release quietly broke underneath you, and how to build a write path that fails safe instead of fast. For the prior question, whether you should hand an agent your accounts at all, and where the accountability sits when it does, the companion piece on what to let Claude Code touch is the argument. This one is the build.

01Four paths, and the line that divides them

There is not one way to automate a Google Ads account. There are four, and they are not competitors so much as tools for different jobs. The useful way to sort them is the line between what someone already built for you and what you assemble yourself.

Google Ads scripts are the oldest and most boring of the four, and that is their strength: deterministic JavaScript that runs on Google's own servers on a schedule, ideal for the fixed, repeatable jobs an agent would be overkill for, like a budget-pacing alert or an out-of-stock pause. The MCP options and the raw API are where the conversational, exploratory work lives. MCP itself is an open standard for connecting a model to the tools and data where the work happens, and Claude Code speaks it natively. [2] And between those two, the fork that decides your whole week is read versus write.

Before the table turns into a decision, match it to the job in front of you.

The pattern most teams land on is not picking one. It is running scripts for the deterministic jobs, the official server for reading, and a carefully built write path for the conversational changes, with a human owning the objective on every path that can spend.

02The read path, wired in ten minutes

Start where the risk is lowest and the payoff is immediate. Google ships an official connector for exactly this: the Google Ads MCP server, published at github.com/googleads/google-ads-mcp, gives any MCP-compatible client read-only access to an account. [3] It exposes three tools, and every one of them is a query.

The configuration is short. Claude Code reads three scopes for where a server is defined: local (just you), project (committed and shared with your team), and user (all your projects). [1]

"mcpServers": {
  "google-ads": {
    "command": "pipx",
    "args": ["run", "--spec",
      "git+https://github.com/googleads/google-ads-mcp.git",
      "google-ads-mcp"],
    "env": { "GOOGLE_ADS_DEVELOPER_TOKEN": "your-developer-token" }
  }
}

Once it is connected, the agent works in GAQL, the account's SQL-like query language. You never write it by hand. You say what you want to see, and the model produces and runs the query behind it. The wasted-spend request from the opening looks like this once translated:

SELECT search_term_view.search_term, metrics.cost_micros
FROM search_term_view
WHERE metrics.conversions = 0
  AND metrics.cost_micros > 50000000
  AND segments.date DURING LAST_30_DAYS

Two credential details decide how far this scales. First, access level: a developer token at Test or Basic access runs up to 15,000 operations per day, where an operation is any read or write request; Standard access lifts that to effectively unlimited. [8] For read-heavy analysis across a handful of accounts, Basic is usually enough to begin. Second, and more important, the signal in the tool count.

The company that owns the data decided what an agent should get by default: look, do not touch. To spend money in Google Ads, you will not use Google's connector. You build the write path yourself, which is the whole reason the guardrails end up being yours.

03What v25 changed underneath you

Any integration you build is a maintenance commitment, because the API does not sit still. Google moved the Google Ads API to a monthly release cadence in 2026, and v25, released July 22, is a major version with breaking changes, not a quiet point update. [5] Two of its changes matter to anyone wiring an agent, and one of them will take down a naive integration on the day it upgrades.

The removal is the one to respect. In v24 you configured customer acquisition through the lifecycle goal resources. In v25 those resources are gone, deleted outright, with configuration moved to a unified Goal and CampaignGoalConfig schema, and there is no soft-deprecation path or automatic remapping. [7] An agent that queries the old resources does not degrade gracefully. It errors.

The practical lesson is not the specific fields. It is the treadmill itself. A monthly major cadence means any integration sprawled across raw endpoints becomes a monthly firefight. The defense is architectural: keep the platform-touching code in a thin, single layer you can version-bump and re-test in one place, rather than letting v25's field names leak into every tool your agent calls. That thin layer is exactly what the write path should be anyway.

04The auth reality, and what it does not protect

Before you build anything that spends, it helps to know precisely what the platform secures for you, because it is less than the headlines suggest. Google spent 2026 adding security controls, and they are real. They also guard a different door than the one an agent walks through.

Here is the part that surprises people. Google Ads exposes a single broad OAuth scope, adwords, described on the consent screen as permission to see, edit, create, and delete your Google Ads accounts and data. There is no read-only sub-scope. A connector that only reports asks for the same all-powerful permission as one that can delete a campaign, so the token is doing the talking, not the tool's friendly description. [9]

The 2026 additions do not narrow that. They add friction at sign-in and for account access, which is not the same as limiting spend.

Read the split plainly. Passkeys harden human sign-in. Multi-party approvals harden who can be granted access. Both are about the front door. What an already-authorized agent does inside, at the speed of automation, is still entirely on you. That is not a gap Google forgot to close. It is the design: the platform secures identity and access, and leaves the blast radius of an authorized action to the person who authorized it.

05Build the write path so it fails safe

There are two ways to give Claude Code the power to change an account, and they trade convenience for control.

The fast way is to connect a write-capable server someone else built. Community and hosted options exist, like the mcp-google-ads server, which routes every write through a two-step safety layer (draft a change, review the preview, then confirm), with budget caps, bid limits, and audit logging built in. [11] That posture, paused-by-default and confirm-before-execute, is exactly what to demand from any write server. But it still holds the broad scope, and its safety model is the vendor's, not yours.

The controlled way is to write the mutate tools yourself: thin, typed tools you expose to Claude Code, each doing one thing on one account. It is more work, and it is the only honest choice for any account you cannot afford to have wrecked. The principle is simple and worth stating as a rule.

Here is what that looks like in practice. One tool, one job, wired to one account, with the cap compiled in rather than requested politely.

from google.ads.googleads.client import GoogleAdsClient

ALLOWED_CUSTOMER = "1234567890"   # the sandbox account, nothing else
MAX_TERMS = 50                    # a hard cap the prompt cannot raise

def add_negative_keywords(customer_id, campaign_id, terms):
    if customer_id != ALLOWED_CUSTOMER:
        raise ValueError("refusing: this credential is wired to one account")
    if len(terms) > MAX_TERMS:
        raise ValueError("refusing: too many terms, over the hard cap")

    client = GoogleAdsClient.load_from_env(version="v25")
    # ... build the criterion operations here ...
    # Every change is added as NEGATIVE and left for a human to review.
    # The tool exposes no path to enable, raise a budget, or delete.
    return "staged " + str(len(terms)) + " negatives for review"

Notice what the tool cannot do. It cannot touch another account, because the credential and the check both pin it to one. It cannot add a thousand terms, because the cap is a constant, not a parameter. It cannot enable anything or raise a budget, because no code path exists for it to call. The agent is free to be as confident as it likes; the surface it can act on is the one you deliberately drew. Contrast that with the platform's own automated products, like Performance Max and Advantage+, where the lever you hand over is a goal you set and the system runs; here the lever is a tool you define, and its shape is the whole safety story.

Run your finished write path against a short checklist before it sees a live account. Treat any unchecked line as blocking, not as a nice-to-have.

• The write credential reaches one account or a sandbox, never your whole manager hierarchy.
• Each tool does one thing and validates its inputs; there is no general "run this mutate" tool.
• Every change is created paused or in preview, so a mistake surfaces before it spends.
• Hard limits (spend, item counts, allowed accounts) live in the tool's code, not in the prompt.
• Every tool call is logged, not just every API call, because the tool call is where the real action is decided.
• You trust and have read each MCP server you connect, and reject any that fetches untrusted external content. [1]

That last line is not boilerplate. Claude Code's own documentation warns to verify you trust a server before connecting it, because a server that pulls in external content can carry a prompt injection straight into an agent holding a scope that can delete campaigns. [1] For this connector, that warning is the threat model, not fine print.

06A small ad-ops cookbook

With the read path live and one or two capped write tools in place, the day-to-day is a conversation. These are the requests that earn their keep first, each a plain sentence that becomes a query or a staged, paused change underneath.

The shape repeats. Reading is open, immediate, and reversible, so lean on it hard. Writing is narrow, staged, and confirmed, so it moves at the speed of your review, not the model's confidence.

07Keep it alive

An agent integration is not a project you finish. It is a small system you maintain, and the maintenance is predictable enough to schedule.

That is the honest position for 2026, and it is the same one that holds for every capable agent. The convenience is real, and you should take it: the reading alone gives back hours a week, starting the afternoon you wire it. What has not changed is who answers for a budget that moves. Keep a human on every write, wire the agent to the narrowest slice of the account it needs, put the caps in code where no sentence can talk them up, and the account that gets wrecked this year will not be yours. It will be the one where someone mistook a plain-English request for a safe one.

Sources

1. Anthropic · Connect Claude Code to tools via MCPinstallation scopes (local, project, user), stdio transport, and the trust and prompt-injection warning
2. Model Context Protocol · IntroductionMCP as an open standard for connecting AI models to tools and data
3. Google · Google Ads MCP serverofficial, read-only; the three query tools (search, get_resource_metadata, list_accessible_customers) and the pipx install
4. Google for Developers · Google Ads MCP server integration guiderequired credentials: developer token, Cloud project, OAuth client or Application Default Credentials
5. Google Ads Developer Blog · Announcing v25 of the Google Ads APImajor release, July 22, 2026; new goals and reporting; synthetic content info becomes mutable
6. Search Engine Land · Google Ads API v25 adds YouTube metrics and loyalty campaign goalsShorts social metrics, duration segments, and the loyalty retention goal
7. PPC Land · Google Ads API v25 kills two lifecycle goal resources, forcing code rewritesCustomerLifecycleGoal and CampaignLifecycleGoal removed outright, no deprecation window, replaced by Goal and CampaignGoalConfig
8. Google for Developers · Access levels and permissible useTest and Basic access capped at 15,000 operations per day; Standard access effectively unlimited
9. Google Ads Developer Blog · Google Ads API release and security updatesthe single broad adwords OAuth scope; multi-party approvals from July 27, 2026 and MFA on the refresh-token flow, both for access not spend
10. PPC Land · Google Ads passkeys and account securitypasskeys enforced July 15, 2026 for sensitive console actions (adding users, billing, links, access), surfaced in the API only as a read-only status field
11. lib.rs · mcp-google-ads, a community write-capable serverdraft, preview, confirm safety layer with budget caps, bid limits, and audit logging, built on the standard developer token and OAuth

MS

Editor-in-chief

Mikołaj Salecki

Writes about media, tech, and AI business for people who actually run digital. Former agency lead. Skeptic of frameworks that read better than they perform.

LinkedIn ↗Facebook ↗salecki.digital ↗

More articles →