Uptimepage
REMOTE · MCP.UPTIMEPAGE.DEV · SCANNED SEP 27
Monitor uptime and incidents, run checks, and publish status updates from your Uptimepage org.
Available components
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. How we score → Why this is hard to score →
Endpoint Security94
- The endpoint's TLS certificate is valid, in date, and uses a strong key. View diagnostics → Pass
- 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. View diagnostics → Pass
- HTTPS is enforced; there's no plaintext access path. View diagnostics → Pass
- The HSTS (Strict-Transport-Security) header is present. View diagnostics → Pass
- DNSSEC check failed: this domain isn't protected by DNSSEC. See how to fix → View diagnostics → Fail
- The authorisation server offers only Dynamic Client Registration (RFC 7591), which MCP 2026-07-28 deprecated in favour of Client ID Metadata Documents. View diagnostics → Partial
Transport & Reachability100
- Verified streamable-http transport via a live MCP handshake. View diagnostics → Pass
Schema Quality & AI Usability73
- AI-judged instruction clarity (excellent).Pass
- Context-footprint check failed: tool/resource definitions use about 4905 tokens (~158/item across 31 items; 31 tools + 0 resources), over budget; trim descriptions and params. See how to fix → Fail
- Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management100
- No destabilizing schema changes in the last 30 days.Pass
Tool Coverage98
- 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
- 93% of tool parameters carry a description.Partial
- Structured output schemas are declared (100% of tools); any adoption earns full credit.Pass
Tool Safety100
- No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
- All 1 tool(s) whose name or description implies an irreversible operation declare an MCP destructiveHint annotation.Pass
- An AI judge read all 32 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities100
- Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.Pass
How do I install the Uptimepage MCP server?
Uptimepage is a hosted endpoint at https://mcp.uptimepage.dev/mcp, 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.
remote · mcp.uptimepage.dev
claude mcp add --transport http dev-uptimepage-uptimepage 'https://mcp.uptimepage.dev/mcp'
{
"mcpServers": {
"dev-uptimepage-uptimepage": {
"url": "https://mcp.uptimepage.dev/mcp"
}
}
} {
"servers": {
"dev-uptimepage-uptimepage": {
"type": "http",
"url": "https://mcp.uptimepage.dev/mcp"
}
}
} [mcp_servers.dev-uptimepage-uptimepage] url = "https://mcp.uptimepage.dev/mcp"
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"dev-uptimepage-uptimepage": {
"type": "remote",
"url": "https://mcp.uptimepage.dev/mcp",
"enabled": true
}
}
} openclaw mcp add dev-uptimepage-uptimepage --url 'https://mcp.uptimepage.dev/mcp' --transport streamable-http
mcp_servers:
dev-uptimepage-uptimepage:
url: "https://mcp.uptimepage.dev/mcp" {
"McpServers": {
"dev-uptimepage-uptimepage": {
"Transport": "http",
"Url": "https://mcp.uptimepage.dev/mcp"
}
}
} assistant mcp add dev-uptimepage-uptimepage -t streamable-http -u 'https://mcp.uptimepage.dev/mcp'
{
"mcpServers": {
"dev-uptimepage-uptimepage": {
"type": "http",
"url": "https://mcp.uptimepage.dev/mcp"
}
}
} The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs.
Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.
- 25 Sept 26 0
- We updated how we score, so this day's move reflects our rubric, not a change to the server See what changed → functional
- 24 Sept 26 0
- Tool “get_incident” rewrote its description, which is the text the model reads security
- Tool “publish_incident” rewrote its description, which is the text the model reads security
- “publish_incident” added an optional parameter “status_page_ids” cosmetic
- 20 Sept 26 0
- The server rewrote its instructions, which are the text every model session reads security
- New tool “pause_monitor”, which the server declares destructive security
- New tool “resolve_incident”, which the server declares destructive security
- New tool “unpublish_incident”, which the server declares destructive security
- New tool “update_monitor”, which the server declares destructive security
- New tool “update_status_page”, which the server declares destructive security
- Schema quality: 139 → 154 ▼ functional
- Tool coverage: 100% → 93% ▼ functional
- Destructive annotations: pass → 100 functional
- New tool “acknowledge_incident” functional
- New tool “add_status_page_components” functional
- New tool “create_monitor” functional
- New tool “create_monitors” functional
- New tool “create_status_page” functional
- New tool “post_incident_update” functional
- New tool “publish_incident” functional
- New tool “resume_monitor” functional
- New tool “run_check_now” functional
- New tool “update_status_page_component” functional
- 10 Sept 26 0
- Stability: 0.97 → pass security
- 9 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 93 to 97. That category is still filling its 30-day observation window: 28 days of observed history at the previous scan, 29 at this one. The score rises as the window fills, whether or not the server changes.
- 7 Sept 26 0
- The server rewrote its instructions, which are the text every model session reads security
- Tool “get_org_usage” rewrote its description, which is the text the model reads security
- Schema quality: 1930 → 2230 ▼ functional
- New tool “list_variables” functional
- 5 Sept 26 0
- The server rewrote its instructions, which are the text every model session reads security
- Tool “list_regions” rewrote its description, which is the text the model reads security
- Schema quality: 113 → 128 ▼ functional
- 4 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 77 to 80. That category is still filling its 30-day observation window: 23 days of observed history at the previous scan, 24 at this one. The score rises as the window fills, whether or not the server changes.
Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.
Captured 27 Sept 2026 · Probed https://mcp.uptimepage.dev/mcp
TLS valid
Negotiated TLS 1.3 with TLS_AES_128_GCM_SHA256 .
| Subject | Issuer | Valid from | Valid until | Key | Signature | Serial |
|---|---|---|---|---|---|---|
| CN=*.uptimepage.dev | CN=YE2,O=Let's Encrypt,C=US | 26 Sept 2026 | 25 Dec 2026 | ECDSA 256 | ECDSA-SHA384 | 6501e358767ecaf94e154f8e0b5a12c3b0b |
| SANs: *.uptimepage.dev | ||||||
| CN=YE2,O=Let's Encrypt,C=US (CA) | CN=Root YE,O=ISRG,C=US | 3 Sept 2025 | 2 Sept 2028 | ECDSA 384 | ECDSA-SHA384 | 4df3b15dd6c0784c507cd37b58e6f115 |
| CN=Root YE,O=ISRG,C=US (CA) | CN=ISRG Root X2,O=Internet Security Research Group,C=US | 13 May 2026 | 2 Sept 2032 | ECDSA 384 | ECDSA-SHA384 | 872165fc34b6e5fba8add5b3705fb53a |
| CN=ISRG Root X2,O=Internet Security Research Group,C=US (CA) | CN=ISRG Root X1,O=Internet Security Research Group,C=US | 13 May 2026 | 2 Sept 2032 | ECDSA 384 | SHA256-RSA | 6c8f1dc727c7117f7baf853ac980f9cd |
Background: What to check on a remote MCP endpoint →
DNSSEC insecure
Validation of mcp.uptimepage.dev. — Not signed
| Zone | DS | Keys | Algorithms | Outcome |
|---|---|---|---|---|
| . | trust_anchor | 20326, 38696 | 8, 8 | Verified |
| dev. | present | 60074 | 8 | Verified |
| uptimepage.dev. | absent | Unsigned (proven) parent-signed NSEC/NSEC3 proves an unsigned delegation |
Authentication Enforced and verified
The endpoint asked for a token and published valid RFC 9728 metadata describing how to get one.
| Result | Enforced and verified |
|---|---|
| Enforced | On tool calls |
| HTTP status | 200 |
WWW-Authenticate challenge Bearer resource_metadata="https://mcp.uptimepage.dev/.well-known/oauth-protected-resource", scope="targets:read status_page:read incidents:read"
Bearer resource_metadata="https://mcp.uptimepage.dev/.well-known/oauth-protected-resource", scope="targets:read status_page:read incidents:read" | Header | Value |
|---|---|
| strict-transport-security | max-age=31536000; includeSubDomains |
| x-content-type-options | nosniff |
| referrer-policy | strict-origin-when-cross-origin |
Protected resource metadata
| Document | https://mcp.uptimepage.dev/.well-known/oauth-protected-resource |
|---|---|
| Retrieved | Yes |
| Resource | https://mcp.uptimepage.dev/mcp |
| Authorisation server | https://app.uptimepage.dev |
Background: How OAuth 2.1 works in the 2026 MCP spec →
Transports 2 probes
| Transport | URL | Outcome | Status | Location |
|---|---|---|---|---|
| streamable-http | https://mcp.uptimepage.dev/mcp | Verified | 200 | |
| http (plaintext) | http://mcp.uptimepage.dev/mcp | HTTPS enforced | 308 | https://mcp.uptimepage.dev/mcp |
The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →
acknowledge_incident Acknowledge incident ~112
Acknowledge an incident: take ownership and halt escalation. Internal/operational only — does NOT post anything to the public status page. Use post_incident_update for customer-facing updates. Asks for confirmation where the client can show a prompt; otherwise runs on the token's scope. Not read-only.
| Name | Type | Req | Description |
|---|---|---|---|
| id | string | yes | The incident id. |
| note | string|null | – | Optional internal note recorded on the incident's activity timeline. This is operator-facing, not published to the public status page. |
| Name | Type | Req | Description |
|---|---|---|---|
| acknowledged_at | string|null | – | RFC 3339 acknowledged time, when set. |
| incident_id | string | yes | – |
| resolved_at | string|null | – | RFC 3339 resolved (ended) time, when set. |
| state | string | yes | Operational state after the action: `triggered`, `acknowledged`, `resolved`. |
No examples provided.
add_status_page_components Add status page components ~139
Add monitors to a status page as public components, in one confirmation where the client can show a prompt. Give each a public_name the page's readers will understand, since the monitor's own name is operator-facing, and a public_group to file related components together. Monitors already on the page are reported as such rather than duplicated. detail_link_enabled publishes a per-monitor detail view that shows the monitor's real name and address, not public_name. Not read-only.
| Name | Type | Req | Description |
|---|---|---|---|
| components | array | yes | The monitors to add, in the order they should appear. |
| slug | string | yes | The page slug (from `list_status_pages`). |
| Name | Type | Req | Description |
|---|---|---|---|
| added | integer | yes | – |
| results | array | yes | – |
| slug | string | yes | – |
No examples provided.
create_monitor Create monitor ~696
Create a monitor for an http, tcp, ping, dns, tls_cert, domain_expiry or heartbeat check. The check is run once before anything is saved and the result is shown to the user along with every setting it would apply; where the client can show a prompt, nothing is created unless they approve; otherwise the monitor is created on the token's scope and the trial result comes back with it. Bind it to alerts as you create it: pass channel_ids from list_notification_channels (this needs the channels:read scope), and if the org has no channel yet, say so rather than leaving a monitor that pages nobody. Leave regions unset unless the user named where they want the check to run from — omitted, it probes from the operator's default set, which is already the intended coverage; naming more regions than the plan allows is refused outright. Request headers and a request body can be set, but a credential must be referenced rather than pasted: write `Bearer {{ my_key }}` and call list_variables for the keys this org has. A URL carrying a username or password is refused, and browser flows cannot be created here — add those in the app. Not read-only.
| Name | Type | Req | Description |
|---|---|---|---|
| alert_confirmations | integer|null | – | Consecutive failing checks before the monitor alerts. Minimum 1, defaults to 2. |
| channel_ids | array|null | – | Channel ids from `list_notification_channels` to alert. Omitting them creates a monitor that pages nobody, which is worth saying out loud rather than leaving for an outage to reveal. The channels the… |
| check | – | yes | – |
| group_name | string|null | – | Operator-side grouping label. |
| interval_secs | integer|null | – | Seconds between checks, held to the plan's floor and the check kind's own floor. Omit it to get the cadence the app's own picker opens this kind at, which is well above the hard minimum for the slow-… |
| name | string | yes | What the operator will see in lists and alerts. |
| notify_recovery | boolean|null | – | Whether recovery is announced. Defaults to true. |
| region_policy | – | – | Detection quorum across probe regions. |
| regions | array|null | – | Probe regions to run the check from, as ids from `list_regions`. Omit unless the user named the places they want covered: omitting takes the regions `list_regions` flags `default_selected`, which is… |
| renotify_interval_secs | integer|null | – | Seconds before the first reminder while an outage stays unacknowledged; each further reminder waits twice as long, up to a day. 0 turns reminders off; otherwise at least 60. Defaults to 3600. |
| tags | array|null | – | At most 50, each at most 50 characters. |
| Name | Type | Req | Description |
|---|---|---|---|
| address | string | yes | What the check watches, as stored. |
| alerts | string | yes | The channels this monitor will alert, by name, or `nobody` when nothing reaches it. One covered by a channel's tag rule rather than a binding is marked `by tag`. A channel that cannot deliver says so… |
| id | string | yes | – |
| interval_secs | integer | yes | – |
| name | string | yes | – |
| probe | – | – | The trial run's outcome, which the operator saw before approving. Absent for a heartbeat, which has nothing to probe. |
| regions | array | yes | Probe regions the monitor was assigned, which is the operator's default set when `regions` was omitted. Empty for a heartbeat. |
No examples provided.
create_monitors Create monitors ~144
Create several monitors at once, with one confirmation covering the batch where the client can show a prompt. Every check is run once first and all the results are shown together, so a misconfigured endpoint is visible before anything is saved. An item that fails validation or its trial run is reported in the results and the rest are still created. Prefer this over repeated create_monitor calls whenever the user names more than one thing to watch: it costs them one prompt instead of many. Same per-monitor fields and same limits as create_monitor. Not read-only.
| Name | Type | Req | Description |
|---|---|---|---|
| monitors | array | yes | The monitors to create. Each is validated and probed before the single confirmation covering the batch. |
| Name | Type | Req | Description |
|---|---|---|---|
| created | integer | yes | – |
| results | array | yes | – |
No examples provided.
create_status_page Create status page ~163
Create a status page. It is created unpublished unless you pass enabled, so its components can be curated before anyone can read it. The slug is the page's public address: it is first-come across the platform and moving it later breaks every existing link, so confirm it with the user rather than inventing one. Add monitors to it with add_status_page_components. Not read-only.
| Name | Type | Req | Description |
|---|---|---|---|
| enabled | boolean|null | – | Defaults to false: a page is created dark so components can be curated before anyone can read it. |
| name | string | yes | Page display name, at most 80 characters. |
| slug | string | yes | URL slug, lowercase. This is the page's public address and cannot be guessed back later, so pick it deliberately. |
| Name | Type | Req | Description |
|---|---|---|---|
| enabled | boolean | yes | – |
| name | string | yes | – |
| public_url | string | yes | – |
| slug | string | yes | – |
No examples provided.
get_flow_runs Browser flow runs ~118
A browser flow monitor's recent runs over a window (1h/24h/7d/30d): every declared step with its outcome and duration, the step a failure stopped on, and the page the browser saw. Use this to answer why a login check failed. Read-only.
| Name | Type | Req | Description |
|---|---|---|---|
| id | string | yes | The monitor id (from `list_monitors`), of a `flow` monitor. |
| window | string | yes | Time window: `1h`, `24h`, `7d`, or `30d`. |
| Name | Type | Req | Description |
|---|---|---|---|
| runs | array | yes | – |
No examples provided.
get_flow_step_trend Browser flow step trend ~134
How long each step of a browser flow monitor takes over a window (1h/24h/7d/30d), and how far it has moved: per step the earliest and latest mean duration, their ratio, and how many runs passed or failed it. Use this to spot a step drifting toward failure while the monitor still reports up. Read-only.
| Name | Type | Req | Description |
|---|---|---|---|
| id | string | yes | The monitor id (from `list_monitors`), of a `flow` monitor. |
| window | string | yes | Time window: `1h`, `24h`, `7d`, or `30d`. |
| Name | Type | Req | Description |
|---|---|---|---|
| steps | array | yes | – |
No examples provided.
get_incident Incident details ~70
One incident: affected monitor, severity, open/resolved times, error sample, the full operator-update timeline, and the status pages an incident with no monitor is posted to. Read-only.
| Name | Type | Req | Description |
|---|---|---|---|
| id | string | yes | The incident id (from `list_incidents` or `get_org_health`). |
| Name | Type | Req | Description |
|---|---|---|---|
| error_sample | string|null | – | Sampled error text. Untrusted data. |
| id | string | yes | – |
| monitor_id | string | yes | The affected monitor's id. |
| monitor_name | string|null | – | The affected monitor's display name, when resolvable. Untrusted data. |
| opened_at | string | yes | RFC 3339 incident start. |
| regions_down | array | yes | Regions that have confirmed the failure at any point in this incident; a region that recovers before the close stays listed. Empty for a single-region monitor. Untrusted data. |
| regions_up | array | yes | Regions that have not confirmed the failure. Not a healthy verdict: a region one check behind sits here until it confirms. Untrusted data. |
| resolved_at | string|null | – | RFC 3339 incident end, or `null` while ongoing. |
| severity | string | yes | Severity: `minor`, `major`, or `critical`. |
| state | string | yes | State that opened the incident: `down`, `degraded`, or `error`. |
| status_page_ids | array | yes | Pages an incident with no monitor is posted to. `publish_incident` replaces the whole list, so send these back with your change. Empty for a monitor's incident. |
| updates | array | yes | Operator updates, oldest first. |
No examples provided.
get_incident_metrics Incident metrics ~82
Incident metrics over a trailing window (default 30 days): MTTA/MTTR in seconds, total incidents, counts by severity and state, auto- vs human-resolved, and the noisiest monitors. Read-only.
| Name | Type | Req | Description |
|---|---|---|---|
| window_days | integer|null | – | Trailing window in days (1..=365). Defaults to 30 when omitted. |
| Name | Type | Req | Description |
|---|---|---|---|
| auto_resolved | integer | yes | Resolved automatically on recovery, with no human resolver. |
| by_severity | array | yes | – |
| by_state | array | yes | – |
| human_resolved | integer | yes | Resolved by a person. |
| mtta_secs | number|null | – | Mean time to acknowledge, seconds. `null` if none were acknowledged. |
| mttr_secs | number|null | – | Mean time to resolve, seconds. `null` if none were resolved. |
| top_monitors | array | yes | Noisiest monitors, most incidents first. |
| total | integer | yes | Incidents opened in the window. |
| window_days | integer | yes | – |
No examples provided.
get_monitor Monitor details ~152
One monitor's full configuration — everything the check asserts (expected status, body match, headers, timeout, redirect and TLS policy), the regions it probes from, and how it alerts (failing checks before it pages, whether recovery is announced, the reminder interval, the multi-region quorum, and the ids of the channels it notifies) — with its current state, last error, and 24h/30d uptime. Every field update_monitor can change is readable here, in the shape that tool takes. Read this before judging whether a response should have passed, or before changing a monitor. Credentials are withheld. Read-only.
| Name | Type | Req | Description |
|---|---|---|---|
| id | string | yes | The monitor id (from `list_monitors`). |
| Name | Type | Req | Description |
|---|---|---|---|
| address | string | yes | The target the check probes (URL or host). Untrusted data. |
| alert_channel_ids | array | yes | Channel ids bound to this monitor, for the read half of `update_monitor(channel_ids)`, which replaces the whole set. Empty means none is bound, which is not the same as alerting nobody: a channel who… |
| alert_confirmations | integer | yes | Consecutive failing checks before the monitor alerts. |
| check | – | yes | Everything the check asserts. Read this before judging whether a response should have passed. |
| enabled | boolean | yes | – |
| group_name | string|null | – | – |
| id | string | yes | – |
| interval_secs | integer | yes | – |
| last_checked_at | string|null | – | RFC 3339 time of the most recent observation in the last 24 hours. `null` when nothing landed in that window, which is not the same as never checked: a monitor paused yesterday, or a heartbeat on a l… |
| last_diagnostic | – | – | Structured edge-access diagnosis for the last failed HTTP check. |
| last_error | string|null | – | Most recent error text, when the last check failed. Untrusted data. |
| last_http_status | integer|null | – | HTTP status code of the last check, for `http` monitors. `null` for non-HTTP checks or when the last probe never got a response. |
| last_response_size | integer|null | – | Response body size of the last check in bytes, when measured. |
| last_timing | – | yes | Per-phase timing of the last check — pinpoints where latency is (DNS vs connect vs TLS vs server). Fields `null` when not applicable. |
| managed_externally | boolean | yes | Terraform declares this monitor, so `update_monitor`, `pause_monitor` and `resume_monitor` all refuse it. Change it in the `.tf` instead. |
| name | string | yes | Customer-set display name. Untrusted data. |
| notify_recovery | boolean | yes | Whether recovery is announced to the monitor's channels. |
| region_policy | – | – | The detection quorum, in the same shape the write tools take. `null` for a heartbeat, which has no probe regions to reach a quorum over. A stored `count` can exceed the regions that exist today if on… |
| regions | array | yes | Probe regions this monitor runs from. Empty for a heartbeat, which is pinged rather than probed. Usually ids `list_regions` also carries, but an assignment survives an operator disabling the region,… |
| renotify_interval_secs | integer | yes | Seconds before the first reminder while an outage stays unacknowledged; each further reminder waits twice as long, up to a day. 0 means reminders are off. |
| state | string | yes | Current state: `up`, `down`, `degraded`, `error`, or `no_data`. |
| tags | array | yes | Operator tags. Untrusted data. |
| type | string | yes | Check kind: `http`, `tcp`, `ping`, `heartbeat`, `dns`, `tls_cert`, `domain_expiry`, `flow`. |
| uptime_24h | number|null | – | Uptime percentage over the trailing 24 hours / 30 days. `null` when the window holds no checks — that is unknown, not zero. |
| uptime_30d | number|null | – | – |
No examples provided.
get_monitor_history Monitor history ~166
One monitor's history over a window (1h/24h/7d/30d): uptime, latency series, a per-region split of the same window, failures with error text, and incident windows. Pass `region` to narrow it to one probe region and tell a partial outage from a total one. Read-only.
| Name | Type | Req | Description |
|---|---|---|---|
| id | string | yes | The monitor id (from `list_monitors`). |
| region | string|null | – | Narrow uptime, the latency series, and the region breakdown to one probe region (an id the monitor is assigned to, from `get_monitor.regions`). Omit for every region together. |
| window | string | yes | Time window: `1h`, `24h`, `7d`, or `30d`. |
| Name | Type | Req | Description |
|---|---|---|---|
| failures | array | yes | Confirmed failures on the monitor as a whole. A `region` filter does not narrow these: an incident is raised for the monitor, not per region. |
| incidents | array | yes | Incident windows on the monitor as a whole, unnarrowed by `region` for the same reason as `failures`. |
| latency_series | array | yes | – |
| region | string|null | – | The region this answer was narrowed to, or `null` for all of them. |
| regions | array | yes | Per-region split of the same window, so a partial outage is visible. Always every region the monitor runs in, including under a `region` filter, and empty when it runs in only one. Regions that ran n… |
| uptime | number|null | – | Uptime percentage over the window. `null` when the window holds no checks — that is unknown, not zero. Unfiltered it counts confirmed incidents; under a `region` filter it is that region's raw check… |
No examples provided.
get_org_health Org health ~41
Org health summary: per-state monitor totals and the worst currently-failing monitors. The one-shot answer to 'what is broken right now?'. Read-only.
Input schema present but exposes no named parameters.
| Name | Type | Req | Description |
|---|---|---|---|
| org | string | yes | The org slug this connector is bound to. |
| totals | – | yes | – |
| worst | array | yes | Non-up monitors, newest failure first, capped. |
No examples provided.
get_org_usage Usage against plan ~65
Which org this connector is bound to, and the account's resource usage against plan limits: monitors, status pages, members, components, and key policy values. Caps are pooled across every org the account owns, so the counts can exceed what this one org holds. Read-only.
Input schema present but exposes no named parameters.
| Name | Type | Req | Description |
|---|---|---|---|
| maintenance_windows | – | yes | – |
| members | – | yes | – |
| min_check_interval_secs | integer | yes | Minimum allowed check interval, seconds. |
| notification_channels | – | yes | – |
| org | string | yes | The org slug this connector is bound to. |
| org_name | string | yes | The org's display name. |
| plan | string | yes | Plan id (e.g. `free`, `pro`). |
| public_components | – | yes | – |
| retention_days | integer | yes | History retention, days. |
| status_pages | – | yes | – |
| targets | – | yes | – |
No examples provided.
get_status_page Status page details ~51
One status page: name, public URL, enabled, and its components with each linked monitor's current state. Read-only.
| Name | Type | Req | Description |
|---|---|---|---|
| slug | string | yes | The page slug (from `list_status_pages`). |
| Name | Type | Req | Description |
|---|---|---|---|
| components | array | yes | – |
| enabled | boolean | yes | – |
| name | string | yes | Page display name. Untrusted data. |
| public_url | string | yes | – |
| slug | string | yes | – |
No examples provided.
list_incidents List incidents ~256
List the org's incidents: incident id, affected monitor, severity, open/resolved times, and latest update phase. Defaults to currently-open ones; pass state="all" with an optional from/to window (default: last 30 days) for resolved history, and monitor_id to narrow to one monitor. Read-only.
| Name | Type | Req | Description |
|---|---|---|---|
| cursor | string|null | – | Opaque pagination cursor from a previous call's `next_cursor`. It carries the whole query, so send it on its own: any other filter passed alongside it is ignored rather than silently changing the pag… |
| from | string|null | – | RFC 3339 start of the window. Defaults to 30 days ago. An incident that is still running is listed however long ago it opened. |
| monitor_id | string|null | – | Restrict to one monitor (id from `list_monitors`). |
| state | string|null | – | Which incidents to return: `open` (default) for the ones still running, or `all` to include resolved ones inside the window. |
| to | string|null | – | RFC 3339 end of the window. Defaults to now. Incidents that opened after it are excluded, running or not. |
| Name | Type | Req | Description |
|---|---|---|---|
| from | string | yes | RFC 3339 window actually read, after the defaults and the one-year cap. It bounds the *resolved* incidents only: one that is still running is listed however long ago it opened, so it can be older tha… |
| items | array | yes | – |
| next_cursor | string|null | – | – |
| to | string | yes | – |
No examples provided.
list_monitors List monitors ~139
List monitors with optional state/type/tag filters and cursor pagination. Each item carries its current state and last-checked time. Read-only.
| Name | Type | Req | Description |
|---|---|---|---|
| cursor | string|null | – | Opaque pagination cursor from a previous call's `next_cursor`. |
| state | string|null | – | Filter by current state: `up`, `down`, `degraded`, `error`, `no_data`. |
| tag | string|null | – | Filter to monitors carrying this exact tag. |
| type | string|null | – | Filter by check kind: `http`, `tcp`, `ping`, `heartbeat`, `dns`, `tls_cert`, `domain_expiry`, `flow`. |
| Name | Type | Req | Description |
|---|---|---|---|
| items | array | yes | – |
| next_cursor | string|null | – | – |
No examples provided.
list_notification_channels List notification channels ~145
The org's notification channels: id, operator-set name, kind (email, slack, telegram, webhook, and so on), and whether the channel is enabled. Two flags say a channel is not working even where it reads as ready: awaiting_verification for an email address nobody confirmed, and not_delivering for an enabled channel whose recent alerts all failed to arrive. auto_bind_tags is the channel's tag rule: it also pages any monitor carrying one of those tags, so a monitor with no binding can still be covered. Channel settings are withheld, since they hold webhook URLs and bot tokens. Channels are created in the Uptimepage app, not here. Read-only.
Input schema present but exposes no named parameters.
| Name | Type | Req | Description |
|---|---|---|---|
| items | array | yes | – |
No examples provided.
list_regions List probe regions ~125
The fleet's probe regions: id, display name, city, country, continent, and whether each is on by default for a new monitor. Reports `max_regions` only when the plan reaches fewer regions than the catalog lists, so a set too large to be accepted is visible before it is sent. Use it to pass a valid `region` to get_monitor_history, and to read where a check would run from. This is a catalog, not a menu to fill: leave `create_monitor.regions` unset unless the user named the places they want covered. Read-only.
Input schema present but exposes no named parameters.
| Name | Type | Req | Description |
|---|---|---|---|
| items | array | yes | – |
| max_regions | integer|null | – | How many of these regions one monitor may probe from, when the plan allows fewer than the catalog holds. A `create_monitor` naming more is refused outright, not trimmed to fit. Null when the plan rea… |
No examples provided.
list_status_pages List status pages ~53
List the org's status pages: slug, name, public URL, enabled. Cursor-paginated. Read-only.
| Name | Type | Req | Description |
|---|---|---|---|
| cursor | string|null | – | Opaque pagination cursor from a previous call's `next_cursor`. |
| Name | Type | Req | Description |
|---|---|---|---|
| items | array | yes | – |
| next_cursor | string|null | – | – |
No examples provided.
list_tags List tags ~46
Every tag in use across the org's monitors, most-used first, with how many monitors carry each. Pass one back as the `tag` filter to list_monitors. Read-only.
Input schema present but exposes no named parameters.
| Name | Type | Req | Description |
|---|---|---|---|
| items | array | yes | – |
| truncated | boolean | yes | The org has more tags than the cap returned here, so a tag missing from `items` is not proof it does not exist. |
No examples provided.
list_variables List variables ~96
The org's reusable variables: key, and whether it is a secret. Values are never returned, and a secret's value is never even read. Write a variable into a monitor's header or body as `{{ key }}`, which is resolved when the check runs: this is how an authenticated check is built here, since pasting the credential itself is refused. Variables are created and edited in the app, not here. Read-only.
Input schema present but exposes no named parameters.
| Name | Type | Req | Description |
|---|---|---|---|
| items | array | yes | – |
No examples provided.
pause_monitor Pause monitor ~63
Pause a monitor (stop its checks until resumed). Asks for confirmation where the client can show a prompt; otherwise runs on the token's scope. Not read-only; idempotent.
| Name | Type | Req | Description |
|---|---|---|---|
| id | string | yes | The monitor id (from `list_monitors`). |
| Name | Type | Req | Description |
|---|---|---|---|
| enabled | boolean | yes | The monitor's enabled state after the change. |
| id | string | yes | – |
No examples provided.
post_incident_update Post incident update ~125
Post a public, customer-facing update to an incident's status-page timeline (phase + message). This is what your subscribers and status-page visitors see. Asks for confirmation where the client can show a prompt; otherwise runs on the token's scope. Not read-only.
| Name | Type | Req | Description |
|---|---|---|---|
| id | string | yes | The incident id. |
| message | string | yes | Public message shown on the status page. |
| phase | string|null | – | Optional phase: `investigating`, `identified`, `monitoring`, `resolved`, `postmortem`. Defaults to `investigating`. |
| Name | Type | Req | Description |
|---|---|---|---|
| incident_id | string | yes | – |
| posted_at | string | yes | RFC 3339 time the update was posted. |
No examples provided.
publish_incident Publish incident ~219
Publish an incident so it appears on every status page carrying the affected monitor, optionally seeding the public title and description. An incident with no monitor needs `status_page_ids` naming the pages to show it on; the list replaces its pages, so start from `get_incident`'s `status_page_ids`. Status-page subscribers may be notified. Asks for confirmation where the client can show a prompt; otherwise runs on the token's scope. Not read-only; idempotent.
| Name | Type | Req | Description |
|---|---|---|---|
| id | string | yes | The incident id. |
| public_description | string|null | – | Public summary shown under the headline. |
| public_title | string|null | – | Public headline shown on the status page. |
| status_page_ids | array|null | – | Status page ids (from `list_status_pages`) for an incident with no monitor; replaces its pages, so start from `get_incident`'s `status_page_ids` to add or drop one. Leave unset for a monitor's incide… |
| Name | Type | Req | Description |
|---|---|---|---|
| incident_id | string | yes | – |
| visibility | string | yes | Visibility after the change: `public` or `internal`. |
No examples provided.
resolve_incident Resolve incident ~96
Resolve an incident (mark the operational state resolved). Internal only — does not post to the public status page. Asks for confirmation where the client can show a prompt; otherwise runs on the token's scope. Not read-only.
| Name | Type | Req | Description |
|---|---|---|---|
| id | string | yes | The incident id. |
| note | string|null | – | Optional internal note recorded on the incident's activity timeline. This is operator-facing, not published to the public status page. |
| Name | Type | Req | Description |
|---|---|---|---|
| acknowledged_at | string|null | – | RFC 3339 acknowledged time, when set. |
| incident_id | string | yes | – |
| resolved_at | string|null | – | RFC 3339 resolved (ended) time, when set. |
| state | string | yes | Operational state after the action: `triggered`, `acknowledged`, `resolved`. |
No examples provided.
resume_monitor Resume monitor ~62
Resume a paused monitor (restart its checks). Asks for confirmation where the client can show a prompt; otherwise runs on the token's scope. Not read-only; idempotent.
| Name | Type | Req | Description |
|---|---|---|---|
| id | string | yes | The monitor id (from `list_monitors`). |
| Name | Type | Req | Description |
|---|---|---|---|
| enabled | boolean | yes | The monitor's enabled state after the change. |
| id | string | yes | – |
No examples provided.
run_check_now Run check now ~90
Run a check on a monitor immediately and record the result. Asks for confirmation where the client can show a prompt; otherwise runs on the token's scope. A down result may fire the org's normal alerts. Heartbeat monitors cannot be probed (they wait for your systems to ping them). Not read-only.
| Name | Type | Req | Description |
|---|---|---|---|
| id | string | yes | The monitor id (from `list_monitors`). |
| Name | Type | Req | Description |
|---|---|---|---|
| checked_at | string | yes | RFC 3339 time of the probe. |
| diagnostic | – | – | Structured edge-access diagnosis, when a supported signature matched. |
| duration_ms | integer | yes | – |
| error | string|null | – | Error text when the probe failed. Untrusted data. |
| http_status | integer|null | – | HTTP status code, for `http` monitors. `null` for non-HTTP checks or when no response was received. |
| id | string | yes | – |
| response_size | integer|null | – | Response body size in bytes, when measured. |
| state | string | yes | Observed state: `up`, `down`, `degraded`, `error`. |
| timing | – | yes | Per-phase timing of the probe (DNS / connect / TLS / first byte). |
No examples provided.
unpublish_incident Unpublish incident ~78
Hide a published incident from the public status pages again. Its operator timeline is untouched. Asks for confirmation where the client can show a prompt; otherwise runs on the token's scope. Not read-only; idempotent.
| Name | Type | Req | Description |
|---|---|---|---|
| id | string | yes | The incident id (from `list_incidents` or `get_org_health`). |
| Name | Type | Req | Description |
|---|---|---|---|
| incident_id | string | yes | – |
| visibility | string | yes | Visibility after the change: `public` or `internal`. |
No examples provided.
update_monitor Retune monitor ~419
Change how loudly a monitor is watched: check interval, alert confirmations, recovery notices, reminder interval, tags, group, the multi-region detection quorum, and which notification channels it alerts (channel_ids replaces the whole set, and needs the channels:read scope). It cannot change what the check watches — name, address, assertions, expected status, headers, body, probe regions and owner are refused. A monitor managed by Terraform is refused outright. Shows the old and new value of every field before it runs, where the client can show a prompt; otherwise runs on the token's scope. Not read-only.
| Name | Type | Req | Description |
|---|---|---|---|
| alert_confirmations | integer|null | – | Consecutive failing checks before the monitor alerts. Minimum 1. Raising it quietens a flapping monitor at the cost of alerting later. |
| channel_ids | array|null | – | Replaces the whole set of alerted channels, by id from `list_notification_channels`. Read the monitor first: a channel left out of this list stops being alerted. An empty list silences the monitor. |
| group_name | string|null | – | Operator-side grouping label. Send `null` to clear it; omit to keep it. |
| id | string | yes | The monitor id (from `list_monitors`). |
| interval_secs | integer|null | – | Seconds between checks. Held to the plan's floor and the check kind's own floor, whichever is higher. |
| notify_recovery | boolean|null | – | Whether recovery is announced to the monitor's channels. |
| region_policy | – | – | Detection quorum across probe regions. |
| renotify_interval_secs | integer|null | – | Seconds before the first reminder while an outage stays unacknowledged; each further reminder waits twice as long, up to a day. 0 turns reminders off; otherwise at least 60. |
| tags | array|null | – | Replaces the whole tag list. Read the monitor first: a tag left out of this list is removed. At most 50 tags, each at most 50 characters. |
| Name | Type | Req | Description |
|---|---|---|---|
| changes | array | yes | What moved. Empty when every value sent already matched the stored one, in which case nothing was written and no confirmation was asked for. |
| id | string | yes | – |
No examples provided.
update_status_page Update status page ~118
Rename a status page, move it to a new slug, or publish and unpublish it. An omitted field is left alone. Changing the slug moves the public URL and breaks existing links. Not read-only; idempotent.
| Name | Type | Req | Description |
|---|---|---|---|
| enabled | boolean|null | – | Publish or unpublish the page. |
| name | string|null | – | New display name. |
| new_slug | string|null | – | New slug. Changing it moves the public URL and breaks existing links. |
| slug | string | yes | The page to change, by its current slug. |
| Name | Type | Req | Description |
|---|---|---|---|
| enabled | boolean | yes | – |
| name | string | yes | – |
| public_url | string | yes | – |
| slug | string | yes | – |
No examples provided.
update_status_page_component Update status page component ~116
Change how one monitor is presented on a status page: its public name, description, group or position. An omitted field is left alone. Not read-only; idempotent.
| Name | Type | Req | Description |
|---|---|---|---|
| monitor_id | string | yes | The monitor id whose curation is being changed. |
| public_description | string|null | – | – |
| public_group | string|null | – | – |
| public_name | string|null | – | – |
| slug | string | yes | The page slug (from `list_status_pages`). |
| sort_order | integer|null | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| monitor_id | string | yes | – |
| slug | string | yes | – |
No examples provided.
What is the Uptimepage MCP server?
Uptimepage is an MCP server listed in the public MCP registry as dev.uptimepage/uptimepage. Monitor uptime and incidents, run checks, and publish status updates from your Uptimepage org. This page covers its hosted endpoint (https://mcp.uptimepage.dev/mcp).
Is the Uptimepage MCP server safe to use?
Uptimepage scores 93 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 Uptimepage MCP server expose?
Uptimepage exposes 31 tools: acknowledge_incident, add_status_page_components, create_monitor, create_monitors, create_status_page, and 26 more. Their descriptions and schemas cost roughly 4,379 tokens of context every time the server is loaded.
Does the Uptimepage MCP server require authentication?
Yes. Uptimepage asked us for credentials when we connected, so you will need to authorise it in your MCP client before it can do anything.
Is the Uptimepage MCP server still maintained?
Uptimepage is still listed as active in the MCP registry. We last reached this channel on 27 September 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.