Google Ads MCP Servers Compared (2026)

A Google Ads MCP server is a program that exposes Google Ads API operations as MCP (Model Context Protocol) tools, so any compatible AI client — Claude, ChatGPT/Codex, Cursor, Windsurf — can read campaigns, run audits, and apply changes through natural language. As of April 2026 there are a handful of public options. Most are thin API wrappers; one or two ship the production-grade pieces (OAuth, guardrails, change history) you actually need to run on a live account.

We build NotFair, so this is not a neutral review. What follows is the most honest read we can give: the criteria that matter for a Google Ads MCP server, where each option lands, and which one is right for which job. We will tell you when something else is the better choice.

What a Google Ads MCP server actually has to do

It is easy to write a 200-line MCP server that wraps a few Google Ads API endpoints. It is much harder to ship one that is safe to point Claude at on Monday morning. Six things separate a demo from a production-ready server:

• OAuth and developer token handling — Google Ads API requires a developer token (1–2 week approval) plus OAuth. A good server hides both behind a single sign-in.
• GAQL fan-out — real audits hit 10+ reports (campaigns, search terms, quality scores, change events). Issuing them sequentially is slow and burns token budget. The server should support parallel GAQL.
• Write-side guardrails — the model must not be able to delete a campaign because of a misread instruction. Approval gates, dry runs, and undo are required, not optional.
• Change history and rollback — every write should be logged with enough context to undo it in one call. Standard Google Ads change history is not enough.
• Manager (MCC) account support — agencies and most mid-market accounts run under an MCC. The server has to enumerate clients via login-customer-id and let users pick.
• Multi-client transport — Claude Desktop wants HTTP/SSE, Claude Code wants stdio, Cursor wants stdio with config, ChatGPT/Codex wants HTTP. A useful server speaks all of them.

Most of the open-source servers on GitHub today cover items 1–2 and stop. That is fine for read-only experimentation. It is not fine for a media buyer running optimizations against a live account.

The current landscape

NotFair (hosted)

NotFair is the MCP server we maintain. ~40 tools split across read (audits, search terms, change history, recommendations) and write (pause, bulk update bids, negatives, RSAs, budgets, bidding strategies). One sandboxed runScript tool runs JS with ads.gaql() and ads.gaqlParallel() so a single audit pass can fan out 20 GAQL queries and correlate them in-script. Hosted at notfair.co/api/mcp with a one-click OAuth flow that handles the developer token. Hosted only today — self-host is not a supported distribution.

• Best for — anyone who wants to be auditing a real account in 5 minutes without standing up infrastructure.
• Skip if — you have a hard policy against hosted MCP servers and need every byte of auth state inside your own VPC.

Community open-source MCP wrappers

Several individual developers have published Google Ads MCP servers on GitHub since late 2024. Quality varies — some are well-engineered single-developer projects; others are 200-line proofs of concept. Common pattern: thin wrappers around the official googleads-python-lib or google-ads-node, exposing 5–10 tools, expecting you to bring your own developer token and OAuth refresh token.

• Best for — developers who already have an approved developer token, want full code control, and only need read tools.
• Skip if — you do not want to apply for a Google developer token, or you need write-side guardrails out of the box.

Roll-your-own with the Google Ads API

If you are an engineering team with strong opinions about MCP shape and want exactly the tools you want, you can build directly on the Google Ads API and the official MCP SDK (TypeScript or Python). Realistic effort: 2–4 weeks for a credible v1 with auth, GAQL helpers, and a handful of write tools — plus the Google developer token application that runs in parallel.

• Best for — agencies or in-house teams who need bespoke tools, custom guardrails, or to integrate the MCP into a larger product.
• Skip if — your team does not need bespoke logic. The marginal value over forking an open-source server is usually negative.

Decision matrix: which server should you use?

• Solo marketer or agency owner who wants to use Claude on Monday — NotFair hosted. Five-minute setup beats two weeks of Google approval every time.
• In-house growth team running multiple accounts under an MCC — NotFair hosted, with the MCC selected during connect. Re-auth once, manage many clients.
• Engineer evaluating MCP for a side project — community open-source server. Lowest commitment, easiest to fork.
• Agency building a proprietary internal tool on top of MCP — roll-your-own with the Google Ads API and the official MCP SDK. NotFair is hosted-only today.
• Compliance-bound enterprise — roll-your-own inside your VPC, with your own Google developer token. The infra cost is justified by the data-residency requirement.

What to look for in any MCP server you evaluate

Independent of which path you take, here is the checklist we use when reviewing other people's MCP servers:

• Tool surface area — does it cover both read and write, or only read? A read-only server is a research toy, not a workflow tool.
• GAQL access — can the server execute arbitrary GAQL, or only the report shapes the author thought to expose? Arbitrary GAQL is a 10x multiplier for what Claude can do.
• Parallel queries — can it batch GAQL calls? Without parallelism, audits hit token-budget limits before they finish.
• Approval flow on writes — does it require explicit confirmation for destructive operations, or does it just YOLO whatever the model says? Production servers require confirmation.
• Change log and undo — is there a server-side change history that can be queried ("what did Claude change this week?") and rolled back? If not, your account has no audit trail.
• Error surfaces — does the server return Google Ads API errors verbatim, or wrap them with helpful context? "AUTHENTICATION_ERROR" with no extra info is a debugging nightmare.
• Transport coverage — does it support stdio (Claude Code, Cursor), HTTP/SSE (Claude Desktop, ChatGPT/Codex), or both?
• License and source visibility — even hosted servers should have public source for the parts that touch your auth tokens. "Trust us" is not a security posture.

Common mistakes when picking a Google Ads MCP

• Optimizing for tool count — "100+ tools" sounds impressive but it is mostly noise. A small set of well-designed tools (with one sandboxed GAQL escape hatch) outperforms a hundred narrow endpoints.
• Skipping the developer-token question — the Google Ads API requires an approved developer token. If a server does not provide one, you have to apply for your own. Plan for that or pick a server that handles it.
• Ignoring write guardrails — the most common AI ads incident we have seen is a model bulk-pausing campaigns based on misread context. A server without approval gates makes this 10x more likely.
• Treating MCP as a Claude-only thing — MCP is an open standard. The same server should work with ChatGPT/Codex, Cursor, and Windsurf. If a server is Claude-locked, that is a signal of immaturity.
• Confusing MCP with Google's own AI features — Smart Bidding and Performance Max are inside Google Ads. An MCP server is the thing that makes your AI assistant outside Google Ads (Claude, ChatGPT) able to read and act on your account. They are complementary, not competing.

How to get started in 5 minutes

If you want to skip the comparison and just try it, the fastest path is the NotFair hosted server. Sign in at notfair.co/connect with the Google account that has Ads access, pick which customer IDs Claude (or ChatGPT, or Cursor) should see, and copy the connector config into your client of choice. The connect page has a tab per client with the exact config snippet for each.

If you need an MCP server inside your own infrastructure, NotFair is hosted-only today — there is no published self-host distribution. The two real options are to fork an open-source community wrapper from GitHub and bring your own Google developer token, or to roll your own on top of the Google Ads API and the official MCP SDK. Both routes assume engineering capacity. Most teams who think they want self-host find the hosted server clears their threat model after they read its OAuth scope and revocation story.

FAQ