Xanthe Incident Agent
Allows defining incident runbooks as XState state machines, providing enforceable step-by-step procedures with constraints.
Click on "Install 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: dobbe
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 installed
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Latest Blog Posts
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/msradam/xanthe-incident-agent'
If you have feedback or need assistance with the MCP directory API, please join our Discord server