Better Stack MCP by usefulapi

Reviewed 1d ago.

• tools: 9 tools scanned
• metadata: scanned

No findings.

Tools (9)

• list_monitors

  List uptime monitors with their status (up/down/paused/pending/maintenance/validating), check frequency, and alert settings. Good first call to discover what is being monitored. Uptime API: GET /api/v2/monitors.

• get_monitor

  Get a single monitor by id, including current status, last_checked_at, SSL/HTTP settings, regions, and alerting configuration. Uptime API: GET /api/v2/monitors/{id}.

• list_incidents

  List incidents (alerts triggered by monitors/heartbeats), filterable by date range, monitor, and acknowledged/resolved state. Each incident carries cause, started_at, acknowledged_at, resolved_at. Uptime API: GET /api/v3/incidents.

• get_incident

  Get a single incident by id, including cause, status, timeline timestamps (started/acknowledged/resolved), who acknowledged/resolved it, and the related monitor. Uptime API: GET /api/v3/incidents/{id}.

• list_heartbeats

  List heartbeats (cron/background-job monitors that expect a periodic ping), with period, grace, and status (up/down/paused/pending). Uptime API: GET /api/v2/heartbeats.

• list_on_call

  List on-call calendars/schedules and the users currently on call for escalation. Useful to see who gets paged. Uptime API: GET /api/v2/on-calls.

• list_status_pages

  List public/private status pages with company name, subdomain, aggregate_state, and published flag. Uptime API: GET /api/v2/status-pages.

• acknowledge_incident

  Acknowledge an ongoing incident, signalling that someone is looking into it (stops further escalation). Idempotent-ish: acknowledging an already-acknowledged incident returns HTTP 409. Uptime API: POST /api/v3/incidents/{id}/acknowledge.

• resolve_incident

  Resolve an ongoing incident, marking it as handled/closed. Idempotent-ish: resolving an already-resolved incident returns HTTP 409. Uptime API: POST /api/v3/incidents/{id}/resolve.