Claude Code, working on Google Ads accounts

One client and one platform, end to end: what the connection gives a terminal agent on this platform specifically, what to run first, and what happens to a change between the prompt and the account.

The combination has one property worth naming up front. This is the platform with a dry run, and a terminal agent is the client most likely to be asked for a large structural batch in one go — a hundred negatives, a rebuild of an ad group, a sweep across campaigns. Those two facts fit together: the batch is validated against the live account before it is queued and again on the way to being applied, so the failure mode a long batch usually has here is caught at the gate rather than halfway through.

The server is one Model Context Protocol endpoint over streamable HTTP, authenticated with a key you mint in the app under Settings and then MCP. Add it in a line:

claude mcp add --transport http tempio https://app.tempio.ai/api/mcp \
  --header "Authorization: Bearer YOUR_KEY"

The key's scopes decide what the session sees. Reading covers connections, ad accounts, campaigns, structure, media assets, metrics, drafts and media plans. Drafting writes change requests and reaches no live account. Approving is opt-in at the moment the key is minted, and most workspaces do not grant it to an agent. Scopes are enforced on the call rather than by hiding it: a capability whose scope the key does not hold answers by naming the scope it needs and the scopes the key holds. What the tool list inside the session shows is the surface chosen at the mint — compact registers two tools, one that describes the catalogue and one that runs it; explicit registers each capability as a tool of its own.

A terminal agent has one habit worth naming: it keeps whatever it was given in the session it was given it in. The key belongs in the header of that command and nowhere near a file under version control, and revoking it is done in the app rather than by editing anything here. The client page covers the configuration; this page covers the platform.

What to run first in the session on this platform: the search terms and the account's own change history, in that order — the demand that exists, then what somebody already did about it.

Start with the account brief: ninety days per connected ad account, coverage, totals, the last twenty-eight days against the twenty-eight before them, objective mix, spend concentration, and the return and cost-per-acquisition rankings inside one account and one currency.

Then the reads this platform has and the others do not. What people actually typed before an ad showed, ordered by cost so the top of a short list is the expensive tail rather than an arbitrary sample, with the keyword that matched each term and how it matched. Where the money in a display, video or Performance Max campaign actually went — the sites, apps and channels it ran on. The account's own change history: who changed what, when, and exactly which fields moved, which is the read to reach for when a number moved and nobody remembers why. And place resolution, because a location criterion here is a number rather than a name, and an agent guessing at one is an agent drafting a campaign aimed at the wrong country.

The tree itself is deeper than elsewhere: campaign, ad group, ad, and — depending on the campaign type — keywords and assets as first-class rows of their own. An objective read on a campaign here is a translation rather than a native field, because this platform has no objective concept in the sense the others use the word; what a campaign carries is a channel type, and the read model maps it so one shape holds every platform. The tool layer says so rather than inventing a taxonomy the platform does not have.

Three platform facts shape every change drafted here, and the connection states all three.

A budget is a campaign-level object. An ad group has a bid, not a budget, so the list of levels a budget attaches to has exactly one entry, and a request to change an ad group's budget is refused before a reviewer sees it rather than quietly applied one level up.

A dry run exists, and it is used. A draft can be validated against the live account before it is queued and again on the way to being applied, which catches the common failure — a draft written on Monday against structure that moved on Tuesday — at the gate rather than halfway through a batch. This is the one connected platform where that safety net exists, and it is the reason a large structural batch is less frightening here than anywhere else.

A removal is terminal. Removing an entity is not an archive and cannot be undone, not even to re-pause it, which is why a removal is never cleared automatically and why a reversible status change is almost always the better instruction. An agent asked to clean up an account should be proposing status changes, and a workspace writing a rule that clears removals automatically is writing a rule it will regret.

Approving is not deploying. An ad or an asset enters the platform's review queue when the change lands, on the platform's schedule; a change can be applied, read back, verified as landed, and still not be delivering. The record keeps the two apart.

This platform also withholds the current day. It restates today's figures for hours, so the tool layer treats data as ready through yesterday and refetches a trailing month on every sync. An agent asked how today is going says what it can see and when it was read, rather than filling the gap with a number that will change. Pacing runs against the campaign budget from the moment an edit lands rather than retroactively, which is why every change request records the state before it: when a figure moves the week after a change, what was true beforehand and who cleared it are both on the row.

Applying a cleared change to a live account on this platform is in private beta. Everything before it is built and in use: the reads, the numbers, the media plan a flight is shaped in, and the gate every change waits at — approved by you, or by a rule you wrote.