Will Google Ads ban you for using an MCP?

Does using an MCP get your Google Ads account banned?

No. An MCP server talks to Google through the official Google Ads API — the interface Google publishes, documents and supports for exactly this. There is no policy that prohibits connecting an AI client to it. Google itself ships an official Google Ads MCP server for exactly that purpose, and its launch announcement frames it as making campaign analysis available to “any MCP-compatible AI application.”

What Google enforces against is a set of behaviors — and those behaviors are bannable whether a human, a script or an AI performs them. The confusion comes from a wave of Meta ad account suspensions in early 2026, widely reported as “AI got my account banned.” Read the incident reports and the pattern is always the same: it was never the model. It was the connection method and the absence of human review.

The three real risks

They are not equally severe, and treating them as one thing is why most advice on this topic is useless. Two can cost you the account. One cannot.

Risk 1 — Browser automation, which is not an MCP at all

This is the risk most often mistaken for “the MCP got my account banned,” and it is the opposite of using one. Instead of talking to the API, you give an AI agent control of Chrome, Safari or Firefox so it opens your Google Ads Manager interface and clicks for you: changing budgets, activating campaigns, moving buttons inside the UI.

An MCP server does not do this. It calls documented API endpoints. Browser automation is what people reach for when they do not have an API connection — and it is the one behavior Google names outright.

This is the one risk that is not a gray area. The Google Ads Terms & Conditions state it directly:

The Google Ads API Terms add a second clause that browser agents trip by design: “You will only access (or attempt to access) the Google Ads API by the means described in the Google Ads API Specifications. You will not misrepresent or mask your identity.” An agent driving a logged-in browser session is, definitionally, presenting itself as the human user.

And even setting policy aside: an agent clicks at a speed and regularity no person produces. Detection systems built to catch bots manipulating ad auctions are looking for exactly that signature.

Risk 2 — Publishing campaigns nobody reviewed

This one can happen through an MCP — specifically, through any MCP with write access and no human in the loop. It is the risk that has actually produced reported suspensions, and it is the most misunderstood, because the violation has nothing to do with automation.

When you fully delegate campaign creation to an AI, it can write claims that aren’t true: promises your product doesn’t keep, guarantees you can’t honor, superlatives that trip Google’s advertising policies. Those are ordinary policy violations. The account gets suspended for the ad copy, not for the tool that wrote it.

The distinction matters because it tells you where the fix goes. The ban isn’t a consequence of automating campaign creation. It’s a consequence of no human ever checking that the campaigns complied with policy before they went live. Automate the drafting all you want; the review step is what you cannot delegate.

Risk 3 — Developer token rate limits and downgrades

This one applies to any API connection, MCP or not — and it will not ban your account. It is worth being precise about, because nearly every article on this subject — and Google’s own AI-generated summary of it — folds rate limits in with ban causes. They are different consequences with different remedies.

When you connect Google Ads to an AI through the API you need a developer token, and that token has a daily operation limit set by its access level:

Reading data will almost never approach those limits. The problem appears with write actions: creating campaigns, applying bulk changes, working in batches.

And here is why agents hit limits when humans don’t. When a person hits a restriction, they stop and find out why. An agent doesn’t know the platform, so it retries until it finishes the task it was given — even as the API returns RESOURCE_EXHAUSTED. The task doesn’t complete, you get rework, and you wait for the quota to reset.

Repeat that pattern and the consequence is documented in Google’s API policies: “downgrading your status from Standard Access to Basic Access, imposing other quota limits on your Google Ads API usage, or termination of your Google Ads API token.” Google may also revoke a token unused for 90 consecutive days. The API Terms add: “You must not attempt to exceed automated use-quota restrictions.”

What actually gets an account banned — the policy, not the tool

Put the three together and the rule is simple: Google enforces against unauthorized access and against non-compliant ads. An MCP is neither — it is authorized access by definition. What it can do is produce non-compliant ads faster than a human would, if nobody is reading them.

It’s worth being honest about the evidence, because most of what circulates on this topic isn’t sourced. Claims like “the platform fingerprints your browser’s JavaScript variables” or “high error rate per token is the signal that flags you” appear confidently in article after article with nothing behind them — no platform statement, no documentation. They may well be true. They are not documented, and you should treat them as community reports rather than rules.

What is documented, and linked above: the prohibition on automated access and identity masking, the advertising policies your ad copy must satisfy, the access levels and their operation limits, and the escalation path from downgrade to token termination. That is the whole enforceable surface. Everything else is inference.

The three ways to connect Google Ads to AI

Each option carries a different combination of the three risks. There is no universally right answer — it depends on whether you need to read, or to act. For the setup walkthrough of each, see our guide to the Google Ads connector.

Option 1 — The official Google Ads MCP (read-only)

Google’s own open-source server. It sounds like the obvious choice: first-party, no intermediaries. Two things to know before you invest the setup time.

It is read-only. It exposes three tools — list_accessible_customers, search (GAQL queries) and get_resource_metadata — and Google’s launch post is explicit: “it can be used for reporting and diagnostics but will not make changes to your account.” If your goal is to create campaigns, the setup work buys you nothing.

The setup is genuinely hard. You need a Google Cloud project with the API enabled, a developer token approved beyond test-account access, and OAuth 2.0 credentials or a service account. Approval isn’t immediate or automatic, and a rejected application means fixing it and starting over.

Option 2 — A direct Google Ads API connection (read + write)

Same developer token requirement, but once you’re connected through the API you have write access: create campaigns and ads, apply changes, not just query data.

Two trade-offs. You’ll largely be working from the terminal with your AI, which is rough going if you’re not technical. And the rate limits are now yours — everything in Risk 3 lands on your token, and you have to teach the connection to back off rather than retry into a wall.

Option 3 — A hosted MCP with no developer token

A managed server that connects through the official API on your behalf, so you skip the developer token application entirely and connect from Claude, ChatGPT or any MCP client with an OAuth sign-in. If you want the step-by-step, we cover every method in 4 ways to connect Google Ads to Claude.

The question worth asking any vendor in this category — and most of them dodge it — is whose developer token your calls run under, and at what access level. Google’s API policies are specific: a tool’s end users “will need to manually sign in to use your tool, rather than having automatic access,” and providers can’t offer indirect token access that lets customers circumvent Google’s Required Minimum Functionality. A legitimate hosted tool holds its own reviewed token and signs you in with OAuth. Ask, and expect a straight answer.

Here is how Porter Metrics handles each of the three risks, so you can compare it against whatever else you’re evaluating:

How to connect safely: the checklist

Based on Google’s documented limits and policies — linked throughout this article — not on guesswork.

1. Never automate the Google Ads interface. No browser agents, no headless Chrome, no RPA on ads.google.com. This is the one behavior named in the Terms. Use the API instead.
2. Keep a human on the publish step. Have campaigns created paused and review the copy before anything goes live. This is what separates “automated drafting” from “unreviewed claims.”
3. Start read-only. Run analysis and reporting first, and enable write actions once you trust the setup. Reads almost never approach quota limits.
4. Know your access level before you batch. Explorer is 2,880 operations a day against production accounts; Basic is 15,000. Bulk changes are where you’ll find that number.
5. Make the agent back off, not retry. On RESOURCE_EXHAUSTED, stop and wait for the reset. An agent that retries into a limit is what turns a quota error into a token downgrade.
6. Check whose token you’re using. If you’re on a hosted MCP, ask the vendor whose developer token the calls run under and at what access level. If you can’t get a clear answer, that’s the answer.

What to do if your account is already suspended

First, work out which of the three actually happened, because the remedies are unrelated.

Frequently asked questions