Personal Access Tokens

A Personal Access Token (PAT) is how the Bolti MCP server authenticates as you. Every token starts with the prefix mcp_ and is passed to the server through the BOLTI_API_TOKEN environment variable (or the login_with_token tool at runtime).

The key principle: a token carries the creating user's permissions and no more. The MCP server can never do anything you could not do yourself in the dashboard. Access is enforced by the Bolti backend on every call against your workspace membership and role.

Create a token in the dashboard (recommended)

1. Open the Bolti dashboard.
2. Click your profile at the bottom-left of the sidebar.
3. Go to Access Tokens -> Create Token.
4. Give it a name, choose a scope and optional expiry (see below), and create it.
5. Copy the token immediately. It is shown only once and cannot be retrieved later.

Paste the token into your client configuration as described in Installation.

Scope: all workspaces or one

Every token has a scope, chosen at creation time:

Scope	What it can reach
Unscoped	All workspaces you are a member of.
Workspace-scoped	Exactly one workspace. It cannot access any other workspace, period.

Workspace scope is enforced by the backend, not just a client-side hint. A workspace-scoped token used against a different workspace is rejected. Scoping to a single workspace is the safest default when a token only needs to operate in one place.

Expiry and revocation

• Expiry is optional. Setting an expiry date means the token stops working automatically after that date, which limits the blast radius of a leaked token.
• Revoke anytime in the dashboard under Access Tokens -> Revoke, or from chat with the token_revoke MCP tool.

Revocation requires confirmation

token_revoke is a destructive tool. It requires an explicit confirm: true argument. Called without it, the tool returns a CONFIRMATION_REQUIRED error so your client can check with you before revoking.

Managing tokens from chat

You can also work with tokens through the MCP server itself:

Tool	Purpose	Notes
tokens_list	List your tokens with their names, scopes, and expiry.	Token values are never returned.
token_create	Create a new token from chat.	The value is shown once in the response.
token_revoke	Revoke a token.	Requires confirm: true.

Creating tokens in the dashboard is still recommended - it keeps token creation on a trusted surface and makes the one-time value easy to copy safely. Read tools never return token values; you will only ever see a token's value at the moment it is created.

How tokens fit the safety model

Personal Access Tokens are the foundation of the MCP server's safety guarantees:

• Least privilege. The token has your permissions, no more. A viewer-role member cannot create, update, or delete resources or place calls, no matter what they ask the model to do.
• Workspace isolation. A workspace-scoped token is walled off from every other workspace by the backend.
• Write-only secrets. Even with a valid token, read tools never return sensitive values such as tool credentials or SIP trunk passwords - they show a redacted placeholder.
• Confirmation gating. Destructive or billed actions still require confirm: true regardless of your token's permissions.

For the full picture, see the Safety section in the Overview.

Best practices

Token hygiene

• One token per machine or client. If a laptop is lost, revoke just that token without disrupting your other setups.
• Scope to a workspace whenever a token only needs to operate in one workspace.
• Set an expiry so forgotten tokens age out on their own.
• Revoke unused tokens promptly - list them with tokens_list and clean up.