Cursor, working on Meta ad accounts

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

Of the connected platforms, this is the one where the structure an agent proposes is least likely to be a one-line change. Money can sit at the campaign or at the ad set, every create lands paused, and a removal is an archive rather than a delete — so a rebuild here is usually a batch of creates and status changes rather than an edit, and reviewing a batch as a set of diffs is the thing this client is already shaped around.

The server is one Model Context Protocol endpoint over streamable HTTP, authenticated with a key minted in the app under Settings and then MCP. It goes in the client's own configuration as a server entry:

{
  "mcpServers": {
    "tempio": {
      "url": "https://app.tempio.ai/api/mcp",
      "headers": { "Authorization": "Bearer YOUR_KEY" }
    }
  }
}

The key's scopes decide what the editor's agent 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 mint and is rarely worth granting to an agent that also has a file system in front of it.

One caution belongs on this page rather than in a footnote. The configuration file can sit beside a project, and a bearer key in a file beside a project is a bearer key one careless commit away from a public repository. Put the entry in the user-level configuration, or keep the project-level file out of version control. Keys are revocable in the app for exactly this reason, and a key that is revoked stops working everywhere at once. The client page covers the rest of the configuration; this page covers the platform.

What to read into the editor first on this platform: the structure beneath the campaigns that are spending, because a budget here can be held at two levels and the rows are what say which.

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 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 — 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.

Reach deserves a line of its own, because this is the platform that reports it. It is de-duplicated per day per campaign rather than across a range, so summing a fortnight of it counts the same person several times. The tool layer calls it a sum of daily reach, and an agent quoting it says so rather than calling it an audience.

The platform-specific facts an agent should have before it drafts anything here are three, and the connection states all three rather than leaving them to be inferred.

Money sits at two levels. A budget can be held by the campaign or by the ad set, so the first question about any account is where its money actually is, and a draft aimed at a level that holds none is refused before a reviewer sees it.

There is no dry run. The connection reports that a draft cannot be validated against the account before it is applied, 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. That is a reason to read the structure first rather than a reason to draft carefully once.

A removal is an archive. This is the one connected platform where the most destructive operation is reversible: removing an entity is a status change that preserves it and can itself be undone. Combined with the fact that every create lands paused, approving a batch of creates builds structure without spending anything, and starting delivery is a second change through 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 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.