User settings

Manage access tokens

Personal access tokens (PATs) authenticate you for API and MCP clients without an interactive browser login—for example the Modelling Support MCP server used in reverse engineering.

Open User settings from the header Settings icon, then go to the Access tokens tab.

⚠caution

The full token value is shown only once when you create or rotate it. Copy and store it securely; you cannot display it again later.

Create an access token

1. Click Create access token.
2. Fill in the form:

Field	Description
Token name	Unique name for this token (required).
Description	Optional note about where the token is used.
Expires on	Expiry date (required). Maximum lifetime is one year from today.

3. Click Generate token.
4. In the confirmation dialog, copy the token (it starts with k5pat_) and store it safely, then close the dialog.

Manage existing access tokens

The Access tokens tab lists Active tokens and, when present, Inactive tokens (revoked or expired).

Action	What it does
Rotate token	Issues a new secret for that token entry. The previous secret stops working immediately. Copy the new value from the dialog—it is shown only once.
Revoke token	Immediately invalidates the token. It moves to the inactive list and can no longer authenticate.

Only administrators can delete tokens. They manage tokens for all users under Admin settings → Access management.

Manage Git Tokens

To access the User Settings use the Settings capability on the top right of the page and navigate to the User Settings page.

Create a Git Token

Each user can have only one token for each Git provider for which he has rights. To create a new token use the header capability Create in the Git tokens tab on the User Settings page.

A Git token is defined using the following master data:

• Token name: Name of the token. (required, unique for each user)
• Git provider: List of all Git providers for which the current user has access permission. The Git providers are represented with their assigned alias that was provided by the admin user (required)
• Git access token: The actual Git token (required)
• Git username: The username as defined in the Git provider (required)

💡tip

By using the default Verify and Create the provided Git username and Git access token will be validated before the creation. In case of incorrect data you will get an error notification. If you want to use that data anyway please choose the Create button.

Verify a Git Token

To verify a Git token use the inline or header Verify capability. You will get either a "Success" or an "Error" notification displayed.

Delete a Git Token

To delete a Git token use the inline or header Delete capability. After you confirm the action the Git token will be permanently deleted.

Update a Git Token

In order to update a Git token use the inline or header Edit capability. This action only allows a change of the access token itself. If your username has changed delete the previous Git token and create a new Git token for the same Git provider. After saving the changes, all Pipeline Configurations using your personal credentials will also be updated.

Manage AI API keys

Generative AI capabilities can be configured centrally by your administrator via the k5-ai-credentials secret — see AI providers. When central credentials are configured, Design Assistant, ADR Sidekick, and Diagram Assistant are available without a personal API key.

Alternatively, users can provide their own API key in User Settings for these capabilities. Personal keys support OpenAI platform and OpenAI on Azure. If you have access, you can create an API key directly from your platform or by contacting your system administrator.

❗️info

The user based API keys does currently not work with Amazon bedrock API keys.

Create an AI API key

To create a new AI API key use the header capability Create in the AI API tokens tab on the User Settings page.

An AI API key token is defined using the following master data:

• AI API Key: API key created through the AI provider platform (required)

Delete an AI API key

To delete an AI API key use the inline or header Delete capability. After you confirm the action the AI API key will be permanently deleted.

Update an AI API key

In order to update an AI API key use the inline or header Edit capability. This action allows you to change the API key. After changing the key, the new key is immediately applied for future calls to the AI provider.

Manage design recipes

Upload personal design-recipe packages so the Design Assistant can use your own skills and commands in addition to the recipes linked to the project baseline.

Open User settings from the header Settings icon, then go to the Design recipes tab.

ℹ️note

Any authenticated user can manage their own recipes — no admin role is required.

User-specific recipes are a separate, per-user list. They do not replace tenant or baseline recipes. When a personal recipe is enabled, the Design Assistant applies it on every query, independent of which baseline the current project uses. That makes personal recipes useful for:

• Your own recurring commands and skills
• Trying new skills and commands before they are published in Admin Settings and attached to a baseline for other projects

For concepts, authoring, and how personal recipes relate to baseline recipes, see Design recipes. For the ZIP format, see the Design recipe reference.

View your design recipes

The overview lists your uploaded recipes in table or card view. Metadata such as Name, ID, Description, Version, Enabled, Tags, and Last modified comes from the package after upload — you do not enter it in a separate form.

If you have no recipes yet, the empty state invites you to add one.

Add a design recipe

1. Click Add design recipe.
2. In the sidebar, upload a ZIP file under Design recipe file (drag and drop or click to select).
3. Click Add.

On success, the sidebar closes and the list refreshes. On failure, the UI shows an error (including the server message). Validation runs on upload — there is no separate validate step. Name, ID, version, description, and tags are taken from the package metadata (k5-design-recipe.yaml).

Manage an existing design recipe

Each recipe offers actions such as:

Action	What it does
Upload new file (replace)	Opens Update design recipe and replaces the package with a new ZIP (same upload flow as add; no overwrite confirmation).
Download file	Downloads the recipe as {id}-{version}.zip.
Enable / Disable	Turns the recipe on or off. Only enabled recipes contribute skills and commands. Disable has no confirmation.
Delete	Removes the recipe permanently after a confirmation dialog.

Upload, download, or delete may be unavailable if the API does not allow that action for the recipe.

How personal recipes appear in the Design Assistant

Commands from your enabled user recipes appear together with baseline recipe commands:

• As / slash commands in the Design Assistant chatbot
• As actions on selected model elements (when the command matches the selection)

Selecting a command loads its prompt into the chatbot. Skills from enabled personal recipes are considered on every query, the same way as baseline skills. Disabled recipes remain in your list but their skills and commands are not offered.

Manage custom MCP settings

Attach personal MCP configuration to an external system that an administrator already registered. You do not create a new MCP server. You pick an existing system and store your custom configuration so the Design Assistant can call that MCP server. For how the assistant uses these connections in chat, see MCP support.

A typical use is e.g. that users add their own personal API keys as Authorization header so that the MCP calls user the right authorization. The shared connection stays under Admin settings; only the user-specific extras live here.

Open User settings from the header Settings icon, then go to the External systems tab.

ℹ️note

Any authenticated user can manage their own custom MCP settings — no admin role is required. You only see and edit your settings, not those of other users.

User headers are applied in addition to the headers from the admin configuration. You cannot change the MCP endpoint URL, description, or timeout — those stay in Admin settings → External systems.

ℹ️note

The design assistant MCP client supports neither OAuth nor dynamic client registration in the current version. Provide your authorization credentials for the external MCP server as headers here, or rely on headers configured in Admin settings. See MCP support.

Admin settings vs user settings

	Admin settings	User settings
Purpose	Register the MCP external system	Personal MCP settings for that system
What you configure	Name, MCP endpoint URL, description, headers, default arguments, timeout, enabled	Headers, default arguments, enabled
Name	Free-text, must be unique	Dropdown of enabled admin systems only
Headers	Base headers for everyone	Extra headers for this user
Who can see them	Administrators	Only the signed-in user

If an administrator disables a system, it does not appear in the Add custom MCP setting dropdown. If only one enabled admin system exists, it is pre-selected when you add a setting.

View your custom MCP settings

The overview lists your custom MCP settings in table or card view.

Column	Description
Name	The administrator-defined system (for example JIRA)
Headers	Checkmark if you defined any headers (values are not shown in the table)
Default arguments	Checkmark if you defined any default arguments
Enabled	Whether the external system is enabled for you (if disabled in admin settings, the system cannot be enabled in the user config)

To see all details, click a row or a card to open them in the side panel.

Add a custom MCP setting

1. Click Add custom MCP setting.
2. In the Add custom MCP setting sidebar, fill in the fields:

Field	Description
Name	Required. Select an enabled administrator-defined MCP external system.
Headers	Optional key/value list. These headers are applied additionally to the headers defined for the external system in Admin settings.
Default arguments	Optional key/value list (same editor as headers).
Enabled	Checkbox, on by default.

3. Click Add, or Cancel to abort.

Headers and default arguments

Headers and default arguments use the same key/value editor. Each entry has:

Field	Description
Key	Required.
Value	Optional.
Secure	If set, the value is hidden after save (*****************) and is not shown again. Use this for credentials such as an Authorization header with a personal token.

⚠caution

If an entry is marked Secure, the value is not available to view after you create it. This protects sensitive data from being exposed.

Action	What it does
Add	Opens a sidebar to add a key/value entry. Optionally create another entry afterwards.
Edit	The key is read-only. You can change the value and the Secure flag.
Remove	Select one or more rows and remove them.

A typical secure header is Authorization with a personal API token. For Jira via the Atlassian Rovo MCP server, that header must be HTTP Basic authentication (Basic plus Base64 of email:api_token), not Bearer. See the Jira integration example.

Manage an existing custom MCP setting

Click a row (or a card) to open the details side panel and edit them.

To delete custom MCP setting, use Delete custom MCP settings from the row overflow menu and confirm. Deleting removes only your custom settings, not the administrator-defined system.

What you cannot do here

• Create a new MCP endpoint or invent a new system name
• Change the URL, description, or timeout of an external system
• See or edit other users' custom settings
• View secure values after they are saved
• Add a custom setting for a disabled administrator-defined system
• Authenticate with OAuth or dynamic client registration — credentials must be provided as headers