Ask questions about your infra from a Claude chat. How the MCP server works, which 12 tools are available, and why we deliberately don't allow autonomous Emergency Actions.

When you set up the monsys Claude Connector, you can ask questions from a Claude chat like "which servers have an open critical CVE?" or "what is my tenant's Trust Score?". Claude then calls MCP tools on the monsys hub and gives you a summary.

This article describes how that connector works technically, which OAuth flow it uses, which tools are available, and — perhaps more importantly — what the connector deliberately doesn't do.

MCP: Model Context Protocol in one paragraph

MCP is an open protocol (Anthropic, late 2024) that defines how an AI model can call tools on external servers. An MCP server publishes a list of available tools via a JSON-RPC interface. The client (Claude) calls tools by sending a tools/call request with the tool name and arguments.

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "monsys_list_alerts",
    "arguments": {
      "severity": "critical",
      "limit": 10
    }
  }
}

The MCP server (the monsys hub at api.monsys.ai) processes the call, fetches data from the database, and returns a structured response. Claude interprets that response and formulates an answer.

OAuth 2.1 with PKCE: the auth flow

The connector uses OAuth 2.1 with PKCE (Proof Key for Code Exchange). That's the current best practice for public clients (such as browser-based apps) that can't securely store a client secret.

Discovery

Claude detects the OAuth configuration via:

GET https://api.monsys.ai/.well-known/oauth-authorization-server

Response:
{
  "issuer": "https://api.monsys.ai",
  "authorization_endpoint": "https://app.monsys.ai/mcp/oauth/authorize",
  "token_endpoint": "https://api.monsys.ai/mcp/oauth/token",
  "registration_endpoint": "https://api.monsys.ai/mcp/oauth/register",
  "scopes_supported": ["mcp.read", "mcp.acknowledge"],
  "response_types_supported": ["code"],
  "code_challenge_methods_supported": ["S256"]
}

Registration

A client (your own script, or Claude) registers itself:

curl -X POST https://api.monsys.ai/mcp/oauth/register \
  -H "Content-Type: application/json" \
  -d '{
    "client_name": "claude-desktop",
    "redirect_uris": ["https://claude.ai/oauth/callback"]
  }'

# Response:
# { "client_id": "mcp_a1b2c3...", "client_secret": null }

No client_secret — this is a public client.

Authorization flow

1. Client generates PKCE:
   verifier  = random_bytes(32).hex()
   challenge = base64url(sha256(verifier))

2. Redirect to authorization endpoint:
   https://app.monsys.ai/mcp/oauth/authorize
     ?client_id=mcp_a1b2c3
     &redirect_uri=https://claude.ai/oauth/callback
     &response_type=code
     &scope=mcp.read
     &code_challenge=<challenge>
     &code_challenge_method=S256

3. User logs in to monsys and approves scopes

4. Redirect back with authorization code:
   https://claude.ai/oauth/callback?code=<code>

5. Token exchange:
   POST /mcp/oauth/token
     grant_type=authorization_code
     &code=<code>
     &redirect_uri=...
     &client_id=mcp_a1b2c3
     &code_verifier=<verifier>

6. Response:
   {
     "access_token": "mat_...",
     "token_type": "Bearer",
     "expires_in": 3600,
     "scope": "mcp.read"
   }

Token TTL is 1 hour. After that, re-authentication is required.

The 12 available tools

Every tool but one is read-only. The mcp.read scope grants access to the read tools; mcp.acknowledge is required for the single write tool.

Tool	What	Typical Claude question
`monsys_kpi_summary`	Fleet snapshot: Trust Score, open alerts, open detections, SLA status	"Give me a morning briefing of my infra"
`monsys_list_agents`	Active hosts with tag filter	"Which production servers are online?"
`monsys_get_agent`	Per-host detail: CPU/mem/disk + open alerts	"How is web-edge-01 doing?"
`monsys_trust_score`	Trust Score + 8 components + 7d delta	"Has my Trust Score improved this week?"
`monsys_list_alerts`	Open alerts filtered by severity/category/agent	"Which critical alerts are open?"
`monsys_list_detections`	Detection events (24h/7d/30d)	"Were there any security events yesterday?"
`monsys_get_detection`	Drill-down: full context + related events + suggestions	"Explain this detection event to me"
`monsys_acknowledge_detection`	Close a detection after investigation	"Ack detection event DEV-2026-0441"
`monsys_list_kernel_cves`	Open kernel CVEs with affected_hosts count	"Which kernel CVEs are still open?"
`monsys_list_os_cves`	OS package CVEs from OSV.dev	"Which npm CVEs does my fleet have?"
`monsys_list_sla_overview`	SLA targets with observed% and error budget	"How close am I to my SLA threshold?"
`monsys_audit_log_search`	Grep the audit_log by event_type/actor/time	"Who ran Emergency Actions in the last week?"

Every tool call is logged

This is not a side note — it's an architectural guarantee. Every tool invocation via the Claude Connector is stored in mcp_call_log:

CREATE TABLE mcp_call_log (
    id          UUID DEFAULT gen_random_uuid() PRIMARY KEY,
    tenant_id   UUID NOT NULL,
    user_id     UUID NOT NULL,
    tool_name   TEXT NOT NULL,
    args_hash   TEXT NOT NULL,
    result_status TEXT NOT NULL,
    duration_ms INT NOT NULL,
    called_at   TIMESTAMPTZ DEFAULT NOW()
);

Raw arguments are not stored (PII risk), only their SHA256 hash. The log is queryable via the audit tool itself:

monsys_audit_log_search(event_type='mcp_tool_invoked', since='7d')

For compliance contexts this matters: if Claude fetched data on behalf of an operator, it's in the audit trail.

Why the connector is read-mostly

The most common question from security teams: "Can Claude run Emergency Actions automatically?"

No. Deliberately not.

Destructive actions — IsolateNetwork, KillProcess, kernel updates, user lockout — require:

TOTP verification by the operator
A reason of at least 20 characters
An Emergency Action Token (EAT) signed by the hub with Ed25519

That process cannot be automated via the Claude Connector. The only write tool is monsys_acknowledge_detection — closing a detection event after investigation, which is fully reversible and logged.

The reason is principled, not technical: an AI agent that can autonomously isolate production servers from the network is a different risk model than an AI agent that helps you gather information and prepare decisions. We choose the second.

This aligns with the human-in-the-loop principle that Anthropic's own CLUE system also uses: Claude suggests, the operator decides.

Sovereignty: what goes through Claude's API?

This deserves an explicit section. When you use the connector, tool responses pass through Anthropic's API to be processed by the model. That means:

What DOES go through Claude's API:

Hostnames and IP addresses
Alert titles and descriptions
Detection event metadata (src_ip, target_user)
Trust Score numbers
CVE identifiers

What does NOT go through Claude's API:

No agent-side raw data (the connector reads the hub DB, not host resources)
No secrets or credentials
No raw audit-log bodies (only event_type + metadata)
No AI observability trace content (prompts/completions)

For most NIS2 contexts, this is acceptable. For government bodies or sectors with strict data-residency requirements (defence, parts of healthcare) the connector is per-tenant opt-in and can stay disabled.

The connector is a tool for operators who want to query their infrastructure in natural language. It is not meant as an autonomous security agent.

A practical example: morning briefing as a Claude routine

Save this as a Claude routine (daily 08:00):

Open the monsys connector. Call monsys_kpi_summary.
Give a Slack-style update:
- Trust Score: X/100 (delta vs yesterday: +/-)
- Open critical alerts: N
- Open detections (24h): N
If there are critical detections, also call monsys_list_detections(since=24h, ack=open)
and give one line per event: [agent] [rule_kind] [first seen]

Claude assembles the data with two tool calls, correlates where needed, and gives you a readable summary — without you having to open the dashboard.

The Claude Connector is documented at docs.monsys.ai/en/hub/claude-connector. First five servers free, OAuth flow works immediately after registration: monsys.ai/en/signup.

The monsys Claude Connector: MCP, OAuth 2.1 and why the agent never acts autonomously