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 for a service's status and it answers with our check readings.
• /mcp, keyed: everything above plus twenty-eight tools over your own account, mirroring the REST API exactly. Bearer key required.

The keyed endpoint is available on every plan: any account can generate a key and call every tool its scope allows, reads and writes. Plan limits apply exactly as in the dashboard. 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 check readings of popular third-party services:

• is_service_down (service, region?): Do our own checks of a third-party service fail right now, from up to ten regions? Answers up (our checks pass), down (our checks fail), 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, the time of the check, 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 check reading, never alone.
• list_recent_incidents (service): Past probe events 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 with checks failing or degraded" roll-up.
• internet_weather (none): How the internet looks from our own check 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 check readings seen across the whole catalog at once, distinct from any one service's own status.

Every answer carries the regions actually read, the time of the check, 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 check was refused and is never "down", a no-data answer is never a passing check, 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 twenty-eight 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 thirty-five 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 regions your plan includes 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.
• create_error_project: Create an Errors project and receive its ingest address once, as dsn and sentryDsn, so an application can start reporting without a trip to the dashboard. Later reads show only the key's last four characters. The account's plan limits how many projects it may hold.
• set_error_issue_status: Resolve, ignore or reopen one Errors issue, so an agent can close the test errors it sent while setting up and a script can resolve an issue once its fix has shipped. It does what the dashboard does, and sending the status the issue already has succeeds. Returns the updated issue.
• 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.
• create_status_page: Create a public status page and return it with public_url, the address anyone can open.
• list_status_page_components: List the components published on one of the account's status pages, in display order.
• add_status_page_component: Publish one of the account's monitors on one of its status pages as a component.
• list_notification_channels: List the account's alert channels, redacted: the registered channels, and the two built-in destinations (the account owner's email and the account's Slack webhook).
• create_notification_channel: Add an alert channel. email is the account owner's address and takes no config; slack takes config.webhookUrl, is one per account, and is never replaced; discord, msteams, firehydrant, generic_json, opsgenie and incidentio take a name and that type's config.
• test_notification_channel: Send one real test alert to a registered channel and report whether its destination accepted it. A destination that accepts it verifies the channel.
• list_heartbeats: List the account's heartbeat monitors with their state and last ping time. Never their ping URLs.
• create_heartbeat: Create a heartbeat monitor for a scheduled job and return its ping URL. The ping URL is shown once: store it where the job runs.
• create_agent_token: Register a server agent and return its token and install command. The token is an account credential and is shown once: export it on that server as REALUPTIME_AGENT_TOKEN.

Every tool returns the same JSON shape as its REST equivalent, as a text content block; set_error_issue_status returns just the updated issue, where its REST equivalent also carries the issue's releases and occurrences. 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, add_incident_update, and every other tool the table above marks read_write, such as set_error_issue_status. A read key calling a write tool gets a clean isError: true result, not a crash or a silent no-op. Full detail, including rate limits (120 reads/min and 30 writes/min per key on paid plans, 60 requests/min per account on Free, shared with the REST API) and request-size limits, is in the API reference.

Plan limits

Every plan can call every tool, and the seven outage tools need no key at all. A tool call can do exactly what that plan's dashboard can do: monitor count, regions, check interval floor, status pages, subscribers, and team members stay at the plan's limits. 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, choosing 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.