How to Connect Claude AI to Google Ads (2026 Setup)

I made a video a year ago connecting Google Ads to Claude through Zapier. It became this channel's most watched video, and the top comment under it, the actual top comment, was someone asking how to get API access in the first place. I had built the whole thing around a third party tool sitting in the middle, which meant one more subscription and one more thing that could quietly break. This version skips Zapier entirely. It is a more complex setup to walk through on camera, and it is the setup I now run myself.

The direct connection is worth the extra twenty minutes for one reason: nothing sits between Claude and your account except the credentials you control. No middleman service, no extra monthly fee, no dependency on a third party staying online. Once it is wired up, every conversation after this one can pull real campaign numbers instead of you exporting a CSV and pasting it in.

Here is that original video, for anyone who wants to see the Zapier version before picking a route. The write-up that went with it is still live too: Google Ads MCP Claude Account Audit: Complete Guide, worth a read if you would rather compare the Zapier steps on the page than dig them out of the video.

Everything starts with a Google Cloud project. If you already run one for other tools, you can reuse it, but I would actually recommend a dedicated project for this specifically. It keeps your permissions and your quota cleaner, and it makes troubleshooting a lot easier six months from now when you have forgotten which project owns which key.

Name it something that describes what it is for, not whatever random default Google suggests. Once the project exists, go to APIs and Services, then Enabled APIs and Services, and search for the Google Ads API specifically. Click it, click Enable, and wait for the confirmation. That is it for step one. The project exists and it knows about the Google Ads API. Nothing works yet. This is just turning the lights on.

Concretely: open Google Cloud Console, create the project from the project switcher in the top bar, then go to APIs & Services > Library, search "Google Ads API," open the result, and click Enable. You will land back on an APIs & Services overview showing the Google Ads API as active once it goes through.

This is the step that actually blocked me, so I want to slow down here. You need to configure what is called the OAuth consent screen, the permission screen a user sees when your app asks to access their Google Ads data. You fill in an app name, a support email, and an application home page. That last field matters more than it looks like it should.

Here is exactly what I did wrong. I named my app something purely descriptive, Google Ads MCP. Made sense to me, it described exactly what the thing did. I pointed the application home page at my own site, onlinelabs.io, submitted for brand verification, and got rejected. Not one flag, three at once: the app name did not uniquely identify a brand, the home page did not clearly explain what the app does, and the two did not match each other.

The fix was almost embarrassingly simple once I found it. I renamed the app from Google Ads MCP to Online Labs, an exact match to my site's actual title and logo. Nothing else changed, not the home page content, not the description, just the app name matching the brand a stranger would actually recognize if they landed on that home page. That alone cleared all three flags.

One more field while you are in there: the privacy policy link. You do not necessarily need a dedicated standalone privacy policy page. I use a link to an externally hosted policy referenced from inside my site's terms page, and that passed verification without getting flagged. If your own setup does get flagged specifically on the privacy policy field, that is the first thing worth splitting into its own page, but do not assume you need one from the start.

For the exact fields Google checks and how they cross reference them, Google's own brand verification guide covers it in more depth than I will here, including the rule that you cannot use Google product names or logos as part of your own app identity.

Here is the second thing that actually cost me time. Most Google OAuth setups let you stay in Testing or Internal mode and skip verification entirely if you are only using the app yourself. I assumed the same applied here. It does not, not for this specific API. The Google Ads API's own documentation says it directly: even a Testing or Internal app has to go through brand verification.

So before you can even attempt verification, you need to publish the app to production. There is a confirmation dialog, click through it. Only after that does the option to actually verify your branding become available under the Branding tab.

Once you click verify, and assuming your app name genuinely matches your brand this time, the check is automated. It is not the multi week manual review some other Google API scopes require. This one completed in minutes for me. You will get an email with a subject line along the lines of OAuth Verification Response, confirming approval.

Separate from everything you just did in Google Cloud, you also need a developer token, and that comes from inside Google Ads itself, not Google Cloud Console. Go to Tools and Settings, then API Center, under your manager account specifically. This has to happen at the manager account level, not an individual client account underneath it.

You will be asked to describe what you are building and how you will use the API. Be honest and specific. I described exactly what this is: an AI assistant with read and query access to pull reporting, and specific approved write access to make changes to accounts I already manage. Vague or evasive answers here tend to slow the review down, not speed it up.

You will get Basic access first, which is what most people need. Fifteen thousand operations a day sounds like a limit until you realize a single query pulling a full campaign report might count as one operation, so it goes a long way for one person managing a handful of accounts.

Most write-ups only ever mention Basic access, but a token actually moves through up to four tiers, and knowing which one yours sits at tells you exactly what it can and cannot do right now.

Full detail on permissible use, meaning whether your token is scoped for ad management, reporting only, or keyword research, is in Google's access levels and permissible use documentation.

Once approved, the developer token is tied to that manager account. Any client account underneath it that you have proper access to becomes queryable through that same token. You do not need a separate token per client, which matters the moment you are managing more than one account.

At this point you have three pieces in hand: an OAuth client from Google Cloud, a verified brand behind it, and a developer token from the API Center. Wherever your actual Claude connection lives, plug those three pieces in there, along with the refresh token you generate the first time you authorize it. The exact place you paste these credentials depends on your specific setup, but these are the pieces every version of this needs.

I am not going to spend this article on workflows, that is a different piece I have already written, my Claude AI Google Ads audit workflow, built around the same prompt library I run on every account I touch. I just want to prove this setup actually works before wrapping up. One prompt: list my active campaigns and this week's spend. The response comes back as a real table pulled from the live account. Switch over to the actual Google Ads interface, same account, same date range, and the numbers match. That is the whole point of everything above.

None of this is a five minute glossed over version, and I would rather it read that way than pretend the OAuth verification step is trivial when it is the exact thing that stalls most people halfway through. Once it is done, though, it stays done. You are not repeating this setup every week, you are repeating it once per business.

If you hit either of the two snags I hit, the brand name mismatch or assuming Testing mode would skip verification, you now know exactly what is happening and how to fix it. If you would rather skip the setup entirely and want someone to actually go through your account, the free audit link below does that.