MCP server

Two endpoints

RealUptime runs a standalone Model Context Protocol server on mcp.realuptime.io, a stateless HTTP service (JSON-RPC 2.0, no session state) with two endpoints:

• /public, keyless: seven read-only outage tools, no API key, no account, no signup. Ask your assistant whether a service is down and it answers from our own measurements.
• /mcp, keyed: everything above plus seventeen tools over your own account, mirroring the REST API exactly. Bearer key required.

Read access on the keyed endpoint is free: any account can generate a key and call every read tool. Write access (creating or changing a check, or opening and updating an incident) requires a Growth or Scale plan, the same rule the REST API enforces for every endpoint, reads included. See the full API reference for authentication, rate limits, and every REST endpoint the MCP tools mirror.

Keyless outage tools

Point any MCP client at https://mcp.realuptime.io/public with no credentials. It serves seven tools, all read-only, all over RealUptime's own probe measurements of popular third-party services:

• is_service_down (service, region?): Is a third-party service down right now, as measured by our own probes from up to ten regions? Answers up, down, down_in_some_regions, blocked, no_data, or not_covered.
• get_regional_readings (service): Every current per-region reading we hold for one catalog service, with latency, measurement time, and whether each reading is still fresh.
• get_report_volume (service): How many people are reporting problems with a service right now, by region, and whether that is unusual. Always travels with our own probe reading, never alone.
• list_recent_incidents (service): Past outages we detected for one catalog service, alongside the current reading.
• get_stack (stack): One "my stack" page by its slug or id: every member service's plate level, composed by the same rule as its own page, plus the stack's "N of M services down or degraded" roll-up.
• internet_weather (none): How the internet looks from our own probe regions right now: each region's latest response-time percentiles across the whole catalog, its 7-day baseline, and a normal or slower verdict.
• is_the_internet_down (none): Whether there is a shared-infrastructure incident right now (a CDN, a cloud region, a DNS provider), inferred from probe-confirmed outages correlated across the whole catalog, distinct from any one service's own status.

Every answer carries the regions actually read, a measurement timestamp, an explicit freshness verdict, and a URL to cite. The honesty rules are the ones the outage tracker methodology sets out and they matter most here, because an assistant repeats what it is told: "blocked" means our probe was refused and is never "down", a no-data answer is never a healthy answer, and a service we do not track answers "not covered" rather than a guess.

Claude Code

claude mcp add --transport http realuptime-outages https://mcp.realuptime.io/public

Claude Desktop, or any MCP client using a JSON config

{
  "mcpServers": {
    "realuptime-outages": {
      "url": "https://mcp.realuptime.io/public"
    }
  }
}

Checking it by hand

curl -X POST https://mcp.realuptime.io/public \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

The keyless endpoint is limited to 60 requests per minute per IP address, which is deliberately tighter than the keyed budget: an anonymous call cannot be attributed to an account, and unlike our public outage JSON endpoint an MCP response cannot be cached, so every call is a real read. One assistant question costs about four requests, so that is roughly fifteen questions a minute from one address. Over budget answers RU-6004 with a Retry-After. If you share an outbound address with a lot of other people, or you need sustained access, use the keyed endpoint instead: it has its own larger per-key budget.

The keyless endpoint serves those seven tools and nothing else. Every tool that touches an account stays on the keyed endpoint; calling one without a key answers RU-1006 telling you to add one. Nothing is stored about a keyless caller: no cookies, no session, no account.

The seventeen keyed tools

These need an API key on https://mcp.realuptime.io/mcp. The seven keyless tools above work there too, so a keyed client gets all twenty-four from one endpoint.

• list_checks: List every monitor on the account: id, name, url, and check interval.
• get_check_status: The current per-region status and aggregate status for one monitor. Same staleness-aware aggregation as the public status page: operational, degraded, down, stale, or unknown. A heartbeat monitor also carries its state, last ping, max runtime, whether it is held down after repeated failures, and its latest run.
• list_heartbeat_runs: A heartbeat monitor's runs, newest first: start, finish, outcome, duration, whether it got stuck, and any exit code or message a failed run reported.
• create_check: Add a new monitor. Enforces the account's tier limit and the same target-safety validation as the dashboard and REST API. Optional response assertions let an http check confirm the body, a header, or the status range, not just that it responded.
• update_check_regions: Change which of the 4 live regions probe an existing monitor. At least one region is required.
• update_check_assertions: Replace an http monitor's response assertions with the given set. A full replace: calling it with no fields clears every assertion.
• delete_check: Remove a monitor and its history.
• list_status_pages: List the account's public status page(s), including slug and URL path.
• list_incidents: List recent incidents across every monitor on the account, newest first.
• create_incident: Open a new incident against one of the account's own status pages and monitors. Inserts with status "investigating", writes the opening timeline update in the same transaction, and emails the page's confirmed subscribers.
• add_incident_update: Post a staged update (investigating, identified, monitoring, resolved) against an existing incident, advancing its lifecycle status in the same call. Emails the page's confirmed subscribers unless deduped as a double-submit.
• get_active_maintenance_window: The maintenance window currently active for one of the account's own status pages, or null if nothing is active right now.
• create_maintenance_window: Schedule a maintenance window against one of the account's own status pages. Alerts for the window's scope are suppressed without pausing checks, and the page's confirmed subscribers are notified by email. Give exactly one of endsAt or durationMinutes.
• end_maintenance_window: End a maintenance window early by moving its end time to now. A window that has not started yet, or is already over, is returned unchanged.
• list_error_projects: List the account's RealUptime Errors projects, with this month's event usage and every drop counter.
• list_error_issues: Search one Errors project's issues by text, release, status, and time window. The total is exact, and says whether the returned page is a subset of it.
• get_error_issue: One Errors issue in full: status, occurrence count, first and last seen, per-release breakdown, and recent occurrences with their scrubbed context.

Every tool returns the same JSON shape as its REST equivalent, as a text content block. A not-found, over-limit, unsafe-target, or rate-limited condition sets isError: true on the tool result rather than throwing, so a client sees a clean, structured failure instead of a crash.

Authentication and permission scopes

The MCP server uses the same bearer API key as the REST API, generated from the dashboard's API & MCP access section. Every key has a scope: read can call every read-only tool above; read_write can also call create_check, update_check_regions, update_check_assertions, delete_check, create_incident, and add_incident_update. A read key calling a write tool gets a clean isError: true result, not a crash or a silent no-op. This scope is a separate setting from the account-tier rule below: a free account's key is always read, since the write tools require a paid plan regardless of a key's own scope. Full detail, including rate limits (120 reads/min, 30 writes/min, shared with the REST API) and request-size limits, is in the API reference.

Tier requirements

Free accounts get read-only MCP access: list_checks, get_check_status, list_status_pages,list_incidents, and the three Errors read tools all work with a free-tier key, as do the seven outage tools (which need no key at all). The other tools (creating, updating, or deleting a check, and opening or updating an incident) require a Growth or Scale plan; a free-tier key calling one of them gets a clean upgrade message instead of running. This is different from the REST API, which stays a Growth and Scale feature end to end, reads included: a free-tier key is rejected there before any route runs. See pricing for what each plan includes.

Keyed setup

Claude Code

claude mcp add --transport http realuptime https://mcp.realuptime.io/mcp \
  --header "Authorization: Bearer ru_live_..."

Claude Desktop, or any MCP client using a JSON config

Add an entry to your client's MCP server configuration:

{
  "mcpServers": {
    "realuptime": {
      "url": "https://mcp.realuptime.io/mcp",
      "headers": {
        "Authorization": "Bearer ru_live_..."
      }
    }
  }
}

Any other MCP client

Point it at https://mcp.realuptime.io/mcp over HTTP, with theAuthorization: Bearer ru_live_... header set on every request. A client library normally handles the initialize to tools/list to tools/call sequence for you; the request below is only useful as a manual sanity check that the server is reachable and your key works.

curl -X POST https://mcp.realuptime.io/mcp \
  -H "Authorization: Bearer ru_live_..." \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"test","version":"1"}}}'

Getting a key

Generate an API key from the dashboard's API & MCP access section, on any plan. A free account can only create a read-only key; Growth and Scale accounts can choose read-only or read-write. The key is shown once, at creation, stored hashed server-side; if you lose it, generate a new one and revoke the old.