CLI — cw-* Read Commands

The CritterWatch.CommandLine package adds a server-less command-line surface to an embedded CritterWatch console: four read commands that emit the same JSON the MCP read tools produce, without ASP.NET Core, the MCP HTTP transport, or even starting the application. They exist for AI agents and scripts that want a point-in-time snapshot of a system's health from the shell.

Paid tier

Like the whole MCP/AI surface, the cw-* commands are license-gated. Without a valid CritterWatch license the commands exit non-zero with an explanatory message.

Setup

Reference the package in the application that mounts the embedded console:

dotnet add package CritterWatch.CommandLine

The commands are discovered by JasperFx's command runner — the same RunJasperFxCommands entry point a Wolverine application already uses:

// With the CritterWatch.CommandLine package referenced, the cw-* read commands are
// discovered automatically by JasperFx's command runner. `dotnet run` with no arguments
// starts the host normally; `dotnet run -- cw-health` (etc.) runs the command against a
// BUILT-but-not-started host and exits — a point-in-time read of the last persisted state.
return await app.RunJasperFxCommands(args);

Nothing is started when a cw-* command runs: the host is built, not run, so the command reads the console's last persisted state and exits. (That also means reset-on-boot behavior for embedded consoles never fires from a CLI invocation.)

Commands

Every command supports --format json (the default — agent-first, stable shapes shared with the MCP tools) and --format text (human-readable).

cw-health

Invocation	Returns
dotnet run -- cw-health --view summary	Fleet-level health rollup
dotnet run -- cw-health --view service --service <name>	One service's health detail
dotnet run -- cw-health --view degraded	Only the services with problems

cw-performance

Invocation	Returns
dotnet run -- cw-performance --view backlog	Queue/backlog pressure across endpoints
dotnet run -- cw-performance --view hotspots	The slowest / busiest message types
dotnet run -- cw-performance --view lag	Projection lag against the high-water marks

cw-alerts

Invocation	Returns
dotnet run -- cw-alerts --view list	Active alerts
dotnet run -- cw-alerts --view summary	Alert counts by severity/type
dotnet run -- cw-alerts --view get --id <alert-stream-id>	One alert's full detail

cw-routing

Invocation	Returns
dotnet run -- cw-routing --service <name>	The service's message-routing topology
dotnet run -- cw-routing --service <name> --message <type>	How one message type routes

A lookup that finds nothing (an unknown service or alert id) returns a structured { "found": false, ... } payload rather than an error, so scripts can branch without parsing stderr.

Relationship to MCP

The commands reuse the exact reporters behind the CritterWatch.Mcp read tools, so the JSON is identical to what an MCP client sees. Pick by transport: MCP for a connected AI session over HTTP, cw-* for shells, cron, and agents that exec commands. See MCP — Model Context Protocol.

Smoke coverage

Every command × view × format combination is exercised by the repo's SmokeTestCli build target against the runnable EmbeddedDemo.Marten / EmbeddedDemo.Polecat samples, with an anti-drift check that fails the build if a new cw-* command ships without matrix coverage.