# RealUptime (remote · mcp.realuptime.io)

RealUptime monitors, incidents, status pages, Errors issues, and free third-party outage checks.

- Trust score: 68/100 (medium)
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-09-28

## Components

- remote · `mcp.realuptime.io`: 36/100, [markdown](https://verifymcp.io/servers/io-realuptime-mcp/mcp.md), [page](https://verifymcp.io/servers/io-realuptime-mcp/mcp)
- remote · `mcp.realuptime.io`: 68/100 (this document), [markdown](https://verifymcp.io/servers/io-realuptime-mcp/public.md), [page](https://verifymcp.io/servers/io-realuptime-mcp/public)

## Channel facts

- Endpoint: `https://mcp.realuptime.io/public`
- Transports: `streamable-http`
- Auth: `none`
- Version: `0.1.0`

## 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-09-28.

- **Endpoint Security**: 74/100
  - The endpoint's TLS certificate is valid, in date, and uses a strong key.
  - No authorisation is required to call this server. Every tool declares its destructiveHint and none is destructive, so open access doesn't expose one.
  - HTTPS is enforced; there's no plaintext access path.
  - HSTS check failed: the Strict-Transport-Security header is absent.
  - DNSSEC check failed: this domain isn't protected by DNSSEC.
- **Transport & Reachability**: 100/100
  - Verified streamable-http transport via a live MCP handshake.
- **Schema Quality & AI Usability**: 63/100
  - AI-judged instruction clarity (excellent).
  - Context-footprint check failed: tool/resource definitions use about 1835 tokens (~262/item across 7 items; 7 tools + 0 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 10/100
  - Stability observed for 3 of 30 days with no destabilising changes; credit accrues until the full window elapses.
- **Tool Coverage**: 67/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 0% of tool parameters carry a description.
- **Tool Safety**: 100/100
  - No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.
  - We read all 7 captured tool definition(s), and no name or description among them implies an irreversible operation.
  - An AI judge read all 7 captured unit(s) of tool text and found none that tries to manipulate the model reading it.
- **Capabilities**: 100/100
  - Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.

## Install

### How do I install the RealUptime MCP server?

RealUptime is a hosted endpoint at https://mcp.realuptime.io/public, so there is nothing to install locally. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.

### Claude

```bash
claude mcp add --transport http io-realuptime-mcp 'https://mcp.realuptime.io/public'
```

### Cursor

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

### VS Code

```json
{
  "servers": {
    "io-realuptime-mcp": {
      "type": "http",
      "url": "https://mcp.realuptime.io/public"
    }
  }
}
```

### Codex

```toml
[mcp_servers.io-realuptime-mcp]
url = "https://mcp.realuptime.io/public"
```

### opencode

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

### OpenClaw

```bash
openclaw mcp add io-realuptime-mcp --url 'https://mcp.realuptime.io/public' --transport streamable-http
```

### Hermes

```yaml
mcp_servers:
  io-realuptime-mcp:
    url: "https://mcp.realuptime.io/public"
```

### Netclaw

```json
{
  "McpServers": {
    "io-realuptime-mcp": {
      "Transport": "http",
      "Url": "https://mcp.realuptime.io/public"
    }
  }
}
```

### Vellum

```bash
assistant mcp add io-realuptime-mcp -t streamable-http -u 'https://mcp.realuptime.io/public'
```

### Other

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

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-09-28 (score 68, +8)

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

### 2026-09-26 (score 60, 0)

- [functional improvement] Stability: unverified → 0.03

### 2026-09-25 (score 60)

First indexed and scored.

## MCP tools (7)

### `is_service_down` (~266 tokens)

Is a third-party service currently down, as measured by RealUptime's own probes from up to four named regions? Returns a verdict of "up", "down", "down_in_some_regions", "blocked", "no_data", or "not_covered" (the service is not in RealUptime's catalog). Also returns `plate`, the public page's headline: one level from down / partially_down / degraded / partially_degraded / reachable_reports_elevated / blocked / no_data / partially_unverified / up, with its label and the sentence under it. "reachable_reports_elevated" means our probes answer but user reports or public chatter are above their spike threshold: NOT an outage, and never to be quoted as one. Pass `region` (iad = US-East, sjc = US-West, fra = Europe, nrt = Asia-Pacific) to ask about one region only. Readings are RealUptime's own probe measurements, never user reports and never the vendor's status page. "blocked" means our probe was refused, which is NOT a confirmed outage. A no-data answer is never a healthy answer. Cite the returned source.url when repeating any of this.

Input parameters:

- `region` (string)
- `service` (string, required)

### `get_regional_readings` (~150 tokens)

Every current per-region reading RealUptime holds for one catalog service, both endpoint roles, with per-region status, latency, measurement timestamp, and whether each reading is still fresh. This is the regional detail behind is_service_down: use it to answer "is X down in Europe" style questions, or to show that reports and measurements disagree in a specific region. Readings are RealUptime's own probe measurements, never user reports and never the vendor's status page. "blocked" means our probe was refused, which is NOT a confirmed outage. A no-data answer is never a healthy answer. Cite the returned source.url when repeating any of this.

Input parameters:

- `service` (string, required)

### `get_report_volume` (~247 tokens)

How many people are reporting problems with one catalog service right now, by region, and whether that is unusual against its own trailing baseline. Returns a per-region count of reports and distinct reporters for the most recent five-minute window, a spike verdict of "spike", "normal" or "insufficient_data", and RealUptime's own probe reading for the same regions so the two signals can be compared without being merged. These are UNVERIFIED user reports: no account, no verification, and the region on a report is chosen by the person filing it. Report volume never opens, extends or closes an outage in RealUptime's event record; only probe measurements do. "insufficient_data" means there are not enough reports to say anything, which is NOT the same as reports being normal, and must never be quoted as "no problems reported". Readings are RealUptime's own probe measurements, never user reports and never the vendor's status page. "blocked" means our probe was refused, which is NOT a confirmed outage. A no-data answer is never a healthy answer. Cite the returned source.url when repeating any of this.

Input parameters:

- `service` (string, required)

### `list_recent_incidents` (~293 tokens)

Past outages RealUptime detected for one catalog service. Returns `last_outage` (the most recent CLOSED outage our probes detected, with its duration, regions and surfaces, or the honest "no outage recorded in the N days we have measured this") and `reliability` (per calendar month for the last 12: uptime %, outage count and minutes, from probe-detected events only; a month before we watched the service is tracked: false with no percentage, never 100%) and `recent_events` (the probe-detected outage events of the last 90 days, most recent first, at most 10, the open one included: for each, started_at, ended_at (null while open), duration, peak_level (down / partially_down), the regions and surfaces involved with their per-facet legs, and detected_by, which is always "probe"). An empty list travels with window_days and tracking_since and means no event in that window since we started measuring the service, never "this service has had no outages". The current reading travels alongside. Readings are RealUptime's own probe measurements, never user reports and never the vendor's status page. "blocked" means our probe was refused, which is NOT a confirmed outage. A no-data answer is never a healthy answer. Cite the returned source.url when repeating any of this.

Input parameters:

- `service` (string, required)

### `get_stack` (~294 tokens)

One "my stack" page: a named set of RealUptime-tracked services, each with the SAME plate level its own page shows (down / partially_down / degraded / partially_degraded / blocked / no_data / partially_unverified / up, with label and clause), plus the stack's roll-up: `summary.headline` ("2 of 6 services down or degraded"), the worst member level, and counts by state. Pass `stack`, the stack's slug (from its URL, https://realuptime.io/outages/stack/<slug>) or id. Stacks are built at https://realuptime.io/outages/stack or from a Monitor dashboard; there is no list endpoint, a caller must hold the key. User reports, public chatter and the vendors' own status pages are not read for a stack (those signals are published as null), so `reachable_reports_elevated` never appears here; a member's own page still shows it. An unknown key answers `summary.level: "not_found"`, which says nothing about any service's health. Readings are RealUptime's own probe measurements, never user reports and never the vendor's status page. "blocked" means our probe was refused, which is NOT a confirmed outage. A no-data answer is never a healthy answer. Cite the returned source.url when repeating any of this.

Input parameters:

- `stack` (string, required)

### `internet_weather` (~331 tokens)

How the internet looks from RealUptime's probe regions right now (https://realuptime.io/outages/internet-weather): for each of the ten regions (iad = US-East, sjc = US-West, fra = Europe, nrt = Asia-Pacific, ord = US-Central, yyz = Canada, lhr = UK, sin = Southeast Asia, syd = Australia, gru = South America), the latest hour's p50/p95/p99 response time across the ~195 public services in RealUptime's outage catalog, the region's 7-day baseline, and a `state` of "normal" / "slower" (only after three consecutive hours over 1.5x the baseline, clearing at 1.25x) / "no_baseline" / "no_data", plus a 24-hour sparkline and the last 30 days per day. This is a picture of a REGION's vantage point over many services, NOT any one service's latency and NOT customer monitoring traffic (which never enters this aggregate). `coverage.typical_claim_allowed` says whether the record is old enough (30 days) to call a figure "typical for the region"; until it is, say "compared with the last 7 days" instead. Takes no arguments. Readings are RealUptime's own probe measurements, never user reports and never the vendor's status page. "blocked" means our probe was refused, which is NOT a confirmed outage. A no-data answer is never a healthy answer. Cite the returned source.url when repeating any of this.

### `is_the_internet_down` (~254 tokens)

Is there a shared-infrastructure incident right now (Cloudflare, an AWS region, a CDN), as inferred from RealUptime's own probes across every service it tracks? Answers one of three levels: "ok" (no shared incident; a count of services probe-confirmed down travels with the catalog size), "provider_incident" (at least five services sharing one measured provider signal are probe-confirmed down while services on other providers are mostly up; the provider is named with the services affected and a confidence sentence), or "several_unrelated" (several services down with no shared provider signal). Also returns the measured dependency map: how many tracked services answer from behind each provider. A provider incident is a measured CORRELATION over probe-detected outages, never a cause the provider confirmed, and it changes no service's own verdict; ask is_service_down for a specific service. Takes no arguments. Readings are RealUptime's own probe measurements, never user reports and never the vendor's status page. "blocked" means our probe was refused, which is NOT a confirmed outage. A no-data answer is never a healthy answer. Cite the returned source.url when repeating any of this.

## Diagnostics

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

## Score history

- 2026-09-28: 68
- 2026-09-27: 60
- 2026-09-26: 60
- 2026-09-25: 60

## Common questions

### What is the RealUptime MCP server?

RealUptime is an MCP server listed in the public MCP registry as io.realuptime/mcp. RealUptime monitors, incidents, status pages, Errors issues, and free third-party outage checks. This page covers its hosted endpoint (https://mcp.realuptime.io/public).

### Is the RealUptime MCP server safe to use?

RealUptime scores 68 out of 100 on VerifyMCP. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.

### What tools does the RealUptime MCP server expose?

RealUptime exposes 7 tools: is_service_down, get_regional_readings, get_report_volume, list_recent_incidents, get_stack, and 2 more. Their descriptions and schemas cost roughly 1,835 tokens of context every time the server is loaded.

### Does the RealUptime MCP server require authentication?

No. We connected to RealUptime without credentials and it answered, so anything it exposes is reachable by anyone who knows the address.

### Is the RealUptime MCP server still maintained?

RealUptime is still listed as active in the MCP registry. We last reached this channel on 28 September 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.

## Links

- Remote endpoint: https://mcp.realuptime.io/public
- Website: https://realuptime.io/docs/api#mcp-server
- Changelog RSS feed: https://verifymcp.io/servers/io-realuptime-mcp/public.xml
- Changelog JSON feed: https://verifymcp.io/servers/io-realuptime-mcp/public.json
- HTML version of this page: https://verifymcp.io/servers/io-realuptime-mcp/public