# nLight.fit token management

Long-lived API tokens are minted in the app, one per client, and revoked from the same place. Claude can skip this entirely and connect over [OAuth](/docs/mcp#connecting-over-oauth). Everyone else — Cursor, Claude Code with a header, a custom client — needs a token from here.

## Mint, list, revoke

Open **Settings → MCP / CLI Access**.

1. Give the token a name you will recognise later (`cursor`, `claude-code`).
2. Generate it. The plaintext is shown **once**. It is stored hashed, so it cannot be displayed again.
3. Paste it into the client snippet on that same page, or into the config in [client setup](/docs/clients).
4. Revoke it from the list when you stop using that client, or if you think it leaked.

Each token is independent. Revoking one integration does not disturb the others, and the last-used timestamp tells you which one is actually being called.

Connectors you approved over OAuth appear in the same list, under the name of the application that asked. Revoking one disconnects that client on its next request.

## What you are granting

A token minted here carries `read`. That is every MCP tool today. Nothing on this endpoint accepts `write`, and an OAuth consent screen cannot issue it either. See [authentication](/docs/authentication).

## Storing the token

Treat it like a password with no expiry. Put it in your client's configuration or an environment variable; keep it out of source control, screenshots and shell history files that sync.

If you are unsure whether one leaked, revoke it. Minting a replacement takes a few seconds and the old one dies on the next request.

## Related

- [Authentication](/docs/authentication) — token format, scopes and storage
- [Client setup](/docs/clients) — wiring the token into an MCP client