Cursor, with your ad accounts in its tool list

Cursor reads its MCP servers from a JSON file and shows you the tools each server exposed. That is the entire integration story, and the rest of this page is about what sits behind the endpoint rather than about the four lines of configuration.

One Model Context Protocol server over streamable HTTP, authenticated with a bearer key minted in the app. The editor's agent and the in-app agent call the same org-scoped tool layer, so a tool answers identically whichever one holds it, and the workspace is read from the verified key rather than from anything the agent asks for.

Scopes decide the rest. Reading covers connections, ad accounts, campaigns, structure, media assets, metrics, drafts and media plans. Drafting writes change requests and edits media plans, and nothing it writes reaches a live ad account. Approving applies or rejects a pending draft and is opt-in when the key is minted. Tools are registered per request against the key's scopes, so the list the editor shows you is the list that key can actually call — if the drafting tools are missing, the key is read-only, and that is the gate rather than a failed load.

Mint the key in the app under Settings and then MCP. It is shown once, hashed at rest, revocable and scoped to one workspace. Then add the server to Cursor's MCP configuration:

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

A configuration file that lives inside a repository is shared by everything that clones it, so a key belongs in the one that does not. Keep the server definition wherever your team keeps its own secrets, and revoke the key in the app rather than rotating it by hand if it ends up somewhere else.

Then open the editor's MCP settings and read the tool list. That list is the handshake: it is the server answering with the tools your key's scopes allow, and a server that connected but shows no tools is a key with no scopes rather than a broken endpoint.

The reads are the useful half on day one, and the account brief is where to start. Ninety days per connected ad account: coverage, totals, a twenty-eight day period set against the one before it, the objective mix, how concentrated spend is, which campaigns rank on return, which rank worst on cost per acquisition, which weekdays are cheapest, and a note saying which accounts have no brief and why. It carries the moment it was computed and flags itself as stale past a week, so an agent quoting it says how old it is.

From there: blended KPIs with a per-platform breakdown over a range; per-campaign rows highest spend first, each in its own account's currency with a marker saying whether that order is a ranking at all; the structure beneath any campaign or ad group with the operations each row can express; and the media library with the id the platform holds each asset under.

Money is integer minor units with an explicit currency, everywhere, with no exceptions and no inference. Ratios are computed at read time from base counts, and a zero denominator yields null rather than zero — which means an editor-side agent cannot quietly turn a missing CPA into a flattering one.

It looks like a pull request, which is the comparison the tool was built against. One call writes a batch of changes as change requests in the order they apply, each entry able to name the earlier entry that creates its parent, so a campaign, its ad group and the ad inside it arrive as one group with one review link rather than three separate acts.

The reply carries the batch, that link, 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 clears it, whether that was a person, a key or a policy. A draft that needs an edit has its payload replaced whole, which re-validates it and re-runs the guardrails; a change that already landed is undone by drafting its exact inverse at the same gate.

An agent working in an editor is fast, and that is exactly why the seam matters. The speed belongs in the reading and the drafting. The applying belongs to whoever holds that permission, and the record says which one it was.

It is good for the work that benefits from context: reading a quarter of numbers into a summary you can edit, shaping a media plan in a document beside the tools that will turn it into drafts, writing the naming conventions a batch should follow and then having the batch follow them. A media plan is a working document with a brief, a window, a currency and items carrying whole-flight budgets, and turning one into drafts at the gate is a single call — which is the shape of work an editor is built for.

It is not a dashboard and it does not try to be. Nothing here renders a chart, and the numbers it reads are the same numbers the app shows, from the same tool layer. Where the app is better is the review queue itself: a batch with a review link is meant to be opened by a person, and the client's job is to hand that link over rather than to approve on your behalf.

For one client on one platform, end to end — the connection, the reads it answers and the change that comes back — there is a walkthrough of a single account.

The approval gate is where those drafts wait. The media plan is where a flight is shaped before any of them exist. The MCP server page is the same story from the product's side.