Core purpose
API tokens suit personal scripts, command-line tools, development environments, and controlled automation. They are not another account password: each is a dedicated key that can open only required operations, be revoked at any time, and is subject to quotas and auditing.
What is available now
- Create a named token for a purpose with the least necessary permissions.
- Display the complete secret only once at creation; the server stores a one-way hash.
- Use the same access vocabulary and templates as platform policy.
- Activate, disable, or revoke an individual token without affecting an account’s other credentials.
- Set operation-specific API quotas and limits.
- View token status in personal settings and platform administration.
- Call permitted operations with standard API-token authentication.
Least privilege
Start from a concrete task: reading public works, updating particular metadata, or managing one’s own content. Even when the account has broader authority, a token receives only the explicitly granted scope. The server still checks the target unit, Realm, and operation.
Quotas and observable failure
A quota is not one global rate. API workloads differ, so operation-specific limits give large imports, ordinary queries, and sensitive writes separate boundaries. Limit exceeded, insufficient permission, revoked credentials, and data conflicts must all return identifiable errors.
Safe use
Never put a complete token in public code, chats, browser history, logs, or version control. Revoke and recreate it immediately if exposed; clean up unmaintained tokens regularly.
Relationships and boundaries
Tokens do not provide third-party user authorization—that is OAuth’s role—and do not automatically become MCP credentials. Future tool integrations may use tokens or OAuth, but both must obey the same server-side permissions and quotas.