Is it safe to connect Google Ads to Claude?

Yes, when the connection is built correctly. OAuth tokens are stored in the MCP server, not the model, and every change runs as an approval-gated dry-run so nothing writes to your account without an explicit confirmation from you.

Do I need a Google Ads developer token?

Only if you self-host your own MCP server. A hosted Ads MCP handles the developer token and OAuth app for you, so you just click through Google's consent screen once.

Can one connection manage multiple client accounts?

Yes. If you connect through your MCC (manager) account, the single OAuth grant can reach every linked child account, which is how agencies manage many clients from one setup.

How to Connect Google Ads to Claude (OAuth Setup)

VigilDog Team · October 2, 2026 · 6 min read

Running Google Ads from a chat window sounds like a gimmick until the first time you ask "which campaigns burned budget with zero conversions this week?" and get a real answer in seconds. To get there, you first have to connect Google Ads to Claude through OAuth. This guide walks the actual setup, what each consent screen means, and the guardrails that keep an AI assistant from doing something you didn't approve.

What "connecting Google Ads to Claude" actually means

Claude doesn't talk to the Google Ads API on its own. It talks to an MCP server, a small service that exposes Google Ads actions as tools Claude can call. When you connect Google Ads to Claude, you're authorizing that MCP server to act on your account through OAuth, then pointing Claude at it. Claude decides which tool to call based on your request; the server executes the API call and hands back structured results.

This matters because the OAuth token never lives inside the language model. It lives in the MCP layer, encrypted, scoped to the permissions you grant. Claude only sees the tool definitions and the data returned, not your refresh token. That separation is the whole reason this can be safe to use on live accounts.

How an Ads MCP runs a change safely

Before you start: what you need

Setup goes faster if you gather these first. Most people stall on the developer token, which Google reviews before granting production access, so start that early if you're self-hosting.

A Google account with access to the Google Ads account(s) you want to manage, ideally at Admin or Standard level.
The account's 10-digit customer ID (top-right in the Google Ads UI, formatted 123-456-7890).
If you manage clients, your MCC (manager account) ID, which lets one connection reach every linked account.
An MCP server that speaks Google Ads. VigilDog's Ads MCP is hosted, so you skip the developer-token application and OAuth-app setup entirely.

The OAuth flow, step by step

With a hosted server the flow is short. You open the connection screen, click through Google's consent, and you're done. Here is what happens and what each step is asking of you.

First, you initiate the connection from Claude's connector settings (or the VigilDog dashboard) and choose Google Ads. This redirects you to Google's own accounts.google.com sign-in, never a third-party form asking for your password. If anything asks you to type your Google password into a non-Google page, stop, that's the wrong flow.

Next, Google shows a consent screen listing the scope being requested, typically the Google Ads management scope. Read it. Granting it lets the connected app read reporting data and make changes such as adjusting bids or pausing campaigns. Approve only if you intend to allow changes; some setups offer a read-only scope if you just want reporting.

Finally, Google issues an authorization code that the MCP server exchanges for an access token and a long-lived refresh token. That refresh token is stored encrypted on the server side and used to mint short-lived access tokens as needed. You'll land back on a success screen, and the account now appears as connected.

Self-hosting the connection (the longer path)

If you're building your own MCP server instead of using a hosted one, the OAuth setup has more moving parts. You create a project in Google Cloud Console, enable the Google Ads API, and configure an OAuth consent screen. You then create OAuth client credentials of type "Desktop" or "Web", which give you a client ID and secret.

Separately, you apply for a Google Ads developer token under API Center in your manager account. New tokens start with Test access, which only works against test accounts. To run production campaigns you submit a short application describing your use case and wait for Basic access approval, which can take a few days. Skipping this is the single biggest reason a self-built connection returns "developer token not approved" errors on real accounts.

Google Cloud project with the Google Ads API enabled.
OAuth client ID + secret from the Credentials page.
A developer token from API Center (apply for Basic access for production).
A one-time refresh-token generation script to complete the first OAuth exchange.

Keeping it safe: dry-run and approval gates

Letting an AI touch a live ad account is only reasonable with guardrails, and this is where a well-built Ads MCP earns its keep. Every mutating action, creating a campaign, changing a budget, pausing an ad, should run as a dry-run first: the server returns exactly what would change without committing it. You review the diff, then explicitly confirm before anything writes to the account.

In practice that means when you ask Claude to "cut the budget on the branded campaign to $40/day," it shows you the current value, the proposed value, and waits. Nothing changes until you approve. Reporting queries, being read-only, run immediately. This approval gate is what makes it defensible to point an assistant at accounts you're spending real money on, and it's the default behavior described in our guide on how to run Google Ads from Claude.