How to scope an MCP key

Every key carries read, whether or not you asked for it. A credential that cannot read cannot do anything useful, so read is not optional and not a choice.

Draft and approve are independent additions. The check a capability makes at request time is an exact match on the one scope it needs rather than a comparison against a rank, which has a consequence people find surprising and then find useful: a key holding approve and not draft can clear a batch at the gate and cannot write one. That is a real key for a real job — a tool somebody uses to work through a queue that an entirely different agent filled.

Read covers the whole surface a reader wants: connections and their status, ad accounts, campaigns including the ones not delivering, the structure underneath them, the media library, metrics, the list of change requests, and media plans. It alters nothing, anywhere.

Draft covers writing change requests, editing the payload of one still waiting at the gate, reverting an applied change by drafting its inverse, and every write on media plans — reading a plan or listing them is read, like everything else that reads. Nothing it writes is a change to an ad account.

Approve covers clearing a batch at the gate, and rejecting one so that it can never be cleared. It is off by default at the mint and the in-app agent never holds it.

On the explicit surface, capabilities are registered per request against the scopes the key carries. A read-only key does not see the drafting capabilities at all — they are absent from the client's tool list rather than present and refusing.

That is the cheapest guardrail in the system, because it needs nobody to remember it. An agent cannot be argued into calling something that was never offered to it, and the class of problem where a model is talked into a tool it should not use simply has no surface here.

On the compact surface, where two tools reach everything, the same rule holds one level down: a capability the credential's scopes do not cover answers with the scope it needs and the scopes you hold, so the agent is told what to ask for rather than left to conclude the capability does not exist. The catalogue the help tool returns is filtered the same way, so discovery and execution agree.

Start with read. It answers every question about the account, it cannot alter anything, and it is enough to find out whether an agent is useful on your accounts at all. Most people who mint a read key never need a second one. If you are evaluating a client you do not yet trust, this is the only correct answer.

Add draft when you want preparation rather than description. The difference is real: a draft-scoped agent hands you a batch to look at instead of a paragraph telling you what it would do. The failure mode is a queue of change requests nobody wanted, which costs an afternoon and no money — every row records the state it would change from, nothing has reached a platform, and rejecting a batch is terminal.

Add approve deliberately, to one key, and know what you have done. An approve key can clear a batch without asking, which is the correct arrangement for an automation you wrote and a poor one for a client you are still evaluating. The shape holds either way, because the inverse of anything cleared is a draft somebody can write at the same gate — but a record is only useful if somebody reads it, so give an approve key a job specific enough that you would notice it doing something else.

A key holding both draft and approve can approve its own work, and the record says exactly that: the gate reads that the approving key is the key that drafted the change. If that sentence makes you uncomfortable, the remedy is two keys rather than a setting.

Worth being explicit, because scopes are often assumed to be the only limit.

A scope never raises a guardrail. The connection's kill switch, the account's own daily ceiling, the movement rule, the first-budget cap and the rolling twenty-four-hour aggregate of applied increases are checked when a change request is written, again at approval, and once more immediately before a platform is called. An approve-scoped key meets all of them.

A scope never widens a rule. An approval rule your workspace wrote clears pauses, budget decreases and bid decreases under a cap it states in a currency it states, and nothing else — no creates, no uploads, no removals, no increases, nothing whose direction cannot be read.

A scope never reaches a second workspace. The workspace comes from the verified key and no capability accepts one to name. Two workspaces is always two keys; Run one agent across several ad accounts is the shape of that.

And a scope never survives its creator. Membership is re-read on every call rather than checked once at the mint, so a key minted by somebody who later leaves the workspace stops answering in the same moment. For anything that has to outlive one person, mint it under an account that is not going anywhere and say so in the name.

Underneath all of it, the arrangement the scopes sit on top of: your connections read your accounts, a change 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.

A key also carries a tool surface, and it is not a security control. Compact registers two tools that dispatch onto every capability; explicit registers each capability as its own tool. Both reach the same capabilities under the same scopes and return the same answers, and choosing one over the other changes only what the tool list costs the client in context.

Do not reach for explicit as a way of restricting anything. The scopes are the restriction; the surface is an ergonomics choice.

Name the key after the thing holding it. "The nightly reporting job" tells you whether to revoke it. "Key 3" does not.

One key per client. A shared key cannot be revoked without taking down everything else holding it, and the last-used stamp on the settings page stops meaning anything the moment two things use it.

Rotate in this order: mint the new key, move the client onto it, revoke the old one. Revoked keys stay on the list as a record and hold no allowance, so they cost nothing against your plan's key limit and never block a replacement. Revoking first is an outage you chose.

Revoke on suspicion, investigate afterwards. The next call the key makes is refused and nothing else changes. Nothing it already drafted is affected, because a change request records the key that wrote it and revoking the key does not un-write the row. The audit log holds what it did under its own actor type, and that record survives the revocation.

Once the key is scoped and the client is connected, First prompts for your ad accounts is where to point it, and What an agent can reach in your account is the honest inventory of what it can and cannot see.