Cursor, working on TikTok ad accounts

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

The platform half is where the care goes. Three of the things an agent would normally assume are properties of an entity here rather than of the platform, and all three are answered by reading the structure before anything is drafted. The client half is short: a server entry in a configuration file, the key kept out of version control, and scopes chosen at the mint rather than argued about afterwards.

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 whole structure in one pass, because three of the things an instruction usually assumes are properties of the entity here rather than of the platform.

Read the structure before anything else here, and read it in full rather than asking about it. The three levels carry the names they carry elsewhere and behave differently underneath, and an editor's agent is well placed to absorb that in one pass instead of discovering it one refusal at a time.

What the pass turns up: schedule and targeting are ad-group concepts on this platform, so there is no campaign-level schedule to set and no campaign-level targeting to change. An instruction that would be a one-line campaign edit elsewhere resolves to a set of ad-group edits here, and the tool layer refuses the campaign-level form outright rather than choosing an ad group on your behalf.

The account brief still comes first for context — ninety days of coverage and 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. The media library is worth a read before any creative work: each asset carries the id the platform holds those bytes under, so a creative references an upload that already exists rather than sending the same file a second time.

One limit shapes every long question. Daily insights come back thirty days at a time — a hard platform limit rather than a preference — so a ninety-day range is three requests the sync plans for. 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 rather than leaving them to be found.

Money sits at the campaign or at the ad group, and which one is writable is a property of the campaign rather than of the platform: where 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 the draft decides which is writable now, and one aimed at the wrong one is refused rather than 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. On a platform with this many entity-level surprises that is the strongest argument for reading the structure into the editor first: the checks that exist are the ones that run before the draft is queued.

A removal is terminal. There is no archive state; the third status value is a delete and it cannot be undone. A reversible status change is the instruction of choice, and a removal is not something a 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 decides what can honestly be said after that. 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 offering 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 — which is the pair worth pasting into whatever note the work is being tracked in, since the session that made the change will not be open in a week. Pacing runs against the budget and schedule on the level that holds them from the moment an edit lands, which here means the level that actually owns the money for that campaign.