AI ads infrastructure
Google Ads MCP Servers Compared (2026)
Compare Google's official server, NotFair, and self-hosted options by setup, tools, write access, safety, and operating burden.
Which Google Ads MCP is best for your task?
For self-managed reporting, start with Google’s official read-only server. For a marketer who wants live account analysis and reviewed changes through a published Claude connector, consider NotFair. For custom infrastructure or specialized tools, evaluate a maintained community project against your team’s operating requirements.
A Google Ads MCP server exposes account data and, in some cases, campaign operations as tools an AI client can call. In 2026, the choice is clearer than it used to be: Google offers a first-party, read-only server for local developer workflows; NotFair offers a hosted workflow for analysis plus explicitly approved changes; community and in-house servers trade more operational work for more control.
We build NotFair, so this is not a neutral review. We will be direct about where Google's official server is the better choice: if all you need is self-managed, read-only access to GAQL from a local environment, use it. This guide explains when the extra hosted workflow is worth it.
Documentation reviewed: September 5, 2026. This comparison covers three operating models, not an exhaustive vendor ranking: Google's official server, NotFair's hosted server, and a community or in-house self-hosted build. Product capabilities and MCP-client transport support change quickly; use the linked primary sources before you connect a production account.
What a Google Ads MCP server actually has to do
A useful comparison starts with the actual job. A read-only analysis server needs sound credentials and clear query results. A server that can change a live account also needs scoped access, explicit approvals, an audit trail, and a credible way to unwind a supported change.
- Credentials and setup — can the team use existing Google Ads API credentials, or do they need a hosted OAuth flow that handles the integration setup?
- Read scope — does it expose the account discovery and GAQL queries the analysis actually needs?
- Write safety — are campaign state, bid, budget, and keyword changes shown for explicit approval before they execute?
- Auditability — can you identify who changed what, see before/after values, and undo a supported operation?
- Account scoping — can an agency select the specific client accounts an assistant may touch rather than handing it a broad manager-account credential?
- Client fit — does the transport work with the AI client your team actually uses?
A server can be excellent at read-only research without being suitable for live account operations. Treat those as separate requirements rather than assuming a longer tool list makes a connector safer.
The current landscape
Google's official Google Ads MCP server
Google's Developer Toolkit documents a first-party Google Ads MCP server. Its current tools are read-only: discover accessible accounts, run GAQL search queries, and inspect Google Ads resource metadata. It is designed to run locally over stdio and expects you to supply a Google Ads developer token plus Google Cloud credentials.
- Best for — engineers and analytics teams that already have Google Ads API credentials and want a transparent, local, read-only way to query an account.
- Skip if — you need the agent to make campaign changes, want hosted account connection, or do not want to operate the credential setup yourself.
NotFair (hosted)
NotFair is the hosted MCP server we maintain. It connects the Google Ads accounts you select through OAuth, handles the Google Ads developer-token setup, and gives MCP-compatible clients a route from account diagnosis to reviewed actions. Read tools can investigate the account; write-capable tools surface a proposed change for explicit approval before it reaches Google Ads. Applied changes are recorded with provenance and before/after context, and supported changes include undo metadata. Teams managing more than Google can also use NotFair's platform-specific servers for Meta Ads, LinkedIn Ads, X Ads, Google Search Console, and Google Analytics. NotFair is hosted, not a self-host distribution.
- Best for — marketers and agencies who want to connect selected accounts, investigate with an AI client, and take reviewed action without maintaining Google Ads API infrastructure.
- Skip if — your policy requires local or VPC-only operation, or your work is strictly read-only and your team already runs Google's official server comfortably.
Community open-source MCP wrappers
Community projects remain useful for teams that want to inspect or change every part of the integration. Their scope varies substantially. Confirm the maintainer activity, credential model, account isolation, and the exact behavior of every mutation before using one against a production account.
- Best for — developers who want source-level control or bespoke tools and can own credentials, monitoring, and safety behavior.
- Skip if — you need a ready-to-use approval and operations-history workflow.
Roll-your-own with the Google Ads API
Build directly on the Google Ads API when the connector itself is part of your product or compliance boundary. That choice lets you define the tool surface and retention model, but it also makes your team responsible for credential handling, account isolation, approval behavior, logging, support, and every edge case in a live advertising API.
- 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.
Side-by-side: official, hosted, and self-hosted
| Option | Setup and transport | Read capabilities | Writes and controls | Operating burden |
|---|---|---|---|---|
| Google official server | Python server; stdio locally, with an option to deploy it as a web service. Bring a Google Ads developer token, project ID, and OAuth or application-default credentials. | list_accessible_customers, GAQL search, and get_resource_metadata. | Read-only in the current release. It cannot pause campaigns, change bids, or create assets. | Open source and self-managed. Best when an engineering owner already runs Google Ads API credentials. |
| NotFair hosted server | Hosted Streamable HTTP endpoint. Connect the Google Ads accounts you select through OAuth; NotFair handles the Google Ads developer-token setup. | Live account investigation through MCP-compatible clients, with Google Ads plus separate servers for other marketing platforms. | Supported writes are shown for explicit approval before execution. Operations record provenance and before/after values; undo is available where supported. | Hosted service. Best when a marketer or agency wants reviewed action without operating the API integration. |
| Community or in-house server | You choose the codebase, transport, cloud, credentials, and account-isolation model. | Varies by project. Verify GAQL coverage, manager-account behavior, and maintenance before relying on it. | Varies by implementation. You own approval UX, logging, undo behavior, and production safeguards. | Highest engineering and support burden. Best for self-hosting, bespoke workflows, or a strict data boundary. |
A concrete choice
If a data analyst wants to ask, “Which campaigns spent the most by device last week?”, Google's official server is the cleanest starting point. If a paid-media operator wants to ask, “Show the bid reduction for these two ad groups, then apply it only after I confirm,” choose a hosted server with scoped accounts, visible approval, and an operations record. If your team must keep credentials and code inside its own environment, accept the work of building those controls yourself.
Sources and verification
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:
- Read versus write — read-only may be exactly right. If writes are required, evaluate those tools separately rather than inferring safety from read access.
- Approval behavior — verify that the client shows the exact proposed change and requires confirmation before a write executes.
- Operations record — look for actor, target account, before/after values, timestamps, and undo support rather than a generic success message.
- Account boundaries — verify an assistant can access only the accounts the user selected.
- Credential ownership — understand who supplies the Google Ads developer token and what happens if a user revokes access.
- Transport and client support — confirm the server's transport works with your specific Claude, Codex, or IDE setup.
Common mistakes when picking a Google Ads MCP
- Calling an official server incomplete because it is read-only — that constraint is a feature when the job is analysis. Choose it deliberately instead of treating every connector as an automation platform.
- Skipping the developer-token question — Google's official server and many self-hosted projects require your own Google Ads API credentials. Establish who owns that operational burden before setup.
- Treating approval as a label — inspect what the user sees before a campaign, bid, or budget change runs, and verify that the operation log is useful after the fact.
- Giving an agent a broad manager-account credential by default — choose the client accounts it may access and keep the boundary narrow.
- Confusing an MCP server with Google's in-product automation — Smart Bidding and Performance Max live inside Google Ads. An MCP server lets an external AI client inspect and, where supported, act on the account.
How to get started in 5 minutes
For read-only analysis, follow Google's official Google Ads MCP Server documentation and run it with your own credentials. For a hosted reviewed-write workflow, sign in to NotFair with the Google identity that has Ads access, choose the customer accounts your AI client may see, and connect the NotFair server from your MCP-compatible client.
NotFair is hosted-only. If you need to operate the connector inside your own infrastructure, Google's official server is the simplest current starting point for read-only use. For custom write operations, use a maintained community project or build directly on the Google Ads API and make the approval, account-scoping, and audit requirements part of the design.
Move from article to live account work
Connect your account first, then use an MCP client to turn the article workflow into a reviewed account action.