Claude Connector (MCP)

monsys.ai publishes a Model Context Protocol (MCP) server so you can add it as a Custom Connector in Claude. From a chat or routine Claude can call tools like “list open alerts”, “give Trust Score”, “drill into this detection”.

Per feedback_human_in_the_loop the tools are read-mostly. Claude can see + summarise + suggest, never execute. Destructive actions (IsolateNetwork, kernel update, user lock) stay TOTP-gated in the dashboard. The only write tool: monsys_acknowledge_detection — closes a detection event after investigation (fully reversible, audit-logged).

In the dashboard (Claude side)

Open Claude desktop or claude.ai
Settings → Connectors → Add custom connector
URL: https://api.monsys.ai
Claude discovers OAuth via /.well-known/oauth-authorization-server
Click Connect → you’re sent to app.monsys.ai/login
Sign in with your monsys account → approve scope mcp.read mcp.acknowledge
Back in Claude: connector status “Connected”

Token TTL: 1 hour. After that Claude shows a re-auth button. Refresh tokens land in v2.

Available tools

Tool	What	Scope
`monsys_list_agents`	active hosts with tag filter	read
`monsys_get_agent`	per-host detail (CPU/mem/disk + open alerts)	read
`monsys_trust_score`	current tenant score + 6 components + 7d delta	read
`monsys_list_alerts`	open alerts filtered by severity/category/agent	read
`monsys_list_detections`	detected_events last 24h/7d/30d with filter	read
`monsys_get_detection`	drill-down: full context + related auth-events + similar findings + suggested next steps	read
`monsys_acknowledge_detection`	close a detection after investigation (reversible)	acknowledge
`monsys_list_kernel_cves`	open kernel CVEs with affected_hosts count	read
`monsys_list_os_cves`	open OS-package CVEs from OSV.dev (apt/dnf/apk/zypper)	read
`monsys_list_sla_overview`	every SLA target with observed%/error budget	read
`monsys_audit_log_search`	grep audit_log by event_type/actor/time	read
`monsys_kpi_summary`	one-shot fleet snapshot for morning briefings	read

Every tool call is logged to mcp_call_log with tool_name + tenant + user + duration + result_status. Visible in the dashboard audit log via monsys_audit_log_search(event_type='mcp_tool_invoked').

Example — Claude routines

Daily morning briefing (08:00 Mon-Fri)

Save this as a Claude routine:

“Open the monsys connector. Call monsys_kpi_summary. Format as a short Slack-style update: Trust Score X/100, Y open critical alerts, Z open detections last 24h. If there are detections, also call monsys_list_detections(since=24h, ack=open) and give a 1-line summary per event.”

Unknown src-IP investigation

“In monsys I see an alert from IP 185.220.101.42. Call monsys_audit_log_search(actor_email_contains='@yourMSP.com') for the last 24h AND monsys_list_detections(since=7d) filtered on this IP. Summarise what this IP tried and suggest whether this is suspicious.”

MSP cross-tenant morning check

One connector per tenant. In your MSP workspace use a separate Claude conversation per client with the right connector enabled:

“In monsys-acme: monsys_kpi_summary. In monsys-eu-bank: monsys_kpi_summary. Compare the two and flag the tenant with the biggest delta since yesterday.”

Sovereignty + privacy

Important to state explicitly to prospects: Claude is Anthropic (US company). When you call a tool the data flows through Claude’s API to be fed to the model. For some tenants (government, certain NIS2 sectors) that’s a dealbreaker. The connector is therefore per-tenant opt-in.

What does NOT go through Claude:

No agent-side data (the connector reads the hub DB, not host resources)
No secrets, no credentials (tools return tenant data scoped to user’s RBAC)
No raw audit-log bodies (only event_type + metadata)

What DOES go through Claude:

Hostnames, IP addresses, country codes
Alert titles + descriptions
Detection event src_ip + target_user
Trust Score numbers

For the NIS2 audit buyer this is acceptable; for an intelligence- agency architect it’s not. Make the decision explicit per client.

Session management

Revoke tokens: dashboard → /settings/mcp-tokens (v2; for now via SQL: UPDATE mcp_access_tokens SET revoked_at=NOW() WHERE user_id='<uuid>')
Audit per connector: monsys_audit_log_search(event_type='mcp_authorization_granted')
Per-call audit: table mcp_call_log shows every tool call with argument hash (raw args not stored due to PII concerns)

Or via API (advanced — for automation)

Direct MCP roundtrip with your own client (no Claude UI):

# 1. Register a client
curl -X POST https://api.monsys.ai/mcp/oauth/register \
  -H "Content-Type: application/json" \
  -d '{"client_name":"my-script","redirect_uris":["http://localhost:8080/cb"]}'

# 2. Browser flow: open
# https://api.monsys.ai/mcp/oauth/authorize?client_id=mcp_xxx&redirect_uri=http://localhost:8080/cb&response_type=code&code_challenge=<sha256-of-verifier>&code_challenge_method=S256&scope=mcp.read
# log in if needed → redirect with ?code=xxx

# 3. Exchange code for token
curl -X POST https://api.monsys.ai/mcp/oauth/token \
  -d "grant_type=authorization_code&code=xxx&redirect_uri=http://localhost:8080/cb&client_id=mcp_xxx&code_verifier=<original>"

# 4. Call a tool
curl -X POST https://api.monsys.ai/mcp \
  -H "Authorization: Bearer mat_xxx" \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"monsys_kpi_summary","arguments":{}}}'

What does NOT belong on this page

Manual Emergency Actions (IsolateNetwork etc.) → see Emergency console
OpenAI Admin Audit module (other direction: monsys reads OpenAI/Copilot) → see OpenAI Audit
Anthropic case study → see blog