On April 28, 2026, Google shipped an official MCP (Model Context Protocol) server for the Google Ads API, letting an AI assistant query your ad account in plain language for the first time without writing a line of integration code (Google Ads API docs). But Google made one choice that defines the whole thing and that most write-ups bury: the server is strictly read-only. It can read every metric, budget, and status in your account — and it cannot pause a campaign, change a bid, or create an asset. By design.
This is the complete guide to the Google Ads MCP — what it is, the two tools and the GAQL layer underneath, how to set it up, the connector landscape, the honest limits, and the read-only-vs-Meta contrast that explains the whole design. Each section gives you the map; where you want the full treatment, we link to the deep dive. If you want the strategic read on what a read-only first-party connector means for AI ad teams, start with Google's Official Ads MCP: What It Means for AI Ad Teams.
What the Google Ads MCP is, in 30 seconds
- What shipped: an official MCP server for the Google Ads API, released April 28, 2026, that exposes the API to MCP-compatible AI hosts.
- How big: a deliberately small surface — 2 core tools (
list_accessible_customersandsearch), wheresearchruns GAQL (Google Ads Query Language) against your account. A companionget_resource_metadatahelps the model discover field names. - The defining constraint: it is strictly read-only — "it cannot modify bids, pause campaigns, or create new assets."
- The setup tax: unlike Meta's one-click OAuth, Google requires a developer token, a Google Cloud project with the Ads API enabled, and OAuth credentials — the same gate the Google Ads API always had.
The headline isn't "ask Gemini about your campaigns." It's the operating-model choice. Meta shipped a read-and-write MCP and leaned on a created-paused convention plus your discipline to keep it safe. Google shipped a connector where the agent structurally cannot spend — the safety gate is the API itself, not a convention you have to remember to honor. That contrast runs through every section below.
The two tools and the GAQL layer
Where Meta's MCP gives an agent 29 named verbs, Google's gives it essentially one workhorse and a directory (Google Ads API docs):
| Tool | What it does |
|---|---|
list_accessible_customers | Returns the Google Ads customer IDs and account names the authenticated user can reach — the discovery call an agent makes first. |
search | The workhorse. Executes a GAQL query for metrics, budgets, and status across any reporting resource (campaign, ad group, keyword, asset, etc.). |
get_resource_metadata | Returns metadata about a resource type (e.g. campaign) so the model can pick valid fields instead of guessing column names. |
This is a thinner, more powerful design than 29 fixed tools, because GAQL is the API's full query language. One search tool can answer almost any reporting question — "show me campaigns where ROAS dropped week over week," "list keywords above target CPA," "which assets have a LOW ad strength" — by composing a SQL-like query, no new tool needed per question. The trade-off: the model has to write valid GAQL, which is why get_resource_metadata exists and why a community fork (google-marketing-solutions/google_ads_mcp) adds helper tools like get_gaql_doc and get_reporting_fields_doc to teach the model the schema. Expressive surface, steeper accuracy curve — that's the deal.
Setup: the developer-token wall is the real friction
This is where Google and Meta diverge most. Meta's setup is a Business OAuth click. Google's MCP inherits the full Google Ads API onboarding, and skipping any piece means the server won't return data (digitalapplied setup guide):
- Get a developer token — a 22-character string from the Google Ads UI under Tools & Settings → API Center.
- Apply for Standard access. Basic access works for testing but throttles queries and is limited to test accounts; production GAQL work needs Standard access, and approvals take 1–2 business days for agency accounts with active spend.
- Create a Google Cloud project with the Google Ads API enabled.
- Set up OAuth credentials (Client ID/Secret for solo users) or a service account JSON key (more resilient for teams — refresh tokens can be revoked and force a re-consent).
- Install and wire the server — typically via
pipx, then point your MCP client's config at it withGOOGLE_PROJECT_IDandGOOGLE_ADS_DEVELOPER_TOKENenv vars. The supported clients are Claude Desktop, Claude Code, Gemini CLI, Cursor, and Windsurf.
The honest friction: switching auth mode (OAuth → service account) means reconfiguring every client, and that 1–2-day token approval is a hard gate you can't engineer around. The full, copy-pasteable walkthrough — every env var, the GCP steps, and the client JSON blocks — is in the Google Ads MCP Setup Guide. If you're specifically on Claude (Desktop, Claude.ai, or Claude Code), the connect-Claude-to-Google-Ads guide covers the per-client config and the prompt patterns that get decisions instead of GAQL errors.
The read-only-vs-Meta contrast (the original frame)
The single most useful way to understand Google's MCP is to put it next to Meta's, because the two platforms made opposite bets about where the safety gate lives.
Meta's bet: write access with a soft gate. Meta's MCP exposes 29 tools including campaign, ad-set, and ad creation, behind a one-click Business OAuth. Everything an agent creates lands paused, and a human flips the switch — but that's a convention, and the CLI companion even creates active by default unless you pass --status PAUSED. The agent can spend; you trust the workflow not to.
Google's bet: no write access at all. The agent reads everything and writes nothing, full stop. There is no "remember to keep it paused," no scope-escalation footgun, no created-active gotcha — because the API rejects the write outright. The safety gate is moved from your discipline into the protocol. As Google's own docs put it, "the read-only boundary is the safety model."
Which is better depends entirely on what you want the agent to do:
| If you want… | Google read-only | Meta read-write |
|---|---|---|
| An agent that analyzes and recommends, never touches spend | Ideal — safety is guaranteed | Possible, but you enforce it |
| An agent that executes edits end-to-end | Not possible — writes go through a separate REST workflow | Built for it (with created-paused) |
| Lowest blast radius by default | Wins — structurally can't hurt you | Depends on your guardrails |
| Fastest to a live connection | Slower (token + GCP + OAuth) | Faster (one OAuth click) |
For ad teams, the practical read is that Google's MCP is a superb diagnostic and reporting brain that you pair with a separate, audited write path — while Meta's is a single connector that both observes and acts. Neither is strictly better; they imply different agent designs. The full head-to-head — tool-by-tool, setup-by-setup, and which to reach for by use case — is in Google Ads MCP vs Meta Ads MCP.
The connector landscape: official isn't the only option
Google's free server isn't the only Google Ads MCP, and for some teams it isn't the fastest path to value. Because the official server is read-only and carries the developer-token tax, a market of hosted and community connectors has grown around it (GoMarble, Adspirer):
- Official Google server — free, read-only, two tools, full GAQL power. Best when you want zero vendor in the loop and can pay the setup tax once.
- Community forks (e.g. google-marketing-solutions/google_ads_mcp) — add GAQL-helper tools to improve query accuracy; still read-only, still self-hosted.
- Hosted connectors (GoMarble, Pipeboard, Adspirer, Composio) — trade a subscription for skipping the developer-token and GCP setup, multi-platform auth (Google and Meta in one connection), and in some cases a write path Google's own server won't give you.
Setup time is the wrong headline metric — you connect a Google Ads MCP once, then live with its auth model, data scope, and agent fit for as long as you run it. The full field, ranked by what actually matters (data coverage, agent fit, auth resilience, cost, setup), is in Best MCP Servers for Google Ads, Ranked.
The honest limitations (read before you trust it)
This is where most page-one articles go thin. The consolidated list:
- It cannot do anything. Worth restating: it's strictly read-only. Any "the agent optimized my campaigns" workflow needs a separate, non-MCP write path. The MCP recommends; it never executes.
- GAQL accuracy isn't free. With only a
searchtool, every answer is a model-written GAQL query. A wrong field name or a missing date segment yields an error or — worse — confidently wrong numbers. Pin date ranges and verify schema; this is why helper-tool forks exist. - The developer-token gate is real. Basic access is test-accounts-only and throttled; Standard access takes 1–2 business days to approve. You can't query production data until it clears.
- It can't see your creative. Like Meta's, the tools read structured fields and metrics, not images, video, or landing-page experience — no judgment on the creative itself, only on its numbers.
- No access to Google's optimization brain. Smart Bidding internals, Performance Max asset selection, and the auction are off-limits. The agent reads outcomes, not the algorithm.
- Auth is brittle for solo OAuth. Refresh tokens can be revoked and force a re-consent; teams should prefer service-account auth, but switching modes means reconfiguring every client.
The upside of the read-only design is that limitation #1 makes the rest low-stakes: an agent that can't write can't cost you anything beyond a wrong recommendation you choose to ignore. That's the whole point of where Google put the gate.
The agent operating model the tools imply
A two-tool, read-only, GAQL-driven connector implies a very specific agent — a diagnostician, not an operator. The loop that follows:
- Connect once, at the account scope you need. Developer token + OAuth (or service account), Standard access for production. There is no "scope tier" decision the way Meta has — read-only is the only mode.
- Ask in plain language; let GAQL do the work. "Which campaigns lost impression share to budget last week?" becomes a
searchquery. Always pin the date range and breakdown so the model can't backfill a hallucinated number. - Get a recommendation, then act through your own gated write path. The MCP hands you the diagnosis; a human (or a separate, audited automation) makes the change in Google Ads. Nothing the MCP touches can move spend.
The point: because the connector gives everyone the same read-only verbs, the value isn't access — it's the judgment in the questions you ask and the discipline of the write path you pair it with. Read access is table stakes; a trustworthy act-on-it workflow is the moat.
How Soku fits
Soku is itself an ad-automation agent with a human-in-the-loop approval model, so it treats Google's read-only MCP as exactly what it's good for — the diagnostic layer — and supplies the part Google's server deliberately leaves out: a gated write path. From Settings → Integrations, the Google Ads card sits under Bring Your Own alongside Meta Ads, GA4, and TikTok, and connecting runs the OAuth flow once.
After you connect, Soku reads your account the way the MCP does — GAQL under the hood, plain-language questions on top — surfaces the anomalies and recommendations, and then routes any change through an approval gate where a human signs off before a single edit reaches the account. You assign each ad account to one or more brands, so one agent operates a whole client roster without ever pointing the wrong account at the wrong brand. The read-only MCP gives an assistant the Google verbs; the agent layer decides which account belongs to which brand, keeps a human gate on spend, and enforces the read→diagnose→approve→act discipline above.
Where to go next
This page is the map. For the full treatment of each sub-topic, follow the deep dive that matches your intent:
- Understand what it changes → Google's Official Ads MCP: What It Means for AI Ad Teams — the strategic read on a read-only first-party connector and how it reshapes the ad-team workflow.
- Set it up, any client → Google Ads MCP Setup Guide — developer token, GCP project, OAuth vs service account, install, and the client config blocks, step by step.
- Connect through Claude → How to Connect Claude to Google Ads — Claude Desktop / Claude.ai / Claude Code config and the prompt patterns that get clean GAQL.
- Pick the right connector → Best MCP Servers for Google Ads, Ranked — official vs. community forks vs. hosted connectors, weighted by what actually matters.
- Compare it to Meta → Google Ads MCP vs Meta Ads MCP — the read-only-vs-read-write head-to-head, tool by tool.
- Doing Meta too? → Meta Ads MCP: The Complete Guide — the sister pillar for Meta's 29-tool, read-and-write connector.
FAQ
What is the Google Ads MCP?
An official MCP server Google released on April 28, 2026, that exposes the Google Ads API to AI assistants through two core tools — list_accessible_customers and a GAQL-powered search — so an agent can query your account in plain language. It is strictly read-only.
Is the Google Ads MCP read-only?
Yes. Per Google's docs it is strictly read-only and "cannot modify bids, pause campaigns, or create new assets." Any write must go through a separate REST workflow outside the MCP. That read-only boundary is the safety model.
How is it different from the Meta Ads MCP?
Google's MCP is read-only with 2 tools and a developer-token + GCP + OAuth setup; Meta's is read-and-write with 29 tools and a one-click Business OAuth. Google moves the safety gate into the API; Meta relies on created-paused plus your discipline. Full comparison here.
What do I need to set it up?
A 22-character developer token (with Standard access for production — 1–2 business days to approve), a Google Cloud project with the Ads API enabled, and OAuth or service-account credentials. Step-by-step in the setup guide.
Which AI clients does it work with?
Claude Desktop, Claude Code, Gemini CLI, Cursor, and Windsurf — each with a different config path but the same server logic. For Claude specifically, see the connect guide.
