What connecting Google Ads to Claude actually does
Claude does not natively log into your ad accounts and start pulling reporting on its own. To work with live Google Ads data, it needs an integration layer that can authenticate with Google Ads, retrieve the right objects and metrics, and pass them into Claude as structured context or tool calls. MCP Ads is that layer.
A basic file upload gives Claude a snapshot. A proper connection gives it ongoing access to campaign, ad group, keyword, search term, and conversion data based on the permissions you configure. For operators who need repeatable analysis, that is the difference between a one-off prompt and a usable workflow.
In practice, connecting Google Ads to Claude lets you use natural language to inspect performance, compare date ranges, identify outliers, and build reporting outputs faster — and to combine that with GA4 or Search Console data when a question spans more than one channel.
How to connect Google Ads to Claude, step by step
The setup is the same whether you manage one account or fifty — only the scope decisions change.
- Confirm which account you need connected: a single account is simple, an MCC requires deciding whether Claude needs one child account, several, or the manager hierarchy.
- Confirm you have the right permissions: administrative or standard access in Google Ads, plus authority to approve the connection.
- Authenticate through MCP Ads using browser-based OAuth — no client IDs or secrets to paste anywhere.
- Select which account or accounts should be exposed to Claude; keep scope tight for single-brand work, broader for portfolio reporting.
- Test the connection with a simple, verifiable prompt before moving to anything strategic.
What changes once Claude can inspect the account
With MCP Ads connected, Claude stops acting like a generic writing tool and starts acting more like an analyst with access. You can ask what changed, why CPA moved, where spend is leaking, or which search terms are drifting from intent.
Those are multi-signal questions. They are useful only when the model can read the account context instead of guessing from a copied summary. A connected workflow can support campaign trend analysis, ad group performance review, keyword and search term inspection, device and geo cuts, conversion summaries, budget pacing checks, and efficiency diagnostics.
- Campaign and ad-group analysis
- Search-term and negative-keyword reviews
- Budget pacing checks
- Change-history explanations
The first workflows worth standardizing
The fastest gain comes from standardizing three repeated prompts: one audit, one weekly summary, and one waste-detection flow. That gives you a reliable operating rhythm quickly, and it is the same rhythm agencies use to speed up reporting across multiple clients.
After that, the best prompts usually focus on search-term quality, budget pacing, and changes since the previous reporting window. Vague prompts get vague answers — "How are campaigns doing?" produces a generic summary, while "Compare non-brand search campaigns over the last 14 days vs the prior 14 days and identify the top three CPA increases with spend and conversion deltas" produces something you can act on.
- Audit my account and rank issues by likely impact
- Show me search terms wasting spend in the last 30 days
- Summarize the biggest performance change since last week
Common issues when connecting Google Ads to Claude
Most setup problems are operational, not technical. Authentication usually works — the friction comes from account complexity. A common issue is connecting through the wrong Google identity when you manage personal, agency, and client logins. Another is assuming manager-account access automatically exposes every child account you need.
A third is expecting Google Ads numbers to match another source perfectly without accounting for attribution model differences, conversion lag, or time zone settings. If the numbers Claude returns do not line up with what you see in the platform, the issue is almost always account scope, date logic, or a permissions gap — not the connection itself.
What the first result looks like
The first prompt worth running is the plainest one: "List my Google Ads accounts and give me an overview of the main one for the last 7 days." The response is not a table dump. Claude first lists the accounts the connection can see — each with its ten-digit customer ID, its descriptive name, its currency and time zone, and whether it is a manager account or a client account under one. If the login exposes a manager, the client accounts appear beneath it with the same details.
For the account you pick, the overview reads like a short analyst note. It opens with the totals for the period — spend, impressions, clicks, conversions, and the derived numbers: CTR, average CPC, cost per conversion, and conversion rate — followed by the same figures for the prior period so the direction is visible. Then it breaks the totals down by campaign, in order of spend, naming each campaign, its type (Search, Performance Max, Shopping, Display, Video), its status, its daily budget, and its bid strategy, and calling out anything that stands out: a campaign spending without converting, one capped by budget, one in a learning phase. It usually closes with two or three suggested next questions, which is the point where the real work starts.
Two things to check in that first response. The account ID should be the one you meant, not a test account or a different client with a similar name. And the totals should be within a few percent of what the Google Ads overview page shows for the same seven days in the account time zone. If both hold, the connection is right and every later answer can be trusted to the same degree.
Troubleshooting
The Google Ads API has a few failure modes that are not obvious from the error text. These are the ones that account for nearly every support conversation about this connection.
"Customer not enrolled" or "developer token not approved". Every call to the Google Ads API is made with a developer token, and that token has an access level: test, Basic, or Standard. A token at test level can only reach test accounts, and a request against a real account fails with a message about the customer not being enrolled or the token lacking access. With MCP Ads you never see this in the normal path, because the hosted server uses its own approved token; you will only meet it if you run a community Google Ads MCP server with your own developer token from a fresh manager account. The fix is to apply for Basic access in the API Center of the manager account and wait for approval; there is no way around the wait.
The account does not appear after connecting. This is almost always the wrong Google identity. Most people managing ads have several — a personal Gmail, an agency Workspace login, a client-provided user — and the OAuth consent screen uses whichever one the browser is already signed into. If the account list comes back empty or shows only accounts you do not recognize, disconnect, open the OAuth flow in a private window, and choose the identity that actually has access in Google Ads. Check the account access page in Google Ads too: an email that was invited but never accepted the invitation has no access, and neither will the connection made with it.
Manager (MCC) accounts and login-customer-id. When access to a client account comes through a manager account rather than directly, the API requires every request to carry the manager ID as login-customer-id alongside the client customer ID; without it the request fails with a permission error even though the identity plainly has access in the interface. MCP Ads resolves this by walking the manager hierarchy when you connect and storing the right manager for each client, so selecting the client account is enough. If you use your own server, set login-customer-id to the manager account that sits above the client, without dashes. Note also that a manager login sees the hierarchy, not necessarily every account: a client account linked to a different manager, or unlinked, will not appear until it is linked.
"A server with this url already exists" in Claude. This one is on the Claude side, not Google. Claude Code refuses to register a second MCP server pointing at a URL it already has under another name. Run claude mcp list to see what is registered, remove the stale entry with claude mcp remove and the name it shows, then add it again. In Claude Desktop and Claude.ai the equivalent is an existing custom connector for the same URL; edit or remove that one rather than adding a duplicate. The Claude MCP add guide covers the exact commands.
- Numbers do not match the interface: check the date range, the account time zone, and the conversion action set before suspecting the connection
- Tools are present but every call fails: the platform OAuth grant was revoked or expired; reconnect the account from the dashboard
- One client account is missing from a manager login: it is not linked to that manager, or the invitation is pending
- Reads work but writes are refused: the workspace role or policy does not permit write tools, which is by design until an owner enables them
When this setup makes sense, and when it does not
If your team actively manages spend, checks performance often, and needs fast answers from live campaign data, connecting Google Ads to Claude is a practical move — especially for multi-account teams and agencies blocked by fragmented platform access.
If you only need a static monthly report, a direct connection may be more than you need; exporting a file once a month can still be enough for low-frequency work. The practical test is simple: if your team keeps spending time retrieving Google Ads data before it can think about the data, the connection is probably worth making.
