Skip to content

Better Stack MCP by usefulapi

by usefulapi.io · remote · no sign-in to list tools · v1.16.3 · published by io.usefulapi

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

Changes · 2
CompareRegistry entry

9 tools: 2 change things and 7 only read.

Scanned Oct 21, 2026

1 check matched something in the tool definitions. No finding is not a safety guarantee. How the checks work.

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

Findings

Matches of fixed checks, with the text they matched.

1 warn
  • Warnresolve_incident

    The server marks "resolve_incident" as not read-only (readOnlyHint: false), and its words say it reads.

    Matched text

    annotations: {"readOnlyHint":false,"idempotentHint":true}; The name "resolve_incident" says "resolve": a word for reading.

    What this check looks for

Tools

Open a tool for its reasons and full description. Descriptions are the publisher's own words, shown as they are.

9 tools

Changes things 2Claude Code: ask
  • acknowledge_incidentAcknowledge an ongoing incident, signalling that someone is looking into it (stops further escalation).No findings

    Why it is in this group

    • Nothing in its name or description says what it does, so it is counted as a write.
    Description, as the server wrote it
    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.

    Annotations the server declares

    • title: Acknowledge an incident
    • readOnlyHint: false
    • idempotentHint: true
  • resolve_incidentResolve an ongoing incident, marking it as handled/closed.1 finding

    Why it is in this group

    • The name "resolve_incident" says "resolve": a word for reading.
    • The server marks it as not read-only (readOnlyHint: false).

    Findings

    • Warn

      The server marks "resolve_incident" as not read-only (readOnlyHint: false), and its words say it reads.

      Matched text

      annotations: {"readOnlyHint":false,"idempotentHint":true}; The name "resolve_incident" says "resolve": a word for reading.

      What this check looks for
    Description, as the server wrote it
    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.

    Annotations the server declares

    • title: Resolve an incident
    • readOnlyHint: false
    • idempotentHint: true
Only reads 7Claude Code: allow
  • get_incidentGet a single incident by id, including cause, status, timeline timestamps (started/acknowledged/resolved), who acknowledged/resolved it, and the related monitor.No findings

    Why it is in this group

    • The name "get_incident" says "get": a word for reading.
    Description, as the server wrote it
    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}.

    Annotations the server declares

    • title: Get an incident
    • readOnlyHint: true
  • get_monitorGet a single monitor by id, including current status, last_checked_at, SSL/HTTP settings, regions, and alerting configuration.No findings

    Why it is in this group

    • The name "get_monitor" says "get": a word for reading.
    Description, as the server wrote it
    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}.

    Annotations the server declares

    • title: Get a monitor
    • readOnlyHint: true
  • list_heartbeatsList heartbeats (cron/background-job monitors that expect a periodic ping), with period, grace, and status (up/down/paused/pending).No findings

    Why it is in this group

    • The name "list_heartbeats" says "list": a word for reading.
    Description, as the server wrote it
    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.

    Annotations the server declares

    • title: List heartbeats
    • readOnlyHint: true
  • list_incidentsList incidents (alerts triggered by monitors/heartbeats), filterable by date range, monitor, and acknowledged/resolved state.No findings

    Why it is in this group

    • The name "list_incidents" says "list": a word for reading.
    Description, as the server wrote it
    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.

    Annotations the server declares

    • title: List incidents
    • readOnlyHint: true
  • list_monitorsList uptime monitors with their status (up/down/paused/pending/maintenance/validating), check frequency, and alert settings.No findings

    Why it is in this group

    • The name "list_monitors" says "list": a word for reading.
    Description, as the server wrote it
    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.

    Annotations the server declares

    • title: List monitors
    • readOnlyHint: true
  • list_on_callList on-call calendars/schedules and the users currently on call for escalation.No findings

    Why it is in this group

    • The name "list_on_call" says "list": a word for reading.
    Description, as the server wrote it
    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.

    Annotations the server declares

    • title: List on-call schedules
    • readOnlyHint: true
  • list_status_pagesList public/private status pages with company name, subdomain, aggregate_state, and published flag.No findings

    Why it is in this group

    • The name "list_status_pages" says "list": a word for reading.
    Description, as the server wrote it
    List public/private status pages with company name, subdomain, aggregate_state, and published flag. Uptime API: GET /api/v2/status-pages.

    Annotations the server declares

    • title: List status pages
    • readOnlyHint: true

This is not a safety rating, and no finding is not a safety guarantee. The groups and findings come from fixed checks of the tool definitions the server returned on the date shown, not from its code or what it does when called. How the checks work.

Install

Pinned to version 1.16.3. Values in angle brackets are yours to fill in.

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

Run in a terminal.

Claude Code permissions

Allow the reads, ask before a change, deny the deletes. Paste into .claude/settings.json.

.claude/settings.json
{
  "permissions": {
    "allow": [
      "mcp__betterstack__list_monitors",
      "mcp__betterstack__get_monitor",
      "mcp__betterstack__list_incidents",
      "mcp__betterstack__get_incident",
      "mcp__betterstack__list_heartbeats",
      "mcp__betterstack__list_on_call",
      "mcp__betterstack__list_status_pages"
    ],
    "ask": [
      "mcp__betterstack__acknowledge_incident",
      "mcp__betterstack__resolve_incident"
    ],
    "deny": []
  }
}

Tools that only read are allowed, tools that change things ask first, tools that delete or cancel are denied. It assumes the server is installed as betterstack. Review it before you use it.