Adchestra’s Google Ads MCP Writes Campaigns

Adchestra built a hosted MCP server, described in a post titled "I built my first MCP to manage Google Ads," that connects an AI coding agent to Google Ads, Google Analytics, and Google Tag Manager. The project deals with a painfully normal problem: a small Shopify store spent $150 on one conversion, could not afford an agency, and wanted an agent that could do more than read dashboards. The useful takeaway is simple: write access makes MCP integrations feel real, but only if the boundary is narrow enough that a bad suggestion cannot become an expensive campaign.

An MCP server is a bridge that lets an AI agent use external tools and data through the Model Context Protocol. In a Codex CLI workflow, that bridge can turn a chatty analysis loop into a working command loop: inspect performance, propose changes, apply approved edits, and verify the result. Gemini Workshop is part of Harness Institute.

Start with the actual thing Adchestra built

The interesting part of Adchestra is not that it summarizes ad metrics. Lots of agents can read a CSV, scrape a dashboard, or describe a funnel after the fact.

The interesting part is that its hosted MCP has read and write access. According to the creator’s post, the existing Google Ads MCP they tried could read data but could not make changes. So they built one that can inspect performance, find wasted spend, create or update campaigns, and work across Google Ads, Google Analytics, and Tag Manager.

That is exactly where developers started paying attention. A read-only MCP is a nicer search box. A write-capable MCP is closer to an operator.

The trap is pretending those are the same product. “Show me poor-performing keywords” and “pause these keywords” are separated by one permission boundary, one spend account, and one very awkward Monday morning.

Notice what changes when the agent can write

OpenAI Codex, OpenAI’s coding agent, is usually discussed around code edits: change a function, run tests, open a pull request, explain a diff. Adchestra points at a wider pattern for Codex CLI workflows: the repo is no longer the only surface the agent can touch.

A typical loop might look like this:

codex "Inspect last week's Google Ads performance through the ads MCP. Find campaigns with spend and no conversions. Propose changes only; do not apply them."

codex "Apply the approved pause list from ads-review.md, then fetch the campaign status again and write a receipt to ads-change-log.md."

That second command is the line that matters. The agent is no longer just helping you think. It is operating a business system.

For Codex users, the right mental model is a production verification loop, not a brainstorming session. You want the same rhythm you would use for code: plan, diff, approve, apply, verify, record. The linked Codex CLI workflows topic is a good home for that pattern because the command line makes the boundary visible.

The trap is letting the agent skip the receipt. If it changes campaigns, you need a plain artifact that says what changed, when it changed, and what it checked afterward.

Keep the first version annoyingly narrow

A Google Ads MCP with write access should not begin with “create any campaign you think is best.” That is too much surface area and too little feedback.

A safer first cut is boring on purpose. Let the agent read account structure, query performance, and draft a change file. Then allow only a small set of mutations: pause keywords, adjust labels, or update names to a convention you already use.

Here is a small AGENTS.md instruction that fits this kind of repo:

## Google Ads MCP boundary

Codex may use the Google Ads MCP to read campaign, ad group, keyword,
conversion, and cost data.

Codex may propose campaign edits in `ads-review.md`.

Codex must not create campaigns, change budgets, edit bidding strategy,
or publish Tag Manager changes unless the prompt explicitly says:
"approved to write ads changes".

After any approved write, Codex must fetch the changed objects again and
append a receipt to `ads-change-log.md` with object IDs, before/after values,
and the verification command used.

This is not fancy. That is the point.

The best agent instruction is the one you can audit when something goes sideways. If a future prompt says “clean up naming conventions,” Codex has a local rule for what it may do without turning “cleanup” into a budget change.

Use a decision table before granting write access

Here is the artifact I would keep next to any Codex CLI MCP experiment that touches ads money. It is small enough to paste into a repo, and blunt enough to catch most bad ideas early.

Permission-boundary note: give the MCP the smallest write scope that still proves the workflow. If the first useful workflow is “find and pause obviously wasteful exact-match keywords,” do not also grant campaign creation and Tag Manager publish rights.

That sounds conservative, but it makes the integration more usable. Narrow permissions turn the agent from “scary intern with a credit card” into “fast analyst with a checklist.”

The open question is ads expertise, not just tooling

One commenter asked the question every builder should ask: how much ads experience do you need to use this?

The honest answer is: enough to know what should never be automated blindly. An MCP can surface wasted spend, naming drift, missing tags, or conversion gaps. It cannot magically decide your margin, attribution model, inventory constraints, or tolerance for testing losses.

A concrete example: if a Shopify store sells products with thin margins, a campaign with conversions may still be bad. The agent needs business context, not just ad metrics. Put that context somewhere durable, such as AGENTS.md, a paid-media-notes.md file, or a small skill that explains acceptable customer acquisition cost, excluded geographies, and naming rules.

This is also where cost-tracking habits help. The same discipline behind price Tracks LLM Inference Costs applies here: measure the loop you are automating, because “the agent did work” is not the same as “the business improved.”

Common questions

How much Google Ads experience do I need to use it?

You need enough context to review proposed changes before they affect spend. At minimum, define your target ROAS or CPA, campaign naming convention, excluded actions, and what counts as wasted spend. Without those rules, the MCP may optimize toward visible metrics while missing margin, inventory, or attribution reality.

Can I make it do scheduled tasks, like sending a campaign report every Monday?

Yes, scheduled reporting is a natural fit if the MCP can read the needed metrics. Keep the first scheduled task read-only: fetch last week’s spend, conversions, CPA or ROAS, top movers, and anomalies, then write a report. Delay scheduled writes until the report format is boring and trusted.

Can it automatically create campaigns and organize naming conventions?

It can, if the MCP exposes those write tools, but campaign creation should start as draft-only. Naming cleanup is safer when you provide a convention file, such as brand_region_channel_objective_date, and require the agent to show before/after names before writing changes.

Where does Codex fit if this is an ads tool?

Codex fits in the workflow around the MCP: writing instructions, generating review files, calling tools, checking results, and leaving receipts in the repo. The value is not that OpenAI Codex “knows ads.” The value is that Codex can follow a repeatable command workflow with clear permissions.

What is the biggest risk with a write-capable MCP server?

The biggest risk is silent mutation: the agent changes budgets, campaigns, tags, or tracking without a reviewable record. The fix is boring and effective: require explicit approval for writes, fetch the changed objects afterward, and save object IDs plus before/after values in a change log.

Best ways to use this research

• Best first artifact: Add a short MCP boundary note to AGENTS.md before connecting any write-capable ads tool. Include allowed reads, allowed writes, forbidden actions, and the required verification receipt.
• Best first experiment: Run a read-only wasted-spend report for one account and one date range. Ask Codex to produce ads-review.md, not to apply changes.
• Best comparison angle: Compare read-only MCP value against write-capable MCP risk. If a workflow is useful without writes, keep it read-only longer.
• Best Codex CLI habit: Treat external system changes like code changes. Ask for a plan, inspect the proposed diff or review file, approve a narrow action, then make Codex verify the live state.

Further reading

• OpenAI Developers — Codex CLI docs
• Model Context Protocol — specification
• I built my first MCP to manage Google Ads — source

Try the smallest useful write

If you test a Google Ads MCP, begin with one safe workflow: read performance, draft a pause list, approve it manually, apply it once, and verify the changed object IDs. If that loop feels too heavy, keep the MCP read-only until the review artifact is clear enough to trust.

One methodology lens

One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.