Xanthe Incident Agent
Allows defining incident runbooks as XState state machines, providing enforceable step-by-step procedures with constraints.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@Xanthe Incident AgentBegin incident response for the login timeout spike"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Xanthe Incident Agent
An incident-response agent that drives a runbook on rails. The procedure is a plain XState machine mounted as an MCP server by Xanthe, and the agent can only take the moves the machine allows. The division of labor:
the machine owns the procedure (you cannot mitigate before diagnosing, resolve before recovery is verified, or close before a postmortem is written),
the agent supplies judgment (the hypothesis, the root cause, the mitigation),
the ledger is the audit trail (every step and every refused step, hash-chained).

A premature resolve is refused by the server, not trusted to the model's judgment, and the
refusal is recorded. By the time the incident is closed, the machine's context is a complete
postmortem, assembled as a side effect of being forced through the right order.
Run it
npm installOffline (deterministic policy, no API key)
npm startA scripted policy walks the same gated runbook to resolution and verifies the ledger.
With Claude
npm run agent # or: MODEL=claude-opus-4-8 npm run agentUses the Claude Agent SDK, which
authenticates with your existing Claude Code login (no API key). The Xanthe server is
registered as an MCP server, so Claude only ever acts through the gated step / state
tools: it reads state, narrates each move, recovers from refusals, and writes the postmortem.
It is held to the runbook the whole way.
Related MCP server: PilotOps MCP
What you see
gate check: resolve before mitigating -> refused (legal here: triage)
driving the runbook:
detected triage -> triaged
triaged page_oncall -> engaged
engaged form_hypothesis -> investigating
...
resolved write_postmortem -> closed
final state: "closed" (terminal: true)
postmortem assembled by being forced through the runbook: { ...severity, rootCause, ... }
ledger: intact (10 entries, including the refused gate check)The runbook
machine/incident-runbook.ts is plain XState. Edit it, or point the agent at your own
runbook. Xanthe validates it at mount and rejects machines that auto-advance, so it stays a
step-gated procedure the agent drives one decision at a time.
License
Apache-2.0.
This server cannot be deployed
Maintenance
Related MCP Connectors
Deterministic runtime enforcement of step order for AI agents: ALLOW/DENY before a step runs.
Human-in-the-loop for AI agents over MCP: durable approvals with a hosted review page & audit trail
EU AI Act Art-14 runtime oversight: allow / flag / gate-to-human on an agent action, with receipt.
AI agent run monitoring with incident replay and SLA receipts.
Related MCP Servers
- AlicenseNot gradedqualityCmaintenanceAutomates DevOps workflows like vulnerability resolution, code review, test generation, and DORA metrics through Claude Code slash commands, using a state machine for reliable execution.15 npmMIT
- FlicenseNot gradedqualityDmaintenanceEnables AI-driven incident response by connecting Claude to monitoring tools like Prometheus, Grafana, Loki, PagerDuty, and Slack for automated investigation and runbook generation.9-
- AlicenseNot gradedqualityBmaintenanceEnables autonomous SRE incident investigation by allowing users to describe incidents in natural language. The agent follows a governed state machine to gather read-only evidence and produce grounded conclusions.MIT
- AlicenseNot gradedqualityAmaintenanceEnables evidence-gated, multi-session AI coding runs with plan-build-ship state management, coordinating Claude Code and Codex native agents.36 npmMIT