Skip to main content
From /m/:id/keys, use the row’s actions and confirm.

​
It takes effect immediately

Resolved keys are cached in memory for five minutes so ingest never costs a database round trip per batch. Revoking clears that cache, so a revoked key stops working now rather than eventually.

​
What happens to a server still using it

Nothing bad. The SDK never throws and never blocks:
  • Tool calls keep working exactly as before. Your users notice nothing.
  • Flushes are rejected and the batch is dropped. No retry, no backlog, no growing buffer.
  • Nothing is logged unless debug is on.
That silence is deliberate — see the three rules. It also means a server whose key you revoked will sit there reporting nothing indefinitely, so update its environment when convenient.

​
Revoked, not deleted

The row stays with a revoked_at timestamp, so the key remains explicable. See List keys. There is no un-revoke. Mint a new key and update the environment.

​
Rotating a key

Do it in this order and there is no gap in your data:
1

Create the new key

On the same MCP. Several live keys is fine — they all report into the same place.
2

Deploy the new key

Update MCPULSE_KEY and restart. A restart opens a new session, which is expected.
3

Confirm data is arriving

Check the calls chart, or turn on debug on one instance.
4

Revoke the old key

Now, not before.
Revoking requires the admin role or higher — the same bar as minting. Revoking a key stops a live server reporting, so it needs the write bar rather than mere membership.