MCP access

​

Where it lives

In Clarion, go to Settings > MCP access. The page has two tabs:

• OAuth setup — copy-paste snippets for Claude Code and Claude Desktop, plus a generic note for other MCP clients. No secrets to manage. This is the tab the page opens on.
• API tokens — mint, list, and revoke long-lived bearer tokens. One row per token; the plaintext is shown exactly once at creation time.

The MCP endpoint itself is at https://<your-clarion-host>/api/mcp (the OAuth setup tab fills in the right URL for your environment).

---

​

Choosing a flow

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 or their owner is removed from the workspace.

---

​

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:
   claude mcp add --transport http clarion https://<your-clarion-host>/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:
   {
     "mcpServers": {
       "clarion": {
         "type": "http",
         "url": "https://<your-clarion-host>/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 at https://<your-clarion-host>/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:
   {
     "mcpServers": {
       "clarion": {
         "type": "http",
         "url": "https://<your-clarion-host>/api/mcp",
         "headers": { "Authorization": "Bearer <PASTE_TOKEN_HERE>" }
       }
     }
   }
   

​

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__<tool>). 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

Issues

• list_issues — paginated list, filterable by status / severity / search. status: ["escalated"] narrows to the confirmed problems.
• get_issue — full issue detail by display number, including its parent issue and related child issues
• complete_remediation_item — toggle a checklist item on an issue’s remediation list
• retrigger_issue — re-run triage agents for an issue (e.g. after deploying a fix)
• update_issue — edit an issue’s title, description, or verdict; marking one a duplicate stays in the Clarion UI (requires issues:write)
• set_issue_severity — change an issue’s severity (requires issues:write)
• set_issue_status — move an issue to a new status, including closing it with a verdict; sub-issues follow only when asked (requires issues:write)

Tasks

• list_tasks — paginated list, filter by status / priority / search / issue_number
• get_task — single task by id
• set_task_status — complete or reopen a task (requires tasks:write)

Monitors & integrations

• list_monitors, get_monitor — the workspace’s ingestion sources, with sanitized per-type config (webhook secrets stripped)
• create_monitor — add a monitor of a credential-free type: dns, rss_feed, or status_page (requires monitors:manage). The domain or URL is fetched server-side before the monitor is saved. Every other type mints a webhook secret or takes an API key, so it stays in the Clarion UI.
• update_monitor — rename or enable/disable any monitor type; edit config only for the credential-free types (dns, rss_feed, status_page), which re-validates the feed/status page (requires monitors:manage). A config edit for a secret-bearing type stays in the Clarion UI.
• delete_monitor — permanently delete a monitor and its signal rules, tearing down any webhook registrations it created; any type can be deleted (requires monitors:manage)
• 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 issues, before any alert filter fires
• summarize_signals — one source’s signal counts per monitor and event type over the last 1–90 days, each marked with that monitor’s signal rules whose steps match it. An event type with no covering rule is a detection gap.

Signal rules

• list_signal_rules, get_signal_rule — the detections that turn signals into issues, per monitor or workspace-wide (the matching sequence is returned by get_signal_rule)
• create_signal_rule — add a detection on a monitor: a match sequence plus the severity, kind, and title/description of the issue it fires (requires signal_rules:manage). The alert source is set server-side.
• update_signal_rule — partial-fields edit of a rule; editing a template-managed rule’s content forks it from the template, while toggling active state or moving monitor does not (requires signal_rules:manage)
• delete_signal_rule — permanently delete a signal rule (requires signal_rules:manage)

Bounties

• bounty_list_programs, bounty_get_program — list or inspect workspace Bounty programs by public slug; internal ids, creator data, and Agent configuration are omitted
• bounty_list_findings, bounty_get_finding — page and filter Bounty-specific finding projections by program slug and public reference; the detail response derives currently available actions from lifecycle policy
• bounty_get_agent_triage — read the latest redacted Bounty Agent run in bounded 200-entry transcript pages
• bounty_list_finding_comments, bounty_list_finding_comment_replies — page visible finding discussion and reply history
• bounty_start_manual_triage, bounty_submit_triager_assessment — BountyTriager-only takeover and assessment-handoff actions
• bounty_mark_finding_spam, bounty_mark_finding_duplicate, bounty_request_finding_information — controlled, version-checked, idempotent triage mutations
• bounty_decide_finding — accept or reject a finding in triager/client review, or return a client-review finding to the triager, using its current status and version; Admin-only through bounty_submissions:decide

BountyTriager uses the same workspace credential and endpoint as other workspace roles, but sees only the Bounties tools allowed by its current permissions. Clarion resolves the token owner’s current membership and role on every request; removing the owner from the workspace invalidates the credential on its next use. Agent runs

• get_agent_job — the execution record of a single non-Bounty agent run (status, error, model, token usage, timing, and what it ran for: a triage investigation, an assistant chat, or a scheduled run); use bounty_get_agent_triage for Bounty runs
• get_agent_job_transcript — the poll-friendly, step-by-step transcript of an agent run (assistant turns, tool calls, tool results), oldest first

Assistant chats

• list_chats — the workspace’s assistant chats
• get_chat_transcript — a chat’s messages and tool activity
• start_chat — open a new assistant chat with a first user message (optionally booting a specific agent persona); returns an agent-run id to poll
• send_chat_message — post a follow-up message into an existing chat

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

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 monitors. Create the credential-free monitor types with create_monitor first; the ones involving webhook secrets and registration stay in the Clarion UI.

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 <tool> pills, and edits snapshot a new version
• evaluate_skill — check a saved skill (skillId) or an unsaved draft against the authoring best practices; returns meetsRecommendations, plus recommendations when it does not

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_agent_behavior, set_agent_behavior — read or replace the workspace’s agent behavior (markdown), the standing instructions added on top of the read-only system prompt for every agent

​

Asset catalog & curated knowledge (Brain)

The Brain surface exposes the workspace’s discovered infrastructure and the operator-curated architecture knowledge layered on top of it. Assets & systems (read)

• list_assets, get_asset — the resources (compute, datastores, repos, services, DNS records, cloud accounts, …) discovered across connected integrations
• list_systems — the auto-correlated, cross-provider groupings of those assets

Annotations (write)

• annotate_asset — record durable, attributed notes/attributes on a resource
• record_inferred_asset — persist a triage-inferred narrative asset (attacker IP, involved user, vulnerable package, …) into the catalog

Curated knowledge (read)

• search_knowledge — text-search knowledge names, page bodies, and references
• list_knowledge_elements, get_knowledge_element — the hand-curated architecture nodes (systems, services, platforms, …) and their linked assets and references
• list_knowledge_references — curated external references filtered by semantic tag (access_control, runbook, architecture, …)

Curated knowledge (write)

• propose_knowledge_element, update_knowledge_element, remove_knowledge_element — create/enrich, edit, or delete a curated knowledge node
• link_knowledge_asset, unlink_knowledge_asset — connect or disconnect a catalog asset and a knowledge node
• add_knowledge_fact, update_knowledge_fact, delete_knowledge_fact — weave, supersede, or retract an atomic claim in a knowledge node’s recap