Google Ads MCP Server: What Claude Can (and Cannot) Actually Do

Almost every article on this topic gives you the same two pieces of advice: keep it read-only for safety, and watch out for API quotas. Both are wrong — not slightly wrong, but backwards. Google ships an official Google Ads MCP server that cannot write at all, so read-only is not a discipline you impose, it is the floor you would have to climb down from. And quotas are almost never what breaks: a single Google Ads query counts as one operation no matter how many rows come back. The thing that actually bites you is your context window, because Google’s server streams every matching row into it and applies no default row cap. Here is the version grounded in the source code, as of July 2026.

What a Google Ads MCP server actually does

The Model Context Protocol is an open protocol Anthropic announced and open-sourced on 25 November 2024 for connecting AI assistants to external systems. The architecture is client-server: an MCP host — Claude Code, Claude Desktop, your own app — spins up one MCP client per server, each holding a dedicated connection. Servers expose three primitives: Tools (functions the model can call), Resources (contextual data), and Prompts (reusable templates). The current spec version is 2025-11-25. If you want the fuller treatment of why this exists at all rather than just calling the REST endpoint yourself, we wrote that up in MCP vs API.

A Google Ads MCP server, then, is a small program that translates the Google Ads API into that tool surface. You ask Claude a question in English. Claude decides it needs data, calls a tool, the server turns that into a GAQL query against the Google Ads API, and the rows come back into the conversation. The model then reasons over them. That is the whole trick — there is no magic, and importantly, no intelligence in the server itself.

What this buys you is the removal of the GAQL-writing step and the copy-paste step. What it costs you is discussed below, and it is not what you have been told.

Google ships an official one, and that is the story

The most common framing of this keyword — which Google Ads MCP server should I pick? — has a boring answer that most posts bury. Google publishes one itself: googleads/google-ads-mcp, Apache-2.0, created 3 October 2025, actively maintained (roughly 744 stars and 191 forks when we looked in July 2026, last push 2026-07-13). It is documented in Google’s own Google Ads API developer toolkit.

And it is strictly read-only. Google’s documentation says so in as many words: the implementation cannot modify bids, pause campaigns, or create new assets. The docs list the mode as read-only for the current release.

This is why the standard advice is backwards. Every competing article frames read-only as a discipline you must impose on your setup — a checkbox to find, a config flag to set. There is nothing to set. The server exposes exactly three tools:

• list_accessible_customers — which accounts your login can reach.
• search — run a GAQL query and get rows back.
• get_resource_metadata — ask what fields a resource exposes before you query it.

All three are declared read-only at the protocol level, and there is no mutate operation anywhere in the codebase. So the decision you actually face is the inverse of the one you were sold: do you leave this safe default for a write-capable third party? Treat read-only as a stay-put rule, not a setup step.

One honest caveat before you build a policy on it: Google wrote current release. That is a phrase with an expiry date on it. Check the repo, not this article, before you tell your compliance team the server can never write.

readOnlyHint is a label, not a lock

Here is the distinction nobody writing about Google Ads MCP is making, and it separates understanding the safety model from reciting it. Google’s tools carry the MCP readOnlyHint=True annotation. That annotation is a hint. The specification is unambiguous: for trust, safety and security, clients must consider tool annotations to be untrusted unless they come from trusted servers. A hostile server can set readOnlyHint=True on a tool that deletes your campaigns and the protocol will not stop it.

What actually enforces read-only on Google’s server is two things that have nothing to do with the annotation: no mutate tools exist to call, and the OAuth scope on your credentials. The annotation only helps a client decide whether to bother prompting you. The spec also states that there should always be a human in the loop with the ability to deny tool invocations — which is the layer you should actually be relying on, and a good reason to read how permission prompts work in Claude Code before you wire an ad account into anything.

What Claude can and cannot do, precisely

This table is built from the three-tool surface plus verified vendor write capability — not from vendor marketing. Vendor-dependent means we could not verify it from a primary source.

That last row deserves its own sentence, because “the AI might hallucinate” is usually waved at vaguely. Be precise: the model does not invent the rows. search returns real GAQL results from your real account. What it does invent — or rather, compute unverified in prose — are the derived numbers: the CPA, the ROAS, the week-over-week delta, the “this campaign is down 23%”. Those are arithmetic steps happening in a language model with no calculator attached. The rule: trust the pulled rows, verify the math. And keep Google’s own README warning in view — the MCP server will expose your data to the agent or LLM that you connect to it.

Two auth systems, not one

Nearly every post on this topic conflates MCP’s OAuth with Google’s OAuth. They are different systems and they apply at different places. Getting this right is the difference between debugging your setup in ten minutes and in three hours.

MCP’s authorization specification is built on OAuth 2.1 — and it applies only to HTTP transports. The spec says it directly: implementations using a stdio transport should not follow that specification, and should instead retrieve credentials from the environment. Since the standard local Google Ads MCP setup runs over stdio as a child process on your machine, MCP OAuth is not in the picture at all. What authenticates is Google’s own OAuth to the Google Ads API, plus a developer token. MCP’s OAuth only enters if you deploy the server remotely over Streamable HTTP behind the FastMCP OAuth proxy Google’s repo supports.

Setup shape, then, is three ingredients per Google’s README: a developer token at Explorer access level or higher, a Google Cloud project with the Google Ads API enabled, and OAuth 2.0 credentials (client ID and secret, or Application Default Credentials) carrying the adwords scope. The README shows a pipx run invocation straight from the Git repo. We are deliberately not reprinting the exact string: this repo is nine months old with 191 forks and a push last week — tool names, parameter shapes and install commands are all live surfaces. Read the README.

One tier note, because a lot of older writing is stale here: the access levels are Test / Explorer / Basic / Standard. Explorer is the newer entry tier the MCP server requires as a minimum. Articles that describe only Test/Basic/Standard predate this.

The real limit is your context window, not the quota

Now the second inversion, and the practical one. Every article on this keyword lists “API quotas” as the constraint. It is almost never true.

Google’s documentation states that a single query or report is counted as one operation regardless of the result being paged or streamed. One operation. So a query pulling three rows and a query pulling three hundred thousand rows cost you exactly the same against the cap. And the caps: Explorer allows 2,880 production operations per day (15,000 against test accounts). Basic allows 15,000 both ways. Standard is unlimited. A busy afternoon of conversational analysis might spend forty. You are not going to hit the quota in chat.

The exceptions are real but narrow: Explorer tokens are restricted from planning services entirely, and services like keyword idea generation carry their own much tighter per-account rate caps. If you were expecting keyword research through MCP, that is where you will actually meet a wall — not on reporting.

What does break is the context window, and the mechanism is visible in Google’s source. The search tool calls search_stream. Google’s own docs describe SearchStream as sending a single request and initiating a persistent connection regardless of report size — it does not paginate (plain Search, by contrast, pages at 10,000 rows). The MCP server then appends every row from every batch into one list with no truncation. And its signature is limit: int | None = None, appending a LIMIT clause only if you passed one. There is no default row cap.

Put those together and the failure mode is clear. It is not a 429. It is a single careless “show me all campaign performance this year” on an account that supports up to 10,000 campaigns, quietly streaming the entire result set into a 1M-token context at real per-token rates. Claude Opus 4.8 is $5/MTok input as of July 2026; Opus 4.8 and Sonnet 5 both offer a 1M-token context window at standard pricing, which means there is a lot of room to fill before anything errors out. Nothing warns you. The bill does.

We are not going to invent an arithmetic example here — row width varies enormously with your selected fields, and fabricating a “50k rows = $12” figure would reproduce exactly the hallucination failure this article warns about. The structural claims are what matter, and they are enough:

The rule: always put an explicit LIMIT and a finite date range in the request. Not because the API demands it, but because the server will not add one for you.

Say it in the prompt — “top 50 campaigns by cost, last 30 days” — and you have capped the blast radius before the model ever composes the query. If you are running this pattern at any volume, the broader playbook in how to cut LLM API costs applies directly: the cheapest token is the one you never put in the window.

The tool tax: ~1,600 tokens before any data moves

There is a third cost nobody mentions, and we measured it ourselves. Google builds the runtime description of the search tool by concatenating a docstring, a hints block, and its gaql_resources.txt file verbatim — a list of 179 GAQL resource names (as of July 2026; that count will drift as Google adds Ads API resources). The whole description lands at 5,674 characters.

Read that estimate honestly: it is a character count converted with Anthropic’s own rough rule of thumb — for Claude, a token approximately represents 3.5 English characters, though the exact number varies with the language used. It is not a tokenizer output. And it undercounts on current models: Anthropic notes that Claude Opus 4.7 and later, along with Sonnet 5, use a newer tokenizer that produces roughly 30% more tokens for the same text than earlier models. So call it ~1,600 tokens, minimum, floor not ceiling.

Is that a lot? Not on its own. But it is fixed, it recurs, and it is context you cannot use for anything else. Google evidently agrees it matters: the repo ships a smoke test that compares token usage against stored baselines and fails when usage rises more than a 5% threshold, with a source comment about truncating descriptions to avoid hitting token limits with massive tool docs. The server also appends PARAMETERS omit_unselected_resource_names=true to every GAQL query — an explicit output-trimming measure whose only purpose is fewer returned tokens. When the vendor is writing regression tests against its own tool description length, that is a signal about where the cost lives. This is the same tension we walked through in picking a model for agent work: tool surface area is context, and context is the budget.

Which Google Ads MCP servers actually exist

This ecosystem is full of listicles that name servers which do not exist, or which exist but do something else. We checked each one against a primary source. Naming discipline, in descending order of confidence:

• Google — googleads/google-ads-mcp. Official, Apache-2.0, read-only, actively maintained. This is the default and the answer for most people.
• Supermetrics. Real MCP server, covers Google Ads among many sources, and genuinely write-capable — its docs describe creating or modifying campaigns, with new campaigns starting paused so you can review before going live. Requires a Supermetrics subscription with API access.
• Windsor.ai. Ships a hosted Google Ads MCP, connected via a Windsor API key or OAuth 2.0, positioned around cross-source querying. Medium confidence — verified from the vendor’s own docs.
• gomarble-ai/google-ads-mcp-server. MIT, ~135 stars, last pushed December 2025. Exists and is reasonably fresh.
• cohnen/mcp-google-ads. MIT, ~668 stars — popular enough to look like a safe bet, but last pushed 16 October 2025, roughly nine months stale as of July 2026. The Google Ads API ships breaking versioned releases. Popularity is a lagging indicator here; we would not build on it without checking what has drifted.

And two corrections that will save you an embarrassing recommendation:

Semrush is not a Google Ads MCP server. Semrush’s MCP is real, official, and good — Streamable HTTP, OAuth 2.1 or API key, largely read-only. But it exposes Semrush’s own Trends, SEO and Projects datasets. It does not connect to your Google Ads account. It appears on Google Ads MCP listicles constantly and it does not belong there.

Pipeboard’s Google Ads server we could not verify. Its Meta Ads MCP is real, popular and active. Its GitHub org contains no Google Ads MCP repository. The Google Ads claim is hosted and closed; we found no primary source. We are not naming it as one.

One more on sourcing hygiene: several of the “best ad MCP servers” rankings circulating right now are published by Adspirer — ranking Adspirer. Adspirer does exist and claims a write-capable multi-platform ad MCP with safety rails, but every ranking we traced leads back to that same self-interested page, which manufactures a false impression of corroboration across search results. Treat any Adspirer capability or competitor claim as vendor marketing, not evidence.

When not to bother

The honest answer to “should I use a Google Ads MCP server?” depends entirely on one axis: is the question different every time?

Good fit — ad-hoc conversational analysis. You are poking at something. You do not know what you are looking for yet. Each query is different, you would otherwise be writing GAQL by hand and pasting into a spreadsheet, and the ~1,600-token overhead amortises across a real investigation. This is where MCP earns its keep, and where the exploratory loop genuinely beats the UI.

Bad fit — scheduled bulk reporting. You run the same shaped report every Monday. Here MCP is strictly worse than the boring path: an export plus a pivot table costs zero tokens, cannot hallucinate an average, is reproducible, and does not stream a five-figure row count through a language model to produce a number a SUM would have produced exactly. The fixed per-conversation tool overhead plus unbounded row streaming makes this the wrong tool. Use the export.

The middle ground worth naming: if you want repeatable and conversational, the right shape is usually a thin deterministic layer that fetches bounded data on a schedule, and a model that reads the summary. That is a skills-and-scripts problem more than an MCP problem, and it is the same architectural instinct behind putting a gateway in front of your models — keep the deterministic parts deterministic, and spend model tokens only where judgement is actually required.

FAQ