Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/org-quicko/skillset/llms.txt

Use this file to discover all available pages before exploring further.

Tokens give the skillset CLI, the MCP server, and direct API clients a way to authenticate without a browser session. A Token is a 256-bit secret tied to the User who minted it, carrying that User’s full role. It is shown once at creation and stored only as a SHA-256 hash — there is no way to retrieve the secret after the minting confirmation screen is dismissed. If you lose it, revoke the old Token and mint a new one.

Minting a Token from the web interface

1

Open Settings → Tokens

Sign in to the web interface and navigate to Settings → Tokens.
2

Create a new Token

Click New Token, enter a descriptive name (e.g. ci-pipeline or laptop-cli), and confirm.
3

Copy the secret immediately

The secret is displayed exactly once. Copy it to a password manager or your CI secrets store before closing the dialog — the Registry stores only the hash and cannot show the secret again.
If you navigate away without copying the secret, the Token cannot be recovered. Revoke it and mint a fresh one.

Using a Token

# Store the token in the CLI's credential store for subsequent commands
skillset login --registry https://skills.example.com --token <secret>

# After login, normal commands authenticate automatically
skillset publish
skillset install my-skill
The SKILLSET_REGISTRY and SKILLSET_TOKEN environment variables are the recommended approach for CI pipelines. Any skillset command that would otherwise prompt for credentials reads these variables instead, and --json makes every command non-interactive with machine-readable output on stdout and errors on stderr.

Using a Token with the MCP server

Pass the Token directly to the MCP server at startup, or set SKILLSET_TOKEN in the environment where the server runs:
npx -y @in-org-quicko/skillset-mcp --registry https://skills.example.com --token <secret>

Listing your Tokens

The API returns the id, name, and creation timestamp for every Token you hold. The secret is never included in any listing response.
GET /api/users/me/tokens HTTP/1.1
Host: skills.example.com
Authorization: Bearer <secret>
Example response:
[
  {
    "id": "01932b5f-1234-7abc-8def-000000000001",
    "name": "ci-pipeline",
    "created_at": "2024-11-01T09:00:00.000Z",
    "last_used_at": "2024-11-15T14:23:11.000Z"
  },
  {
    "id": "01932b5f-5678-7abc-8def-000000000002",
    "name": "laptop-cli",
    "created_at": "2024-11-03T16:45:00.000Z",
    "last_used_at": null
  }
]

Revoking a Token

You can revoke a Token from the web interface or directly via the API.
Navigate to Settings → Tokens, find the Token by name, and click Revoke. The Token is invalidated immediately — any in-flight request using it after revocation will receive 401 Unauthorized.

Security considerations

A Token minted by a Writer can publish and import Resources. A Token minted by an Admin can create and remove Users. There are no scope or permission restrictions beyond the User’s existing role. Mint Tokens with the least privileged User account appropriate for the task.
Because Tokens are stored only as hashes, the Registry cannot rotate them for you. If a Token is exposed — in a log file, a public repository, or a leaked environment — revoke it immediately from Settings → Tokens or via DELETE /api/users/me/tokens/:token_id, then mint a replacement.
The Registry re-reads the User’s current role from the database on every authenticated request (session or Token). If the issuing User’s role is changed or the account is removed, the Token’s effective permissions change immediately — no re-issue is required and no cached state lingers.
Name Tokens after where they are used (ci-pipeline, laptop-cli, staging-mcp). This makes it straightforward to identify and revoke a specific credential without affecting others when a machine is decommissioned or a pipeline is retired.

Build docs developers (and LLMs) love