Which scope should the connector be added under?

With the plugin there is no scope to choose: it registers the connector for you. By hand, user scope, as in the command above — it makes the connector available in every folder you open Claude Code in. Local scope (the default when you leave --scope off) keeps it to the one directory you ran the command in, which is why /mcp shows nothing anywhere else. Project scope writes the server into a .mcp.json in the repo, to share with teammates; the URL holds no secret — access is each person's own Google sign-in — so every teammate still signs in as themselves.

I added the connector by hand before installing the plugin. What now?

Claude Code keeps your copy and silently ignores the plugin's: claude mcp list shows a bare adcopilot line and no plugin:adcopilot:adcopilot line. Remove your copy from every scope it is in — claude mcp remove adcopilot -s user, then claude mcp remove adcopilot -s local from the directory you added it in, since a local registration belongs to that directory. Once only the plugin's line is left, run /mcp to sign in.

Can a cron job make changes to my ad account?

Only if you explicitly allowlist write tools, so don't. In headless mode there is no human at the approval prompt, which is exactly why scripted runs should pass only read tools in --allowedTools. A script built that way can query and report forever but cannot mutate — the write path stays interactive, where the approval loop exists.

Why use Claude Code for ads instead of Claude Desktop?

Files and repeatability. Claude Code writes audit output to markdown you can commit, diff week over week, and pipe into anything else; a CLAUDE.md carries your account ID and house rules into every session; and -p mode turns any recurring read into a one-line script. Desktop is better for conversational work — the connector address is the same in both.

Google Ads From the Terminal With Claude Code

Claude Code turns Google Ads work into terminal work: the AdCopilot plugin adds the connector, /mcp signs you in, and from then on your agent reads and runs the account in the same session as your code — audits, budgets, bids, new campaigns, executed on your command in seconds, with output that lands in files instead of chat scroll. Setup for all Claude surfaces is covered in connect Claude to Google Ads; this page is the developer workflow on top.

Install the plugin, then verify

In Claude Code:

/plugin marketplace add AtromxIntelligence/adcopilot-claude-plugin
/plugin install adcopilot@adcopilot-claude-plugin

The plugin registers the connector for you, so there is no claude mcp add step, and it adds three skills and five /adcopilot: commands: /adcopilot:setup checks the connection, /adcopilot:audit runs the full audit, /adcopilot:daily is the daily check-in. What Claude Code loads from it is markdown and one connector registration — no hooks, nothing that runs on your machine — and the repository is public, so you can read every line before installing. The plugin page in the docs lists what each piece does.

Run /mcp, choose adcopilot and sign in with Google; the sign-in is the same one the connector always used. The adcopilot server should then list its tools — reads like the GAQL query and the account list, writes like campaign creation and adding negative keywords. First prompt:

List the accounts you can see, then give me last 7 days of spend and
conversions for account <account>.

Reads change nothing; Claude Code asks the first time each tool runs, and allowing a read tool lets it run from then on. The first write triggers Claude Code's permission prompt in the terminal — tool name, arguments, allow options — which is the approval loop in its terminal form.

Or add it by hand

Rather not install a plugin? One command adds the connector instead:

claude mcp add --scope user --transport http adcopilot https://mcp.adcopilot.cloud/mcp

--scope user is what makes it show up in every folder — leave it off and Claude Code keeps it to the folder you ran the command in. (--scope project writes a .mcp.json instead, to share it with teammates.)

Use the plugin or this command, not both. A copy added by hand hides the plugin's, and taking it out can take two commands: claude mcp remove adcopilot -s user, then claude mcp remove adcopilot -s local from the directory you added it in.

If you do share it through a committed .mcp.json, nothing leaks: the connector URL holds no secret — what authorises access is each person's own Google sign-in, not the URL — and access ends when you revoke the Google grant, not by rotating an address. The full model is on the security page.

The point of the terminal: output that persists

Chat clients answer; Claude Code produces artefacts. Make that the habit from the first session:

Audit account <account> for the last 30 days — wasted spend, search
terms, disapprovals, structure — and write the findings to
reports/ads-audit-2026-08-10.md with a ranked action list at the top.

Now the audit is a file: commitable, diffable against next month's, greppable. The same pattern covers weekly summaries, change logs, and negative-keyword decisions — an ads paper trail living in git next to the site whose ads it describes. When a finding needs code changes (a landing page, a tracking fix), the same session reads your codebase and makes them; that combination is the workflow no browser tab has.

Put the house rules in CLAUDE.md

Claude Code reads CLAUDE.md at session start — use it so every ads session inherits your conventions instead of relearning them:

## Ads conventions
- Google Ads account: <account> (the only account to touch)
- Currency: USD. Budgets stated per day.
- New campaigns: always created paused, never enabled in the same
  session they are created.
- Negatives: exact match for one-off junk, phrase for patterns.
- Every session that changes anything appends to reports/ads-changelog.md.

Five lines, and prompts shrink from paragraphs to verbs — "run the weekly sweep" now means the same thing every week.

Script the weekly check — read-only by construction

claude -p runs a prompt headless and prints the result, which turns the weekly routine's reporting half into a script:

claude -p "In account <account>: last 7 days vs previous 7 — spend,
conversions, cost per conversion by campaign, then the top 10 search
terms with cost and no conversions. Markdown." \
  --allowedTools "mcp__plugin_adcopilot_adcopilot__<read tool>,mcp__plugin_adcopilot_adcopilot__<read tool>" \
  > reports/weekly-$(date +%F).md

The --allowedTools list is the safety design, not a convenience: headless runs have nobody at the approval prompt, so scripts get read tools only. Built that way, the cron job that drops a Monday report into your repo can never mutate the account — writes stay in interactive sessions where you approve them one by one. Schedule it, then spend your Monday twenty minutes acting on the file instead of gathering it.

Quirks worth knowing

Tool names are prefixed — in --allowedTools, MCP tools follow mcp__<server>__<tool>. With the plugin the prefix is mcp__plugin_adcopilot_adcopilot__; added by hand, it is the server name you chose in claude mcp add (here, mcp__adcopilot__). Take the two read tools' names from the /mcp listing.
Approvals are per tool — allow the negative-keyword add for a session without also allowing the campaign update. Graduate tools the way the approval workflow suggests: harmless writes first, spend writes never.
Same address everywhere — the URL you added here also works in Claude Desktop, Gemini CLI and Cursor; one connector, every client, and the full client list shows each config shape.

If you have a terminal open and no connector yet: Start free — the two plugin lines above are the whole setup, and you sign in with Google the first time it connects. Your first audit file can exist ten minutes from now.