Use Muster from your agent

Updated

Muster includes a small MCP server for asking about monitor health. It is read-only: an agent can find monitors that are late, missed or failed and read their recent history, but it cannot create, edit, enable or disable a monitor, or send a check-in.

Reaching it

The MCP server is mounted at /mcp on your Muster environment and is set up for delegated access, so you reach it through Scalpels rather than by connecting to it directly. Install the Scalpels MCP server in your agent with a token that has the Call installed apps ability, and your agent can list the MCP-enabled products your team runs, see Muster's tools, and call them on a specific deployment. Scalpels relays each call with your identity and your role on the team. See Use Scalpels from your agent for setup and Console for how delegated access works.

Tools

Both tools reject arguments they do not recognise, and both page their results with an opaque cursor. Each page carries a next_cursor, which is null on the last page; pass it back as cursor to fetch the next one.

`unhealthy_monitors`

Lists enabled monitors whose status is late, missed or failed, in id order. Disabled monitors are never included.

Argument	Required	Meaning
`statuses`	No	Only these statuses, any of `late`, `missed` and `failed`. Defaults to all three.
`limit`	No	How many monitors to return, from 1 to 100. Defaults to 25.
`cursor`	No	The `next_cursor` from a previous call.

Each monitor carries its id, name, status, command, display, cron expression, timezone, cadence_seconds, grace_seconds, last_check_in_at, next_due_at, last_exit_code, last_runtime and whether it runs in the background. The schedule fields are empty for a monitor you created by hand.

`monitor_history`

Reads one monitor's recorded events, newest first, with the outcome of any alerts each event raised.

Argument	Required	Meaning
`monitor_id`	Yes	The monitor's id.
`event_types`	No	Only these event types: any of `check_in`, `late`, `missed`, `recovered`, `started`, `finished`, `skipped` and `non_zero_exit`. Defaults to all.
`limit`	No	How many events to return, from 1 to 100. Defaults to 25.
`cursor`	No	The `next_cursor` from a previous call.

The answer names the monitor and lists its events. Each event carries its type, when it occurred, the command details, execution id, exit code and runtime where reported, and the monitor's last check-in and next due time at that moment. Each event's alert_deliveries lists the channel (email or webhook), delivery status, attempt count, last error code and timestamps.

Alert destinations are never included: the history shows that an email or webhook was attempted and how it ended, not where it went. An unknown monitor id returns Monitor not found.

The history is the same bounded history the web UI shows: roughly the last hundred events per monitor, plus recent failures.

What to ask

Is anything in Muster missed right now?

Why did the nightly backup monitor go red last night, and did the webhook alert get through?

Which monitors have failed with a non-zero exit, and what were the exit codes?