Connect any MCP client to your accounts

Tempio's programmatic surface is a Model Context Protocol server. There is no separate REST API to learn and no second code path to reason about: the server and the in-app agent call the same organisation-scoped tool layer, so a capability behaves identically whichever client calls it.

The endpoint is a single streamable HTTP address. There is no server-sent-events transport to configure, and a client that insists on negotiating one will fail rather than fall back — a failure that reads like a bad credential and is not one.

Rate limits are a hundred and twenty requests a minute per address before authentication and sixty a minute per credential after it. A client that iterates over campaigns one at a time will find that ceiling; one that asks for the rows in a single call will not.

A bearer key. Minted in the product under Settings and then MCP, shown once, hashed at rest, revocable, and bound to one workspace for life. This is the right credential for anything you configure yourself: a terminal client, an editor, a server-to-server agent. Connect Cursor to your ad accounts is the configuration-file form of it.

An OAuth token. For a client that cannot send a header of its own — the ones a connector directory lists, typically. The client reads two discovery documents, registers itself, and sends you to Tempio to authorise it. On the consent screen you pick the workspace, see exactly what the client asked for, and decide separately whether it may approve; the connection is then bound to that workspace for life exactly as a key is. Those connections are listed on the same settings page with what each one holds and when it was last used, and revoking one refuses the connector's next call.

Past the door nothing knows which kind arrived. The scopes, the capabilities, the guardrails and the gate are identical either way.

One property holds for both and it is the property that makes a credential safe to hand out: the workspace is taken from the verified credential and never from a tool argument. Nothing in the surface accepts a workspace to name, so a client holding one credential reads one workspace and nothing else.

Every credential carries a surface, chosen when it is minted.

The default registers two tools. One describes the surface and one runs it, dispatching on an entity and an action onto the same capabilities the alternative exposes one tool each. It is the right answer for most clients, because a long tool list is a standing cost against the client's context on every single request.

The alternative registers each capability as its own tool, with the help tool beside them. Some clients genuinely handle that better than a dispatch tool.

Both reach the same capabilities under the same scopes and return the same answers. Nothing about the choice changes what is possible; it changes what the tool list costs.

The first call worth making is not a read of the account. It is the help tool.

The catalogue it returns is generated at request time from the same tables the tools run on — the route table, the tool registry, the change operations and their payload schemas, the warning registry, and each live connection's own capabilities — so it cannot drift from the surface. It is also filtered to the scopes the credential holds, which means discovery, description and execution agree with each other. A capability your credential cannot call is not described to you as though it could.

Two ways through it. Walking by path goes from the root down to one entity and then to one verb, and called with nothing it returns the shape of the whole thing: what Tempio is, the entity model, the verbs, the draft lifecycle, the rules about money and ratios, warnings and links, and two worked calls. Searching by keyword goes across names, descriptions and payload field names, which is how a client finds a capability nobody told it the path of.

On the compact surface, scopes are enforced on the call rather than by hiding the tool as the explicit surface does: a capability your credential cannot reach answers with the scope it needs and the scopes you hold, so an agent is told what to ask for instead of concluding the capability does not exist.

Worth knowing before you write anything that consumes results, because it is assembled in one place for every capability and its shape does not vary by tool.

Every call returns data, an optional report, and a warnings list that is always present and empty when there is nothing wrong. The report states once, authoritatively, what a scope covers: its currency, which is empty when the scope spans several, the time zone the dates are in, the date range, the entity level, and whether the scope is the returned rows or all of them.

Each warning carries a code, a class, a severity, a message saying what the condition means for the answer it travels with, and the deep link of the record it is about when it is about one record. Branch on the class rather than the code — the code set is open and adapters add to it, and a code with no registry row degrades to a generic class at the lowest severity while keeping its own message rather than failing the call. A warning never changes a value: a currency warning does not round a number and a staleness warning does not hide one.

Every record a result names carries an absolute link into the app, because an agent hands the string to a person and a relative path is not something a person can open. The link is built from a row a query already returned under the workspace, never from an identifier in the arguments, and it is not a grant — opening it needs a session and the page checks membership regardless.

The same from all of them. A drafting call takes a connection and a list of operations and writes them as one reviewable batch of up to fifty entries. Where entries depend on each other, a child names the index of the entry that creates its parent, so nothing carries an identifier that does not exist yet. What comes back is the batch, a link to the gate for the whole group, and the authority that cleared it.

Stated plainly, because a general guide is exactly where it gets assumed: your connections read your accounts. A change any client asks for is written as a draft on the record, with the state it would change from and the checks it passed. Applying it is gated on approval — by you, or by a rule you wrote — and no platform write reaches a customer account until that platform has granted write access. Applying a cleared change to a platform is in private beta.

Four symptoms cover nearly all of it.

No tools at all. The connection did not authenticate, or the transport is wrong. Check the header, check the credential's status on the settings page, and check that the client is not trying to negotiate a transport this server does not serve.

Fewer tools than expected. Either the credential is on the compact surface, where two tools reach everything, or its scopes are narrower than you thought. Both are visible on the settings page.

A capability refuses with a scope message. The credential holds less than the call needs, and the message names both. Mint a new credential rather than editing the old one.

Reads answer with nothing. The connection behind the account has not finished a sync. An account that has never synced is empty rather than broken, and the two are indistinguishable from a client.

What a connected client can then actually reach — which reads, which writes, and what it cannot see at all — is What an agent can reach in your account.

Why any of this is worth more than a protocol badge on a comparison table is MCP is a contract, not a feature.