# Setup and Access

Configure your workspace, add people, then create a personal API key only if you need an MCP client or an allowed REST agent route.

## Open settings

1. Open **Settings** from the app sidebar.
2. Use **Workspace** for workspace name, color, and icon.
3. Use **API Keys** or **MCP Servers** under Developer & Integrations for agent access.

![Current Settings navigation](/docs/images/navigation/settings-navigation.webp)

Workspace member access is managed under **Admin → People & Access**. Role definitions are under **Admin → Permissions**. These pages require an account with the corresponding access.

## Add a workspace member

1. Open **Admin → People & Access**.
2. Select **Add person**.
3. Enter the person's email. Name and title are optional prefill fields.
4. Keep required workspace access enabled and choose **Admin** or **Member**.
5. Optionally enable one or more team checkboxes and choose the team role.
6. Review the seat impact and invitation details, then select **Send invite**.

The UI says the person receives a magic-link email and has seven days to accept. Sending an invite is an external email action. Use [Members and Roles](/docs/teams-projects/members-roles) to compare roles before sending it.

## Create and protect an API key

1. Open **Settings → API Keys**.
2. Select **Create API Key**, give the key a recognizable name, choose the **Area** (**All of iKanban** or **Security only**), and choose whether to make it read-only. A read-only key can read data through the API and MCP but cannot create or update anything.
3. Create the key, copy it from the reveal panel, and store it in your password manager or deployment secret store. The full key appears in a reveal panel after creation; store it before closing that panel.
4. Do not paste a key into documentation, source control, chat, or a shared screenshot.
5. Delete the key from API Keys to revoke it when it is no longer needed.

The MCP access switch and allowed-client list on **Settings → API Keys** apply to the account's API keys. Turning MCP off blocks those keys from MCP but does not change REST access; allowlist changes can take up to five minutes.

Keys use the `vk_` prefix. They authenticate as the key owner's user identity. They are not unrestricted: browser-session-only routes include key management, admin, billing, invitations, membership and role changes, sharing controls, and destructive deletes. Use a browser session for those operations.

## Connect an MCP client

1. Generate a key from **Settings → API Keys**.
2. In **Settings → API Keys**, review the **MCP access** switch and optional allowed-client list for your account. Client names must match exactly; an empty list allows any client.
3. Register `https://mcp.i-kanban.com/sse` in the MCP client using Streamable HTTP and an `Authorization: Bearer <key>` header.
4. Store the key through the client's secret or environment-variable facility.
5. Ask the client to call a read operation such as `list_teams` and confirm it returns only teams available to the key owner.

MCP client settings are per client. For the command-line examples and tool behavior, see [MCP Usage](/docs/mcp/mcp-usage-from-field).

## Use API keys with REST

Some agent-facing REST routes also accept a `vk_` bearer key, including supported issue, sprint, document, comment, deployment, and test-run operations. The key middleware applies a route deny-list; support for one endpoint does not mean every `/api` route is available to API keys. Check the current agent/API documentation for the exact operation and payload. Browser-session-only actions listed above stay unavailable to API keys.

![Admin navigation for People & Access and Permissions](/docs/images/navigation/admin-access-navigation.webp)

Use **Admin → People & Access** to invite workspace members. Use **Admin → Permissions → Show permission tables** to compare role capabilities without editing the interactive access matrix.

For example REST payloads used by Launch Readiness, see [Feeding Launch Readiness](/docs/teams-projects/launch-readiness). Treat those routes as a supported agent surface, not a promise that all REST endpoints are public or stable.

## Mentions use the current input surface

- **Task comments:** type `$` and select a person from Team member suggestions. `@` is used for agent commands in the issue comment surface. See [Creating Tasks](/docs/tasks/creating-tasks).
- **Team chat:** typed `@name` is not verified as a person mention or notification trigger. Use task comments for a person picker.

No invite or comment is required to configure the account. Role updates, invites, and API-key changes take effect only after you submit their respective controls.