Guard an agent in one minute

1 · Install

Node ≥ 18. The CLI is published to npm and has no runtime dependencies:

npm install -g chronomcp

2 · Guard your first server

ChronoMCP wraps a server by running it as a subcommand after --. The repo ships a demo server that implements the compensation extension, so you can watch a real saga unwind:

# clone the repo for the demo server, then guard it:
git clone https://github.com/chronomcp/chronomcp && cd chronomcp
chronomcp guard --mode gate --saga -- node examples/server-demo/server.mjs

Now point your MCP client (Claude Desktop, an IDE, your own agent) at ChronoMCP instead of the server directly. When the agent calls a mutating tool, you get a human-readable impact diff on your terminal and a y/N prompt before it runs. Drive the demo through your client — create_record is approved, then a charge_payment over 100 fails, and ChronoMCP rolls back the created record before the agent ever sees the error, reporting honestly what could not be reversed.

3 · The three modes

One flag decides how much friction you want. Pick per environment:

• logAudit only. Nothing is blocked. Every call, decision and outcome is classified and written to the audit log. Start here to see what your agent actually does.
• gateAsk a human. Mutating and destructive calls pause for approval (terminal y/N, a policy, or a remote control plane). Read-only calls pass through.
• blockDeny destructive. Destructive actions are refused outright — no human needed. Useful for locked-down or unattended environments.

4 · Works with any MCP server

Local over stdio, or remote over Streamable HTTP — same guard:

# any local stdio server, e.g. the official filesystem server:
chronomcp guard --mode gate --saga -- npx -y @modelcontextprotocol/server-filesystem /tmp

# a remote Streamable HTTP server, with headers:
chronomcp guard --mode gate --http https://mcp.example.com/mcp --header "Authorization: Bearer TOKEN"

5 · Saga rollback with mcp-compensate

When a multi-step task fails at step N, steps 1..N-1 are already committed. With --saga, ChronoMCP unwinds them in LIFO order — but only where the server has declared how. Reversibility is declared per tool in tools/list under _meta["dev.chronomcp/compensate"]:

{
  "reversibility": "compensable",        // "readonly" | "compensable" | "irreversible"
  "compensation": {
    "toolName": "delete_record",
    "parameterMapping": { "id": "$.output.structuredContent.id" }  // static JSONPath only
  },
  "sideEffectScope": ["storage"],
  "notes": "Removes the created record."
}

Two rules the design defends: no LLM in the rollback path — mappings are static, because recovery is exactly where a prompt-injected agent would try to improvise — and declared honesty: a tool with no metadata is treated as unknown reversibility, never assumed safe, and irreversible steps are flagged in the diff before you approve. Full grammar in the spec.

6 · Verify the audit

Every call, decision and outcome lands in an append-only JSONL file with a SHA-256 hash chain. Each entry hashes the previous one, so tampering is detectable by anyone — edit a line and the chain visibly breaks. You don't have to trust the log; you can verify it.

Next steps