Claude Code, working on TikTok ad accounts

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

This is the platform where reading the structure first is not a nicety. The three levels have familiar names and behave differently underneath — the schedule is one level down, targeting is not a campaign concept at all, and whether a budget is the ad group's to change depends on a setting made when the campaign was created. A terminal agent asked to make a change in one line will otherwise propose the change that exists on other platforms and does not exist on this one.

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 structure, because whether an ad group owns its budget is decided by how its campaign was created rather than by the platform.

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, the rankings inside one account and one currency, and the weekday rhythm.

Then the tree, and this is the platform where reading it first matters most. The three levels have the names they have elsewhere and behave differently underneath. Schedule and targeting are ad-group concepts here — there is no campaign-level schedule to set and no campaign-level targeting to change — so an instruction that would be a one-line campaign edit elsewhere is a set of ad-group edits on this one. The tool layer refuses the campaign-level version outright instead of picking an ad group on your behalf.

The media library is worth a read before any creative work. Each asset comes back with the id the platform holds those bytes under, so a creative references an upload that already exists rather than sending the same file twice.

One limit shapes every long question asked here. Daily insights come back thirty days at a time — a hard limit on the platform rather than a preference — so a ninety-day question is three requests and the sync plans it that way. Today's figures are fetched and marked partial rather than presented as final, and a trailing fortnight is refetched on every sync to absorb the platform's own restatements.

Three facts decide what can be drafted here, and the connection reports all three.

Money can sit at the campaign or at the ad group, and which one is writable is a fact about the campaign rather than about the platform: when campaign budget optimisation owns the money, the ad groups beneath it do not. The connection reports both levels as writable somewhere on this platform; the entity in front of you decides which, and a draft aimed at the wrong one is refused rather than quietly applied to the other.

There is no dry run. A draft is checked against the platform's declared capabilities and the account's own shape when it is written, and the platform's verdict arrives when the change is applied, which is another reason to read the structure before proposing a batch against it.

A removal is terminal. There is no archive state here: the third status value is a delete and it cannot be undone. That makes a reversible status change the instruction of choice and a removal something no rule should clear on its own.

Approving is not deploying. A creative enters the platform's review queue when the change lands, on the platform's schedule, and a change can be applied, verified as landed, and still not be delivering an hour later.

The reporting window shapes what can honestly be said afterwards. With insights arriving thirty days at a time and today marked partial, a same-day verdict on a change is not available, and an agent that offers one is offering a guess. What is available is the change on the record with the state before it, and the numbers as at the day they were read. Pacing runs against the budget and schedule on the level that holds them from the moment an edit lands, which on this platform means the level that actually owns the money for that campaign.

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.