# io.usefulapi/betterstack (remote · betterstack.usefulapi.io)

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

- Trust score: 74/100 (medium)
- Change this week: +4
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-08-03

## Components

- remote · `betterstack.usefulapi.io`: 74/100 (this document), [markdown](https://verifymcp.io/servers/io-usefulapi-betterstack/betterstack.md), [page](https://verifymcp.io/servers/io-usefulapi-betterstack/betterstack)

## Channel facts

- Endpoint: `https://betterstack.usefulapi.io/mcp`
- Transports: `streamable-http`
- Auth: `none`
- Version: `1.0.1`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-08-03.

- **Endpoint Security**: 78/100
  - The endpoint's TLS certificate is valid, in date, and uses a strong key.
  - Authorisation is enforced on tool calls, advertised via RFC 9728 protected-resource metadata. Discovery is public, which costs nothing: no tool can be invoked without a token.
  - HTTPS not yet verified: we couldn't determine whether a plaintext access path exists.
  - HSTS check failed: the Strict-Transport-Security header is absent.
  - DNSSEC check failed: this domain isn't protected by DNSSEC.
  - The authorisation server offers only Dynamic Client Registration (RFC 7591), which MCP 2026-07-28 deprecated in favour of Client ID Metadata Documents.
- **Transport & Reachability**: 100/100
  - Verified streamable-http transport via a live MCP handshake.
- **Schema Quality & AI Usability**: 80/100
  - AI-judged instruction clarity (excellent).
  - Tool/resource definitions use about 940 tokens (~104/item across 9 items; 9 tools + 0 resources), lean.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 23/100
  - Stability observed for 7 of 30 days with no destabilising changes; credit accrues until the full window elapses.
- **Tool Coverage**: 100/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 100% of tool parameters carry a description.
- **Capabilities**: 60/100
  - Spec-recency check failed: implements MCP spec 2025-06-18; the latest is 2026-07-28.

## Install

### Claude

```bash
claude mcp add --transport http io-usefulapi-betterstack https://betterstack.usefulapi.io/mcp
```

### Codex

```toml
[mcp_servers.io-usefulapi-betterstack]
url = "https://betterstack.usefulapi.io/mcp"
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "io-usefulapi-betterstack": {
      "type": "remote",
      "url": "https://betterstack.usefulapi.io/mcp",
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add io-usefulapi-betterstack --url https://betterstack.usefulapi.io/mcp --transport streamable-http
```

### Hermes

```yaml
mcp_servers:
  io-usefulapi-betterstack:
    url: "https://betterstack.usefulapi.io/mcp"
```

### Other

```json
{
  "mcpServers": {
    "io-usefulapi-betterstack": {
      "type": "http",
      "url": "https://betterstack.usefulapi.io/mcp"
    }
  }
}
```

The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs.

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-08-03 (score 74, +1)

No change was recorded against any check on this day. Stability & Change Management went from 20 to 23. That category is still filling its 30-day observation window: 6 days of observed history at the previous scan, 7 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-08-01 (score 73, +1)

No change was recorded against any check on this day. Stability & Change Management went from 13 to 17. That category is still filling its 30-day observation window: 4 days of observed history at the previous scan, 5 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-07-31 (score 72, +2)

- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

### 2026-07-30 (score 70, −1)

- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

### 2026-07-28 (score 71, +1)

- [functional improvement] Stability: unverified → 0.03

### 2026-07-27 (score 70, +58)

- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

### 2026-07-26 (score 12)

First indexed and scored.

## MCP tools (9)

### `list_monitors` (~133 tokens)

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.

Input parameters:

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

### `get_monitor` (~66 tokens)

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

Input parameters:

- `monitor_id` (string, required): The monitor id (from list_monitors).

### `list_incidents` (~197 tokens)

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.

Input parameters:

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

### `get_incident` (~73 tokens)

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

Input parameters:

- `incident_id` (string, required): The incident id (from list_incidents).

### `list_heartbeats` (~98 tokens)

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.

Input parameters:

- `page` (integer): Page number for pagination (default 1).
- `per_page` (integer): Results per page.
- `team_name` (string): Filter by team name (only when using a global API token).

### `list_on_call` (~91 tokens)

List on-call schedules

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.

Input parameters:

- `page` (integer): Page number for pagination (default 1).
- `per_page` (integer): Results per page.
- `team_name` (string): Filter by team name (only when using a global API token).

### `list_status_pages` (~86 tokens)

List status pages

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

Input parameters:

- `page` (integer): Page number for pagination (default 1).
- `per_page` (integer): Results per page.
- `team_name` (string): Filter by team name (only when using a global API token).

### `acknowledge_incident` (~104 tokens)

Acknowledge an 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.

Input parameters:

- `acknowledged_by` (string, required): User e-mail or a custom identifier of who is acknowledging the incident.
- `incident_id` (string, required): The incident id to acknowledge (from list_incidents).

### `resolve_incident` (~92 tokens)

Resolve an 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.

Input parameters:

- `incident_id` (string, required): The incident id to resolve (from list_incidents).
- `resolved_by` (string, required): User e-mail or a custom identifier of who is resolving the incident.

## Diagnostics

Captured diagnostic sections: TLS, DNSSEC, Authorisation, Transports. The full working is on the page: https://verifymcp.io/servers/io-usefulapi-betterstack/betterstack#diagnostics

## Score history

- 2026-08-03: 74
- 2026-08-02: 73
- 2026-08-01: 73
- 2026-07-31: 72
- 2026-07-30: 70
- 2026-07-29: 71
- 2026-07-28: 71
- 2026-07-27: 70
- 2026-07-26: 12

## Links

- Remote endpoint: https://betterstack.usefulapi.io/mcp
- Repository: https://github.com/m190/usefulapi-mcp
- Changelog RSS feed: https://verifymcp.io/servers/io-usefulapi-betterstack/betterstack/changelog.xml
- Changelog JSON feed: https://verifymcp.io/servers/io-usefulapi-betterstack/betterstack/changelog.json
- HTML version of this page: https://verifymcp.io/servers/io-usefulapi-betterstack/betterstack