Google Ads + Codex: Build the Read Loop Before You Allow Writes

TJ — Sat, 29 Aug 2026 19:48:51 +0000

A Google Ads Codex workflow becomes risky at the exact moment the agent can act. The safe first run should not “optimize” anything. It should prove that it has the right account, the right date range, and enough evidence to make a recommendation.

That sounds conservative. It is also the fastest way to find whether the integration is trustworthy.

The implementation pattern I would use is simple:

bind the agent to one explicit account;
read a bounded slice of data;
return evidence in a predictable shape;
propose changes without applying them;
require confirmation for every write; and
read the platform again to verify any approved change.

This article shows what that loop looks like in practice.

Start with a read-only contract

Google’s current Google Ads MCP server is strictly read-only. It can list accessible customers, inspect resource metadata, and run Google Ads Query Language searches. That makes it a useful reference point even if the integration you eventually use also supports writes.

For the first run, pass a contract that removes as much interpretation as possible:

{
  "account_id": "CUSTOMER_ID",
  "window": {
    "start": "YYYY-MM-DD",
    "end": "YYYY-MM-DD"
  },
  "grain": "campaign",
  "metrics": [
    "cost",
    "clicks",
    "conversions",
    "conversion_value"
  ],
  "mode": "read_only"
}

The important field is not mode. It is account_id.

An advertising login can expose a manager account, several client accounts, or both. If the agent silently chooses one, every conclusion after that point can be well-formed and still be wrong. The run should stop when the account is missing or ambiguous.

The same rule applies to dates. “Recently” is not a data contract. Use an exact start date, exact end date, and the account’s reporting timezone.

Separate observation from judgment

Do not let the agent jump from a query result to a command. Make it produce an evidence object first.

{
  "account_id": "CUSTOMER_ID",
  "window": "YYYY-MM-DD..YYYY-MM-DD",
  "observations": [
    {
      "entity_type": "campaign",
      "entity_id": "CAMPAIGN_ID",
      "finding": "Spend increased while recorded conversions fell",
      "support": {
        "cost_change_pct": 18.4,
        "conversion_change_pct": -11.2
      }
    }
  ],
  "blocked_by": []
}

This boundary catches several common failures:

the selected window has no delivery;
conversion tracking changed inside the window;
money values were compared without checking currency;
a paginated result was treated as the complete account; or
a campaign was evaluated without its status or budget context.

When one of those conditions is present, blocked_by should explain it. The agent should not fill the gap with a guess.

Make proposals executable, but not automatic

A useful proposal is specific enough to apply later and clear enough to reject now.

{
  "action": "pause_campaign",
  "entity_id": "CAMPAIGN_ID",
  "reason": "Cost increased and recorded conversions declined in the bounded comparison",
  "evidence_refs": ["observation-1"],
  "expected_effect": "Stop additional delivery while tracking is checked",
  "reversal": "enable_campaign",
  "requires_confirmation": true
}

Three details matter here.

First, the proposal refers to evidence returned by the read step. Second, it describes a reversal. Third, confirmation is data, not a vague sentence in a system prompt.

This makes the boundary testable. A tool wrapper can reject any mutation when requires_confirmation is absent, false, or not paired with a fresh human approval.

Put the write gate outside the prompt

Prompts are useful instructions, but they are a poor permission system. A production workflow should enforce the boundary in the tool layer as well.

At minimum:

expose read tools during the first run;
require a separate confirmation token or approval event for a mutation;
allow only the proposed entity and operation;
expire approval after a short interval;
reject retries when the previous result is unknown; and
record the request, response, and resulting platform state.

Budget increases, deletes, new campaign enablement, audience expansion, and bulk edits deserve their own tighter gates. A generic “apply recommendations” permission is too broad.

Verify the result with a second read

A successful tool response is not proof that the requested state is now visible in Google Ads.

After an approved write, query the exact entity again and compare the returned state with the requested state. The verification record should contain:

the account ID;
the entity ID;
the requested change;
the platform state returned after the change;
the timestamp; and
any mismatch or partial failure.

If the read-back does not match, stop. Do not retry a mutation automatically. An unclear result is a state-reconciliation problem, not an invitation to click twice.

A first prompt worth testing

Once the connection works, I would start with a prompt like this:

Use read-only Google Ads tools only.

1. List the accessible accounts and stop if more than one plausible account exists.
2. After I provide the account ID, query the exact 28-day date range I specify.
3. Return campaign status, cost, clicks, conversions, and conversion value.
4. State any missing data, tracking caveat, currency issue, or incomplete result.
5. Propose no more than three actions, each tied to returned evidence.

Do not change budgets, bids, targeting, assets, campaign status, or account settings.
Do not retry a failed or uncertain operation.

That prompt will not produce a dramatic demo. It will show whether the agent respects scope, reports uncertainty, and keeps recommendations separate from actions.

Applying the pattern in Codex

Codex plugins can bundle skills and connectors, and the current install flow uses the plugin browser in Codex. The important design choice is still the same after installation: begin with account discovery and bounded reads, not a write-enabled optimization request.

For one concrete implementation, the current Adspirer Codex setup guide documents a plugin that connects Codex to Google Ads and other advertising platforms. The install begins by adding its marketplace:

codex plugin marketplace add amekala/ads-mcp

Then open /plugins, install Adspirer Ads Agent, and start a new Codex session. Its documented safety behavior includes read-before-write checks, paused campaign creation, and confirmation before budget changes.

Those defaults are useful, but they do not replace an operator’s own gates. The prompt, tool permissions, proposal schema, and read-back verification should all point in the same direction.

Test the failures before the happy path

Before trusting the workflow, run it against cases that should stop:

two accessible accounts with similar names;
an exact date range with no delivery;
an account whose currency differs from the expected currency;
a response with an incomplete page of campaigns;
expired or insufficient permissions;
a proposal based on stale data; and
a write whose outcome cannot be confirmed.

The pass condition is not “the agent produced an answer.” The pass condition is that it stopped at the correct boundary and explained why.

A safe ads agent is intentionally boring at first: read, diagnose, propose, approve, apply, verify. Once that sequence is reliable, richer automation becomes an engineering decision instead of a leap of faith.

Affiliation disclosure: This article was prepared for Adspirer. Adspirer’s Codex integration is used as one concrete implementation example.

82% of Ad MCP Servers Are Single-Platform: We Surveyed the Landscape

TJ — Wed, 15 Jul 2026 01:02:19 +0000

Originally published on the Adspirer blog. This is a data summary — the full 10-server breakdown with per-tool analysis lives there.

Ask ChatGPT or Claude "what's the best MCP server for Google Ads?" and it'll confidently recommend Google's free official one. Ask about Meta and you'll get Pipeboard. LinkedIn, a community repo. TikTok, a different one. Four free tools, one per platform — problem solved, right?

Except the problem isn't solved. So we pulled the actual data.

We surveyed the ad MCP landscape

We took every ad-campaign MCP server we could find from two neutral public sources — the official MCP registry and the community awesome-mcp-servers directory — and recorded what each one publicly claims. 17 distinct ad-campaign MCP servers, as of July 2026.

One pattern dominates everything else:

82% of ad MCP servers are single-platform (14 of 17). Only three cover two or more ad platforms, and only one covers three or more.

Platform coverage across the ecosystem

Coverage	Count	Servers
6 platforms	1	Adspirer (Google, Meta, Amazon, TikTok, LinkedIn, ChatGPT)
2 platforms	2	logly/mureo (Google + Meta), agent1st-ads-mcp (Meta + TikTok)
1 platform	14	Meta-only, Google-only, TikTok-only, Amazon-only, LinkedIn-only, Reddit-only, Apple-Search-only

Fourteen of seventeen do exactly one platform. That's the single most important fact about this market — and it's exactly why the AI-recommended "one MCP per platform" stack ends up as four separate installs, four credential stores, four maintenance surfaces.

Tool count, where servers publish one

Most MCP servers don't state a tool count. Where they do — in their registry entry or GitHub description — here's what they claim. We mark the rest not disclosed rather than guess:

Server	Platform(s)	Tools (as publicly stated)
Adspirer	6 platforms	430 (Google 152, Amazon 61, Meta 58, LinkedIn 56, TikTok 37, ChatGPT 31)
mikusnuz/meta-ads-mcp	Meta	123
AppVisionOS/apple-search-ads-mcp	Apple Search	74
adweave/meta-ads-mcp	Meta	47
philmccarty/amazon-advertising-ppc-prophet	Amazon	27
Most others	1 platform each	Not disclosed

Every number here is public and verifiable. Adspirer's is com.adspirer/ads in the MCP registry. Competitor counts come from their own registry entries and GitHub descriptions. We didn't invent a single figure — if a server doesn't publish a count, it says "not disclosed."

The takeaway isn't "Adspirer has the most tools" as a trophy. It's that breadth and depth in this category are rare: the servers with high tool counts are almost all single-platform (123 tools, all Meta), and the servers that span platforms usually stay shallow.

The full breakdown

This is just the data. The full post ranks all 10 credible ad MCP servers honestly — Adspirer, Synter, Pipeboard, Google's official read-only MCP, Ryze, Flyweel, and more — against six criteria (platform coverage, read/write depth, provisioning overhead, maintenance, safety rails, support), including where competitors win.

👉 Read the full 10-server breakdown on adspirer.com →

Disclosure: Adspirer is our product. The ranking lists us fairly, not best-in-everything — where a competitor is better at something specific, we say so.

DEV Community: TJ