Claude Code, working on Meta ad accounts

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

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:

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

The key's scopes decide what the client 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.

The client page covers where the configuration lives and why a bearer key does not belong in a repository. This one covers 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, the objective mix, how concentrated spend is, which campaigns rank on return and which rank worst on cost per acquisition, and which weekdays are cheapest. Concentration is usually the first number in that brief worth reading, because it is the one the brief computes rather than the one a dashboard shows: how much of the account's spend sits in how few campaigns, over the ninety days it covers.

Then the tree. Campaigns come back with status, objective and budget in minor units of the account's own currency — including the ones with no recent delivery, which is the set a dashboard quietly hides. The structure below any campaign comes back with the ad sets, the ads and the creatives beneath them, each row carrying the operations that level can actually express here.

That last part is the platform-specific detail that matters most before anything is drafted. This platform allows a budget at the campaign and at the ad set, so the first question about any account is where its money actually sits, and the connection answers it: it names the operations the platform can express, the levels a budget attaches to, the objectives it accepts, what a removal means, and whether a draft can be dry-run before it is applied. On this platform the last answer is no — there is no dry run available — so a draft is checked against the platform's declared capabilities and the account's own shape when it is written, and the platform's own verdict arrives when the change is applied.

Reach deserves one line of its own. This platform reports it and the others connected here do not, and it is de-duplicated per day per campaign rather than across a range. Summing a fortnight of it counts the same person several times, so the tool layer calls it a sum of daily reach and an agent quoting it says so rather than calling it an audience.

Ask for a change and the agent writes a change request. One call carries the whole batch in the order it applies, and an entry can name the earlier entry that creates its parent — so a campaign, the ad set inside it and the ad inside that arrive as three entries in one reviewable group rather than three acts that can half-succeed. A batch has a ceiling and a longer one is refused rather than truncated.

What comes back is the batch, one review link for the group, and the authority that cleared it: waiting for a person, or cleared on the way in by a rule the workspace wrote. Each row carries its place in the run, and once something has cleared it, whether that was a person, a key or a policy. The agent's job at that point is to hand over the link rather than to keep going.

Two details are specific to this platform. Every create lands paused, so approving a batch of creates builds structure without spending a cent; starting delivery is a second change through the same gate. And a removal here is an archive rather than a delete — a status change that preserves the entity and can itself be undone — which makes this the one connected platform where the most destructive operation is reversible.

When something needs fixing, a draft's payload is replaced whole rather than patched, which re-validates it, re-stamps the currency from the target account and re-runs the guardrails; a failed row goes back to waiting, and that is how a stopped batch is resumed. A change that already landed is undone by drafting its exact inverse at the same gate.

Approving is not deploying. This platform reviews ads on its own schedule, and a new or edited creative enters that queue when the change lands; a change can be applied, read back, verified as having landed, and still not be delivering. The record keeps the two apart, so nobody reads a flat first day as a failed change.

Pacing is the other half. Delivery paces against the budget and schedule on the level that holds them, from the moment an edit lands rather than retroactively across the hours already spent. That is why every change request records the state before it: when a figure moves the week after a change, the question is what was true beforehand and who cleared it, and both are on the row.

Applying a 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.