Better Stack MCP by usefulapi

Server Details

Read monitors, incidents, heartbeats, on-call and status pages; acknowledge or resolve incidents.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Uptime: 81.2% over 54 days
Last Tested: 2026-10-10 18:06
Transport: Streamable HTTP · MCP 2025-06-18
URL
Repository: m190/usefulapi-mcp
GitHub Stars: 0

TDQS

A4.1/5.0

Scored 2026-07-28 03:21 across 9 tools

Disambiguation5/5

Each tool targets a distinct resource or action: monitors, heartbeats, incidents, on-call schedules, and status pages are clearly separated. Incident actions (list, get, acknowledge, resolve) are unambiguous with no overlap.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern in snake_case (e.g., list_monitors, get_incident, acknowledge_incident). The naming is predictable and easy to follow.

Tool Count5/5

With 9 tools covering the primary aspects of uptime monitoring and incident management, the count is well within the ideal 3-15 range. Each tool serves a clear purpose without being excessive.

Completeness3/5

The tool set covers reading and incident lifecycle management well, but lacks any create/update/delete operations for monitors, heartbeats, or status pages. This is a notable gap for a comprehensive monitoring platform, though the core incident workflow is covered.

Available Tools

9 tools

acknowledge_incidentAcknowledge an incident

Idempotent

Inspect

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.

ParametersJSON Schema

Name	Required	Description	Default
`incident_id`	Yes	The incident id to acknowledge (from list_incidents).
`acknowledged_by`	Yes	User e-mail or a custom identifier of who is acknowledging the incident.

get_incidentGet an incident

Read-only

Inspect

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}.

ParametersJSON Schema

Name	Required	Description	Default
`incident_id`	Yes	The incident id (from list_incidents).

get_monitorGet a monitor

Read-only

Inspect

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}.

ParametersJSON Schema

Name	Required	Description	Default
`monitor_id`	Yes	The monitor id (from list_monitors).

list_heartbeatsList heartbeats

Read-only

Inspect

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.

ParametersJSON Schema

Name	Required	Description
`page`	No	Page number for pagination (default 1).
`per_page`	No	Results per page.
`team_name`	No	Filter by team name (only when using a global API token).

list_incidentsList incidents

Read-only

Inspect

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.

ParametersJSON Schema

Name	Required	Description
`to`	No	End date yyyy-mm-dd (inclusive).
`from`	No	Start date yyyy-mm-dd (inclusive).
`page`	No	Page number for pagination (default 1).
`per_page`	No	Results per page.
`resolved`	No	true = only resolved, false = only unresolved.
`team_name`	No	Filter by team name (only when using a global API token).
`monitor_id`	No	Only incidents for this monitor id.
`acknowledged`	No	true = only acknowledged, false = only unacknowledged.
`heartbeat_id`	No	Only incidents for this heartbeat id.

list_monitorsList monitors

Read-only

Inspect

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.

ParametersJSON Schema

Name	Required	Description
`url`	No	Filter monitors by their monitored URL.
`page`	No	Page number for pagination (default 1).
`per_page`	No	Results per page.
`team_name`	No	Filter by team name (only when using a global API token).
`pronounceable_name`	No	Filter monitors by their pronounceable name.

list_on_callList on-call schedules

Read-only

Inspect

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.

ParametersJSON Schema

Name	Required	Description
`page`	No	Page number for pagination (default 1).
`per_page`	No	Results per page.
`team_name`	No	Filter by team name (only when using a global API token).

list_status_pagesList status pages

Read-only

Inspect

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

ParametersJSON Schema

Name	Required	Description
`page`	No	Page number for pagination (default 1).
`per_page`	No	Results per page.
`team_name`	No	Filter by team name (only when using a global API token).

resolve_incidentResolve an incident

Idempotent

Inspect

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.

ParametersJSON Schema

Name	Required	Description	Default
`incident_id`	Yes	The incident id to resolve (from list_incidents).
`resolved_by`	Yes	User e-mail or a custom identifier of who is resolving the incident.