> ## Documentation Index > Fetch the complete documentation index at: https://docs.cantina.xyz/llms.txt > Use this file to discover all available pages before exploring further. # Settings > Configure your workspace, manage members and access, and customize how your team works in Clarion. > Configure your workspace, manage members and access, and customize how your team works in Clarion. > Settings is where you configure your workspace and the people who work in it. **Members** - Invite teammates, set communication preferences, and manage workspace access. **Workspace** - Name your workspace, customize agent system prompts, and review onboarding choices. **SSO** - Enforce single sign-on through Microsoft Entra ID for centralized identity. **MCP access** - Connect Claude Code, Cursor, or headless scripts to the workspace via MCP. Workspaces are isolated tenants. Alerts, incidents, agents, monitors, integrations, and members all belong to one workspace. Most teams have a single workspace; larger organizations sometimes run separate workspaces for different business units or environments. ## Workspace > Name your workspace and customize agent system prompts. > Your workspace is the isolated tenant that holds everything Clarion knows about your security stack: alerts, incidents, agents, monitors, integrations, and members. ### What you can configure * **Workspace name and description**: Shown in the navigation, on emails, and on Slack messages from Clarion. * **System prompt customization**: Add organization-specific guidance every agent run inherits. Use this for context that doesn't fit in any one skill: terminology, escalation hierarchy, environment-specific quirks. > The workspace system prompt is appended to every agent run. Keep it short and high-signal. Long prompts compete with skill content for the agent's attention. ## Members > Invite teammates, set communication preferences, and manage workspace access. > Members are the people who can see and act in your workspace. Each member has access to alerts, incidents, agents, and tools, plus a set of preferences that determine how Clarion reaches them. ### What a member has * **Profile**: Linked to a Cantina identity (email, name). * **Communication channels**: Slack, Teams, Discord, Telegram, SMS, phone, email. Each member adds the channels Clarion should use to reach them. * **Preferred channel**: The default channel for alerts, approvals, and clarification requests. * **Email notification settings**: Toggle email alerts for incident and task assignments separately from the preferred channel. ### What you can do * **Invite** new members by email. * **Update** a member's communication channels and preferred channel. * **Remove** members who no longer need access. > A member's preferred channel determines where agent approval and clarification requests are sent. Make sure each member has at least one verified channel before assigning them to active agents. ## SSO > Enforce single sign-on through Microsoft Entra ID for centralized identity and access. > Single Sign-On (SSO) lets your team log into Clarion with their existing identity provider. Clarion currently supports Microsoft Entra ID (formerly Azure AD). ### What SSO gives you * **Centralized authentication**: Members log in through your IdP. No separate Clarion password. * **Lifecycle parity**: When a member leaves your organization in your IdP, their Clarion access goes with it. * **MFA inheritance**: Whatever MFA policy you enforce in your IdP applies to Clarion. ### Setup overview 1. Add Clarion as an enterprise app in Microsoft Entra ID. 2. Assign the users or groups who should have access. 3. Provide the tenant ID and any required claim mappings to Clarion through the SSO settings page. 4. Test sign-in with a non-admin account before enforcing SSO workspace-wide. See [Microsoft Entra ID](/clarion/integrations/microsoft-entra-id) for the full step-by-step setup. > Once SSO is enforced, members can only sign in through your IdP. Make sure at least one workspace admin has a verified IdP account before enabling enforcement. ## MCP access > Connect external MCP clients (Claude Code, Cursor, CI scripts) to your Clarion workspace. > Clarion exposes a workspace-scoped Model Context Protocol (MCP) server so external clients can - without the Clarion web UI - read alerts, incidents, tasks, monitors, and signals; operate the scheduler; author and edit agents and skills; browse and instantiate templates; and manage the workspace's default agent instructions. There are two ways to connect: OAuth (for IDE/agent clients) and long-lived API tokens (for headless ones). ### Where it lives In Clarion, go to **Settings > MCP access**. The page has two tabs: * **API tokens** - mint, list, and revoke long-lived bearer tokens. One row per token; the plaintext is shown exactly once at creation time. * **OAuth setup** - copy-paste snippets for Claude Code and Claude Desktop, plus a generic note for other MCP clients. No secrets to manage. The MCP endpoint itself is at `https:///api/mcp` (the OAuth setup tab fills in the right URL for your environment). ### Choosing a flow | | OAuth | Long-lived token | | --------------------- | ----------------------------------------------------------------- | -------------------------------------------- | | Best for | Claude Code, Cursor, any IDE/agent client that can open a browser | CI jobs, cron workers, headless scripts | | Setup | One browser sign-in, no secret to copy | Mint a token, copy it into the client config | | Revocation | From the client's settings | Revoke the row in **Settings > MCP access** | | Appears in token list | No | Yes | If a client supports OAuth, use it. The browser flow handles re-auth automatically when access expires; long-lived tokens never rotate and stay valid until revoked. ### Connecting via OAuth #### Claude Code (CLI) 1. Open **Settings > MCP access > OAuth setup** and copy the `claude mcp add` command shown there. It already contains the right URL for your workspace. 2. Run it: ```bash theme={null} claude mcp add --transport http clarion https:///api/mcp ``` 3. Start a session. On the first tool call Claude Code opens the Clarion OAuth grant page - pick the workspace and approve. The token is captured by Claude Code's local callback. #### Claude Desktop 1. Open **Settings > MCP access > OAuth setup** and copy the JSON snippet. 2. Paste it into `~/Library/Application Support/Claude/claude_desktop_config.json` (macOS) or the equivalent path on Windows/Linux: ```json theme={null} { "mcpServers": { "clarion": { "type": "http", "url": "https:///api/mcp" } } } ``` 3. Restart Claude Desktop. The first tool call triggers the same browser grant flow as the CLI. #### Other MCP clients Point any MCP client that speaks the [Streamable HTTP transport](https://modelcontextprotocol.io/specification/2025-03-26/basic/transports#streamable-http) at `https:///api/mcp`. The first unauthenticated request returns a `WWW-Authenticate` challenge that points at `/.well-known/oauth-protected-resource`; any spec-compliant client follows the metadata to discover the authorization server and complete the OAuth flow without extra config. ### Connecting via a long-lived API token Use this when the client can't drive an interactive browser sign-in. 1. In **Settings > MCP access > API tokens**, click **New token**. 2. Give it a label that lets you recognize it later (e.g. `CI nightly drift check`, `Cron worker`). 3. Click **Create token**. The dialog swaps to a one-time reveal - copy the plaintext **now**. Once you close the dialog the secret is gone for good. 4. Paste the token into your MCP client config as a `Bearer` credential: ```json theme={null} { "mcpServers": { "clarion": { "type": "http", "url": "https:///api/mcp", "headers": { "Authorization": "Bearer " } } } } ``` > A long-lived token grants full workspace access over MCP - not just reads and light triage, but **creating and editing configuration**: agents, skills, schedules, and the workspace's default agent instructions. Treat it like any other secret - keep it out of source control and rotate (revoke + re-mint) on a cadence that matches your other credentials. #### Revoking a token In the **API tokens** tab, click the revoke icon on the row, confirm, and the token stops authenticating immediately. Any client still using it gets a 401 on its next request. Revocation is one-way; revoked rows stay in the list with a "Revoked" badge so you can audit who created them and when. ### Available tools After connecting, the client sees the following workspace-scoped tools under the `clarion` server (so each one appears as `mcp__clarion__`). Every tool is scoped to the token's workspace: reads filter by workspace, cross-workspace lookups return an error rather than another tenant's data, and mutations are attributed to the operator who minted the token. #### Read & triage **Alerts** * `list_alerts` - paginated list, filterable by status / severity / search * `get_alert` - full alert detail by display number * `complete_remediation_item` - toggle a checklist item on an alert's remediation list * `retrigger_alert` - re-run triage agents for an alert (e.g. after deploying a fix) **Incidents** * `list_incidents` - paginated list with the same filters as alerts, plus search * `get_incident` - incident detail including linked alerts **Tasks** * `list_tasks` - paginated list, filter by status / priority / `alertNumber` (useful for "has this alert been escalated yet?") * `get_task` - single task by id **Monitors & integrations** * `list_monitors`, `get_monitor` - the workspace's ingestion sources, with sanitized per-type config (webhook secrets stripped) * `list_integrations`, `get_integration_health` - integration sync health (consecutive failures, pause state, auth errors); credentials are never returned **Signals** * `list_signals`, `get_signal` - the raw ingested events that feed alerts, before any alert fires **Schedules** * `list_schedules`, `get_schedule` - discover what's running in the workspace * `list_schedule_runs`, `get_schedule_run` - poll-friendly run snapshots * `run_schedule_once` - fire a schedule out-of-band without changing its cron cadence * `cancel_schedule_run` - cancel a pending or running execution * `create_schedule`, `update_schedule`, `set_schedule_enabled`, `delete_schedule` - full CRUD on recurring tasks #### Configure the workspace > Skill and instruction content is exchanged as **markdown** (with inline `` pills) and converted to/from Clarion's rich-text format automatically - you never handle the raw editor JSON. **Agents** * `list_agents`, `get_agent` - the workspace's triage agents and their linked skills/monitors * `create_agent`, `update_agent` - manage an agent's name, active state, linked skills, and linked **existing** monitors. Monitor *creation* stays in the Clarion UI - it involves webhook secrets and registration that aren't exposed over MCP. **Skills** * `list_skills`, `get_skill` - reusable workspace skills, instructions returned as markdown * `create_skill`, `update_skill` - author or edit a skill from markdown; tools are extracted from the inline `` pills, and edits snapshot a new version **Templates** * `list_skill_templates`, `get_skill_template` - browse the curated skill-template catalog * `create_skill_from_template` - instantiate a skill template into a *managed* workspace skill (auto-updates when the template changes; idempotent - returns the existing copy if already instantiated) * `list_agent_templates`, `get_agent_template` - browse the published agent-template catalog * `create_agent_from_template` - scaffold an agent plus its managed skills from a template, created inactive so you can review before it runs **Workspace** * `list_workspace_tools` - the action tools currently **available** to agents in this workspace. Only tools whose backing integration (and any required credentials or pauser config) is actually connected are returned - unconfigured ones are omitted - so this reflects what a skill can reference *today*. Includes the workspace's custom MCP servers, custom API/CLI toolsets, and Microsoft Sentinel tools. * `get_workspace_instructions`, `set_workspace_instructions` - read or replace the default agent instructions (markdown) applied to every agent in the workspace > Templates are a shared, platform-curated catalog. These tools only **browse** it and **instantiate** copies into your workspace - creating, editing, or deleting templates is admin-only and is not exposed over MCP. > The agent-side MCP server used by Clarion's own triage agents has a separate (broader) tool surface - agents see integration tools like `mcp__slack__*`, `mcp__okta__*`, `mcp__cloudtrail__*` etc. that aren't exposed externally. External MCP clients only see the workspace tools listed above. `list_workspace_tools` surfaces the *names* of the available integration tools so a skill you author can reference them by their `` type, but those tools still execute agent-side during triage.