MCP keys

A key is how your own AI reaches a Tempio workspace. It is minted under Settings → MCP, carries the scopes you chose, and is bound to that one workspace for as long as it lives. What it can call once it arrives is the MCP reference; this page is the credential itself.

Minting one

The form asks three things.

A name. What the key is for — "Claude Code", "the build server". It is what you will read when deciding which one to revoke a month from now, so name it after the thing holding it rather than after the day you made it.

Scopes. Two checkboxes over three scopes:

Scope	What it unlocks	Default
`read`	Everything readable in the workspace: connections, accounts, structure, metrics, drafts, plans, media	Always on. It cannot be turned off, because a credential that cannot read cannot do anything useful
`draft`	Writing change requests, editing them, reverting an applied change, and everything on media plans	On
`approve`	Applying an approved change to a live platform	Off

approve is the one to think about. A key holding it can apply a change, including one it drafted itself — and the record says so, because a key approving its own work is a different fact from a person approving it. Leave it off unless the client holding the key is something a person drives, and even then consider two keys: one for the agent that reads and drafts, one for the tool a person uses to clear the queue.

A tool surface. Which tools the client sees when it connects:

Surface	What the client sees	Use it when
`compact` (default)	Two tools: `tempio_manage` to run things and `tempio_help` to describe them	The client is context-bound, which is most of them
`explicit`	Every capability as its own tool, with `tempio_help` beside them	The client handles a long tool list better than a dispatch tool

Both reach the same capabilities under the same scopes and give the same answers. The choice is only how much of the client's context the tool list costs.

New key opens a dialog; Create key in it shows the key once, and the dialog stays until you press Done. It starts tmpio_, and this is the only time it is displayed: only its prefix and a hash of it are stored, so nobody — including Tempio — can read it back to you. Copy it into the client now; a key you did not save is a key to revoke and mint again.

Using one

Send it as a bearer token on the endpoint the settings page shows. Claude Code:

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

Cursor, in mcp.json:

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

Any client that can send an Authorization header over streamable HTTP works the same way. The workspace is taken from the verified key, never from a tool argument, so there is no parameter that points a call at somebody else's account.

The list

Each key on the page shows its prefix, its name, when it was last used, and whether it is active or revoked. The last-used stamp is written on every verified call; a key that has never been used has none, which is usually the sign that the client never actually connected.

Revoking

Open the key's row menu, choose Revoke and confirm. The next call it makes is refused; nothing else changes, and nothing it already drafted is affected — a change request records the key that wrote it, and revoking the key does not un-write the row.

Revoked keys stay on the list as a record, and they hold no allowance: they grant nothing, so they cost nothing against your plan's key limit and never block a replacement being minted. Rotating a key is therefore mint, move the client onto the new one, then revoke the old one, in that order.

A key dies with the membership that minted it

Membership is re-read on every call, not checked once on the day the key was created. Remove the person who minted a key from the workspace — or delete their account — and every key they minted stops answering in the same moment, with nothing to revoke by hand.

That is worth planning around. A key minted by somebody who later leaves takes its integration down with them, silently, from the integration's point of view. For anything that has to outlive one person, mint it under an account that is not going anywhere and say so in the key's name.

How many

Active keys count against your plan's allowance. When you are at the limit, minting is refused with a line saying so — revoking one you are not using frees the slot immediately. Billing has the numbers.

The other credential

A client that cannot send a header of its own signs in with OAuth instead. It reads two discovery documents, registers itself, and sends you to Tempio to authorise it; you pick the workspace and the scopes on the consent screen, and the connection is 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 — as does leaving the workspace. Connector OAuth has the flow.

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

Keeping one safe

A key is a workspace credential, not a personal one. Treat it like a production secret: an environment variable, a secret store, never a commit and never a screenshot.
One key per client. Shared keys cannot be revoked without taking down everything else holding them, and the last-used stamp stops meaning anything.
Mint the narrowest scope that works. A read-only key handed to something that only answers questions cannot draft, cannot approve, and is one less thing to think about.
If a key has leaked, revoke it first and investigate after. The audit log records what it did under the mcp actor type, and that record survives the revocation.

On this page