Google Ads

How to Connect Claude Code to Google Ads and Meta Ads with MCP

The practical setup for connecting Claude Code to Google Ads and Meta Ads over MCP, including the credentials nobody tells you about until you are stuck.

MD Marek Dąbrowski · May 24, 2026
How to Connect Claude Code to Google Ads and Meta Ads with MCP, AdLume

Key takeaways

  • Meta's official Ads MCP is a hosted remote server that uses Meta's OAuth login, so you do not create your own developer app, app secret or tokens.
  • The Google Ads MCP server runs locally and needs real API credentials: a developer token, OAuth client ID and secret, and a refresh token in google-ads.yaml.
  • Start with read-only diagnostics; the Google Ads MCP server keeps mutation tools disabled by default, and that default is correct.
  • MCP only gives the agent access to tools; a harness with context, approval gates and verification turns that access into a repeatable workflow.

'

MCP is becoming the default way AI agents connect to advertising platforms.

AdLume

New version of AdLume launching soon

Join the waitlist and get notified when the new AdLume is ready. It catches wasted ad spend automatically and optimises campaigns around the clock.

One email, on the day access opens. Nothing else, and you can leave the list with one click.

That matters for performance marketers because Google Ads and Meta Ads are no longer just dashboards you inspect manually. They are becoming systems an AI agent can query, summarize, and in some cases modify through a controlled connector.

The basic idea is simple:

  • Google Ads or Meta Ads stays the system of record
  • an MCP server exposes selected tools and data to an AI client
  • Claude Code uses those tools during a session
  • the human still owns approval for risky changes

This guide shows the practical setup pattern for Claude Code, Google Ads, and Meta Ads. It also covers the part most setup guides skip: what should not be automated yet.

First, understand the MCP mental model

MCP stands for Model Context Protocol. Anthropic describes it as an open standard for connecting AI assistants to the systems where data lives.

For marketers, the translation is:

Instead of exporting CSVs, pasting screenshots, and explaining your account structure every time, you connect a tool layer once. Then Claude can ask that system for data when it needs context.

In Claude Code, MCP servers can be added as:

  • remote HTTP servers
  • remote SSE servers, though SSE is deprecated where HTTP exists
  • local stdio servers

For ad accounts, both patterns matter.

Meta's official connector is a hosted remote MCP server plus a CLI. Google's open Google Ads MCP implementation runs as a local server that wraps the Google Ads API.

Before you connect anything

The MCP setup path in three stages: getting credentials ready, connecting the server for Meta and Google Ads, and keeping everything read-only until the workflow is proven.

Do not start with writes. Start with read-only diagnostics. The first useful version of an AI ads workflow should answer questions like:

  • which campaigns changed most this week?
  • where did CPA or ROAS move?
  • which assets are fatigued?
  • are conversion signals healthy?
  • what should I review before changing budget?

It should not immediately.

  • launch campaigns
  • change budgets
  • pause ad sets
  • edit tracking
  • rewrite conversion actions
  • publish ads

The connector gives access. It does not give judgment.

Do you need a client_id for mcp.facebook.com/ads?

No. This is the most common point of confusion when connecting Meta's official ads MCP server, so it is worth stating plainly.

The endpoint below authenticates through Meta Business OAuth. You add the server, your browser opens a Meta login prompt, and you pick which ad accounts to authorize:

plaintext
https://mcp.facebook.com/ads

Meta's own documentation is explicit that the ads AI connectors need no developer credentials, API setup, or coding. There is no app to register, no app review, no access token to paste, and no client_id or oauth-client-id to provide.

If your MCP client is asking you for a client_id, one of these is usually true:

  • You are configuring a third-party Meta Ads MCP server rather than Meta's official endpoint. Community servers often run through your own Meta developer app, which does need an app ID and secret.
  • Your client is using a generic OAuth connector form that assumes every server needs registered credentials. Meta's endpoint does not.
  • You are looking at Google Ads instructions. The Google Ads API path is different, and that one does require a client_id (see the section below).

The client_id, client_secret and developer_token in this guide belong to the Google Ads configuration file. They are not used for Meta. Mixing the two is the fastest way to get stuck.

There is a fourth cause, and in 2026 it is the most common one.

If you are connecting from Claude Code or Codex rather than a desktop or web client, nothing asks you for a client_id at all. The connection dies on its own in under a second, before any browser window opens. The errors look like this:

plaintext
SDK auth failed: The provided redirect_uris are not registered for this client.
plaintext
Registration failed: Dynamic registration is not available for this client.

This has been reported repeatedly since late April 2026 and the reports are still open. Command line clients register themselves with the OAuth server on the fly, using a localhost address for the callback, and Meta's server does not accept that kind of registration. Nothing on your side fixes it: the hosted integration has one fixed identity and gives you no way to supply your own client id, client secret or callback port.

What to do instead.

  • Add the connector through your client's connector settings screen rather than the command line. In Claude that is Settings, then Connectors, then Add. This is the path that works today and the first thing to change if you are stuck.
  • If you need a terminal for scripted or bulk work, use Meta's own ads CLI rather than the MCP endpoint. It is built for exactly that.
  • If you must stay inside a command line client, a third-party Meta MCP server that authenticates with a stored token rather than OAuth sidesteps the problem entirely.

Source: Meta for Developers: Connect AI Agents to Meta with MCP and Meta for Business: Introducing Meta Ads AI Connectors.

Credential checklist before the first connection

This is the step that gets skipped most often.

Before Claude Code can use an ads MCP server, the underlying connector still needs a valid way to access the ad account.

Meta Ads: what you need

For Meta's official Ads AI Connector path, you do not create your own Meta Developer App, app secret, system user token, or long-lived Marketing API token.

The official remote MCP server uses Meta's OAuth flow. In practice, you need:

  • a Meta user that has access to the relevant Business Portfolio
  • permission to the ad account you want Claude to read or manage
  • access to Meta Ads AI Connectors in your account, because the feature is still rolling out
  • an MCP-compatible client such as Claude Code

The setup path is.

  1. Add the Meta Ads MCP server to Claude Code.
  2. Open /mcp.
  3. Authenticate through the browser with your Meta account.
  4. Approve the requested Business and ad account access.
  5. Return to Claude Code and verify that the server is connected.
  6. Ask Claude to list available tools before asking it to touch any campaign data.

If you are using an unofficial or self-hosted Meta Marketing API MCP server instead, the credential model changes. Then you may need a Meta Developer App, app review, system user access, a token with the right permissions, and Business Manager setup. That is a different path from Meta's official Ads AI Connector.

Google Ads is different. The local Google Ads MCP server wraps the Google Ads API, so you need API credentials before the MCP server can do anything useful.

At minimum, prepare:

  • a Google Ads manager account if you need to obtain a developer token
  • a Google Ads developer token
  • a Google Cloud project
  • OAuth client ID and client secret, or another supported Google Ads API auth mode
  • a refresh token for the Google user that has access to the target account
  • the target customer ID and, if relevant, the login customer ID for the manager account

Those values normally land in google-ads.yaml:

yaml
developer_token: "INSERT_DEVELOPER_TOKEN"
client_id: "INSERT_OAUTH_CLIENT_ID"
client_secret: "INSERT_OAUTH_CLIENT_SECRET"
refresh_token: "INSERT_REFRESH_TOKEN"
login_customer_id: "INSERT_MANAGER_CUSTOMER_ID_OPTIONAL"

Do not commit this file to a repo. Keep it in a local secret path and pass that path to the MCP server through GOOGLE_ADS_CREDENTIALS.

Connect Claude Code to a remote MCP server

Claude Code supports remote HTTP MCP servers with this pattern:

bash
claude mcp add --transport http <server-name> <server-url>

For any connected server, you can inspect status inside Claude Code:

Open the MCP panel and check whether the server is connected. Then ask Claude to list the available tools before using them. That last step matters. Tool names and capabilities can change, especially during beta.

Meta Ads: official MCP and CLI path

Free bundle

Claude Code Skills Bundle for Marketing

The full library of AdLume skills: paid ads, landing pages, B2B leads, GTM tracking, e-commerce.

The bundle goes straight to your inbox, then one email a week. Unsubscribe in one click. We never share your address.

Meta introduced Ads AI Connectors in open beta. The package includes an ads MCP server and an ads command line interface. Meta positions the connector around four groups of work:

  • reporting
  • campaign management
  • catalog management
  • signal diagnostics

The remote MCP endpoint commonly referenced in setup guides is:

plaintext
https://mcp.facebook.com/ads

The reliable path is your client's connector settings screen. In Claude that is Settings, then Connectors, then Add, and you paste the endpoint there. You complete the Meta login in the browser window that opens, then choose which ad accounts and Pages you are authorizing. That consent screen is the only place you decide what the agent can see at all, so read it rather than clicking through it.

The terminal equivalent looks like this, and it is worth knowing that it currently fails for a lot of people:

bash
claude mcp add --transport http meta-ads https://mcp.facebook.com/ads

If that returns a redirect_uris or dynamic registration error, it is the known issue described earlier in this guide, not a mistake in your setup. Use the connector settings screen instead.

For Claude Code and terminal workflows, Meta also announced an ads CLI. That matters because coding agents often work better when a command returns structured JSON, TSV, or a clear exit code.

The practical split.

  • use the remote MCP server for conversational analysis
  • use the CLI for repeatable scripts, QA checks, and structured workflows

If you are managing client accounts, I would still start with reporting and diagnostics. Do not give a new agent write access on day one.

Set the tool permissions before you run anything

At launch the server exposed 29 tools. On my own connection today it exposes 97, grouped into interactive tools that create campaigns, ad sets and ads, read-only tools, and write tools that touch catalogs, creatives, audiences and pixel events. Meta expands the server tool by tool as products leave beta, so whatever number you see is a floor rather than a ceiling.

Each tool has three states: allow, ask first, or block. You can set them individually, and you can set an entire group at once from a dropdown at the group header. That group dropdown is the part worth slowing down for, because one click hands an agent standing permission to create campaigns unattended.

How I set mine.

  • Read-only insights, performance and benchmarks: allow. This is the whole point of connecting, and it is all an agent needs for the first few weeks.
  • Read-only account and asset lookups: allow. Without it the agent keeps stopping to ask you for IDs.
  • Create campaign, ad set and ad: ask first, never allow. This is the group that spends money.
  • Catalog, creative and audience writes: ask first. Reversible, but it edits assets that other campaigns depend on.
  • Pixel and conversion event writes: block, at least at first. An agent quietly changing what counts as a conversion is worse than one wasting budget, because it never shows up in a performance report.

Leaving the write groups on ask first is not the same as being safe. Approval fatigue is real, and the twentieth prompt of the day gets clicked without reading. If you catch yourself doing that, narrow the scope rather than clicking faster.

Google Marketing Solutions maintains a Google Ads MCP Server repository. The repo describes it as an MCP implementation that lets LLMs interact with the Google Ads API.

Important caveat: the repository itself notes that it is experimental and not intended as a production-supported Google product. Treat it as a powerful technical path, not a compliance shortcut.

So the full Google Ads path is not just "install MCP". It is:

  1. Create or use a Google Ads manager account.
  2. Get a developer token from Google Ads API Center.
  3. Create a Google Cloud project.
  4. Create OAuth credentials for the app or use another supported Google Ads API auth mode.
  5. Generate a refresh token for a Google user with access to the target account.
  6. Create google-ads.yaml.
  7. Point the local MCP server to that file.
  8. Verify the server in Claude Code with /mcp.
  9. Ask for a read-only account summary before enabling any mutation tools.

One trap inside the Google Cloud step.

If your OAuth consent screen stays on the Testing publishing status while its user type is External, Google revokes your refresh token after seven days. Everything works, you come back the following week, and it has silently stopped. The fix is one click: set the publishing status to In production. You are not requesting verification and nothing about your account changes. If your account belongs to a Google Workspace organization and you chose Internal, the rule never applies to you.

Two more details stop people at this step. The API Center only exists inside a Google Ads manager account, so a regular account cannot get a developer token until it is linked to one, and the page is not hidden, it simply is not there. And enabling the Google Ads API on the Cloud project is a separate click from creating the project, which later produces an error that never mentions the API.

If you would rather not touch the API at all.

Third-party services such as Pipeboard, Pipedream and Flyweel broker the connection and hand your client a ready endpoint. I am not affiliated with any of them and I am not recommending a specific one, only noting that the category exists, because most guides present the API route as the only option. The tradeoff is real: you are giving a third party standing access to a live ad account, so read what their token can do and where it is stored before you connect anything.

The Google Ads MCP setup requires Google Ads API credentials. The server expects a Google Ads configuration file with keys like:

  • client ID
  • client secret
  • refresh token
  • developer token
  • optional login customer ID

The basic local server configuration for Claude Code follows the stdio MCP pattern:

bash
claude mcp add --transport stdio google-ads -- \
  pipx run --spec git+https://github.com/google-marketing-solutions/google_ads_mcp.git run-mcp-server

You also need to point the server to your Google Ads credentials:

bash
export GOOGLE_ADS_CREDENTIALS="/path/to/google-ads.yaml"

For project-level setup, the same idea can live in MCP JSON configuration, but be careful with secrets. Do not commit credentials into a repo.

Keep mutations disabled until the workflow is trusted

The Google Ads MCP repository separates read-only tools from mutation tools. Mutation tools are disabled by default and require an explicit environment variable:

bash
export ADS_MCP_ENABLE_MUTATIONS=true

That default is correct.

A useful rollout sequence looks like this:

  1. Connect read-only reporting.
  2. Ask Claude to summarize account structure.
  3. Ask for a weekly performance readout.
  4. Compare the output with your own manual diagnosis.
  5. Add approval-ready recommendations.
  6. Only then consider mutation tools.

Even after mutations are enabled, the agent should not act without a human approval gate.

A practical first workflow

Once both platforms are connected, do not ask the agent to "optimize the accounts."

Ask for a bounded job:

plaintext
Review the last 14 days of Google Ads and Meta Ads performance.
Compare spend, conversions, CPA, ROAS if available, conversion volume, and major week-over-week changes.

Return:
1. the three biggest changes
2. the likely cause of each change
3. what needs human review
4. what should not be changed yet
5. what data is missing

Do not make changes. Do not create campaigns. Do not edit budgets. That is a much safer first workflow than asking the agent to manage ads.

It also mirrors how good performance marketers work. They do not start by clicking buttons. They first understand what changed and why.

The approval gates I would use

For Google Ads and Meta Ads, I would require human approval before:

  • changing budgets
  • pausing campaigns, ad sets, ads, or keywords
  • changing bidding strategy
  • changing optimization events
  • publishing new ads
  • changing conversion actions or tracking setup
  • editing audiences or exclusions
  • creating campaigns
  • changing catalog or feed settings

I would allow the agent to draft:

  • readouts
  • diagnostic tables
  • hypotheses
  • task lists
  • QA checklists
  • proposed changes
  • rollback plans

That is the sweet spot: AI does the boring diagnostic work, but the human keeps control over money and account risk.

The real product is the harness

Connecting Claude Code to ad platforms is not the hard part anymore.

The hard part is building the operating system around the connection:

  • what context the agent reads
  • what it is allowed to do
  • how it explains recommendations
  • how it handles uncertainty
  • where human approval is required
  • how results are checked after a change

That is why MCP alone is not enough.

MCP gives the agent access to tools. A good harness turns that access into a repeatable workflow.

For performance marketing, that difference is everything.

Sources

Done for you

Rather have it run for you?

AdLume watches your ad accounts and brings the next fix to your team's tools.

One email, on the day access opens. Nothing else, and you can leave the list with one click.

FAQ

What do I need before connecting Claude Code to Meta Ads via MCP?

For Meta's official Ads AI Connector you do not create a developer app, app secret or tokens. You need a Meta user with access to the relevant Business Portfolio and ad account, then you authenticate through Meta's OAuth flow in the browser and approve the requested access.

Why does the Google Ads MCP server need a client_id and client_secret?

The local Google Ads MCP server wraps the Google Ads API, so it needs OAuth credentials from a Google Cloud project plus a developer token and refresh token. Those values normally live in google-ads.yaml, which should stay out of any repo.

How do I add the Meta Ads MCP server to Claude Code?

Run claude mcp add --transport http meta-ads https://mcp.facebook.com/ads, then authenticate through the Meta login flow when the client requests it.

Should I let the agent make changes to my ad accounts?

Not at first. Start with read-only reporting, compare the output with your own diagnostics, and require human approval before budget, bidding, pausing or tracking changes even after mutation tools are enabled.

Keep reading