Skip to main content
The token your first mcp apply returns allows every selected operation and never expires. That is a fine default for your own testing and a poor one for an agent running unattended. A token can only ever narrow what its MCP version already exposes. It cannot grant an operation the server does not offer, so scoping a token is always safe in the sense that it can only reduce reach.

​
Generate a narrowed token

Both are yours to choose: the first identifies the MCP server, the second names this particular token so you can revoke it by name.
Anything absent from --allow is denied. Repeat the flag, or pass a comma-separated list. Omit it entirely and the token defaults to full access (*). Unified operations do not introduce a separate token scope. A narrowed token must allow the physical forward operations and any active rollback that the Unified graph can execute. search_docs exposes only Unified descriptors fully authorized by that token, and the Engine repeats authorization for the caller’s selected graph before dispatch. Supplying targets cannot broaden the token.
The plaintext prints exactly once. Capture it immediately — mcp token list shows status and metadata but never the token or its hash.

​
Flags

​
mcp token generate

--expires-in takes a positive whole-second duration such as 15m, 4h, or 7d. Omit it for a non-expiring service credential. --fixed-binding belongs to the connected-user story — see tokens for OAuth services. For a fixed token, the stored service/auth/user/resource binding is authoritative even if a Unified call supplies a conflicting selector.

​
One token per audience

Give each agent, environment, or job its own named token. It costs nothing and makes revocation a decision about one caller rather than a decision about everyone.

​
List and revoke

The listing includes active, expired, and revoked status, binding mode, and aggregate execution and session counts from retained history.
Ending an MCP session is not revocation. A session DELETE closes that session; the token stays valid until you revoke it.

​
Tokens and versions

MCP execution tokens are shared across every version of a server. A token issued today keeps working when you publish a new version tomorrow — while each version still enforces its own operation scope. If two audiences must not share capability, deploy two MCP servers rather than trying to split one token between them.

​
Permissions

Generating, listing, and revoking tokens all require app.tokens.manage. That is deliberately separate from app.manage: a team can own and update an MCP server without being able to mint credentials for it, or the reverse. Applications that need to issue tokens for dynamic agent sessions can use the Engine’s equivalent app-token API. The caller still needs app.tokens.manage.

​
Sharing the server itself

Ownership and audience are separate concerns. The owning person or team keeps management authority even when the server is offered company-wide:
That adds bounded workspace-wide use across every version without handing over token or lifecycle management — and callers still need an execution token at runtime.

Tokens for OAuth services

When the provider needs to know which end user the agent is acting for.