# hyperping > hyperping, an MCP server by hyperping.com, listed from the official MCP registry. Indexed, not reviewed: facts and our own checks, no score or ranking. Uptime, API and server monitoring with outages, reporting, on-call and status pages. - Canonical: https://www.anchorterminal.com/tools/hyperping - Markdown: https://www.anchorterminal.com/tools/hyperping.md (~3,450 tokens) - Slim: https://www.anchorterminal.com/tools/hyperping.min.md (~3,380 tokens, same facts, less prose, for token-sensitive contexts) - JSON: https://www.anchorterminal.com/tools/hyperping.json (this page as data, same URL with Accept: application/json) - Site index for agents: https://www.anchorterminal.com/llms.txt (full text: https://www.anchorterminal.com/llms-full.txt) - API: https://www.anchorterminal.com/api/v1/index.json - Updated: 2026-10-04 # hyperping > Indexed, not reviewed: facts from the official MCP registry and our own checks. No score, grade or rank, and not in the rankings until the panel reviews it. How the index works: https://www.anchorterminal.com/indexed/ - Kind: MCP server, by hyperping.com (https://hyperping.com/docs/mcp) - Category: Observability & incidents (https://www.anchorterminal.com/categories/observability.md) - Listed because: It's published in the registry under hyperping.com, a namespace the registry only gives to whoever proves they control that domain. - What the official MCP registry says: Uptime, API and server monitoring with outages, reporting, on-call and status pages. ## Facts - MCP registry: `com.hyperping/hyperping` 1.0.0 - Endpoint: https://api.hyperping.io/v1/mcp (streamable HTTP) - Source: https://github.com/hyperping/mcp-server - Website: https://hyperping.com/docs/mcp - GitHub stars: 1 - Registry entry updated: 2026-07-29 ## Tools - Tools it lists (67, about 18,861 tokens of context, `tools/list` without credentials over MCP 2025-11-25, checked 2026-10-04 22:23 UTC): - `list_monitors` (read-only): Paginated monitors in the project. Optional status filter (up/down/paused/ssl_expiring). - `get_monitor` (read-only): Fetch a single monitor by its UUID. - `create_monitor` (writes): Create a new monitor. Requires name+url; add "port" for port checks, "dns_*" for DNS checks. - `update_monitor` (writes): Patch a monitor. Pass only fields you want to change; others are preserved. - `pause_monitor` (writes): Pause a monitor — no checks run and no alerts fire. Same as update_monitor with paused=true. - `resume_monitor` (writes): Resume a paused monitor. Same as update_monitor with paused=false. - `search_monitors_by_name` (read-only): Case-insensitive substring search across monitor names and URLs. - `get_status_summary` (read-only): Up/down/paused counts plus a list of currently down monitors with the timestamp they went down. - `list_outages` (read-only): Paginated list of outages in the project. Filter by status, type, or search term. - `get_outage` (read-only): Fetch a single outage by UUID, including acknowledgements, description, and root cause. - `get_outage_timeline` (read-only): Full activity timeline for an outage: detection, cross-region verification, alert dispatches, acknowledgement, resolution. - `get_monitor_outages` (read-only): Paginated list of outages scoped to one monitor. Convenience wrapper around list_outages. - `create_outage` (writes): Declare an incident by hand, for a problem no monitor detects. It appears under Incident Management in the dashboard and, with an escalation policy, pages its… - `acknowledge_outage` (writes): Mark an ongoing outage as being handled: repeat alerts stop. Escalation steps still fire on schedule; resolve it or fix the cause to stop them. - `escalate_outage` (writes): Page the next step of the outage's escalation policy now instead of waiting for it. Each call moves one step further. - `resolve_outage` (writes): Resolve an incident declared by hand or a server incident, and send the recovery to the channels it paged. An outage detected on a monitor resolves itself when… - `list_recent_alerts` (read-only): Alert notifications (up/down transitions) over a date range. Defaults to last 30 days. - `get_monitor_uptime` (read-only): Uptime percentage over a date window, aggregated and optionally per day/hour/week/month. - `get_monitor_response_time` (read-only): Response time latency trend over a date window. Returns a per-monitor breakdown — pass all monitors at once in monitor_uuids rather than calling this once per… - `get_monitor_mttr` (read-only): Mean time to resolve (MTTR) per monitor over a date window, in seconds. Already per-monitor — pass all monitors at once in monitor_uuids rather than calling… - `get_monitor_mtta` (read-only): Mean time to acknowledge (MTTA) per monitor over a date window, in seconds. Already per-monitor — pass all monitors at once in monitor_uuids rather than… - `get_monitor_anomalies` (read-only): Anomaly-detection output for a single monitor (flapping, latency spikes, etc.). - `get_monitor_http_logs` (read-only): Recent HTTP probe logs for a monitor, paginated. Useful to diagnose recent check failures. - `list_on_call_schedules` (read-only): All on-call schedules in the project. Each entry typically includes rotation config and current on-call. - `get_on_call_schedule` (read-only): One schedule by UUID with full rotation detail and the linked escalation policies. - `list_escalation_policies` (read-only): All escalation policies in the project. Use to find which monitors route alerts where. - `get_escalation_policy` (read-only): One policy by UUID. Reveals step sequence, linked schedules, and contact channels. - `list_team_members` (read-only): Users on the project, with names and emails. Use to resolve user IDs from schedules/policies. - `get_on_call_now` (read-only): Who is on call, per on-call schedule, right now or at the moment given in `at` (e.g. next Saturday 10:00), computed by the engine that pages people: names,… - `list_integrations` (read-only): All notification integrations in the project (Slack, Telegram, Discord, PagerDuty, OpsGenie, Teams, webhook, etc.). - `get_integration` (read-only): One integration by UUID, with its channel-specific config (channel name, webhook URL, routing, etc.). - `list_status_pages` (read-only): Status pages in the project, 20 per page: UUID, name, public URL, password protection. - `get_status_page` (read-only): One status page with its settings (languages, subscriptions, access) and the services it shows, section by section, with their UUIDs. - `create_status_page` (writes): Create a status page on a hyperping.app subdomain, with sections of monitors, components and servers. It is public as soon as it exists: confirm the name,… - `update_status_page` (writes): Change a status page's name, description, website, look or subscription button. Only the fields passed change. The page is public: confirm the change with the… - `add_status_page_services` (writes): Show monitors, components or servers on a status page, in the section you name (created at the end if the page has none by that name) or the first one.… - `remove_status_page_services` (writes): Take monitors, components or servers off a status page, wherever they appear, groups included. Their settings on the page (display name, description) are lost. - `list_status_page_incidents` (read-only): Incidents published on status pages, newest first, each with its current stage and latest update. For downtime detected on monitors, use list_outages. - `get_status_page_incident` (read-only): One status page incident with every update (newest first, with their UUIDs), its status pages and affected components. - `create_status_page_incident` (writes): Publish an incident on status pages, with its first update. Public, and emailed to subscribers unless notify_subscribers is false: confirm the wording with the… - `add_status_page_incident_update` (writes): Post an update on a status page incident (investigating, identified, update, monitoring, resolved). Public, and sent to subscribers unless notify_subscribers… - `resolve_status_page_incident` (writes): Close a status page incident with a final "resolved" update. Same as add_status_page_incident_update with status "resolved"; refuses an incident that is… - `update_status_page_incident` (writes): Change a status page incident's title, type, status pages or affected services. The pages show the change right away; subscribers are not notified. To tell… - `edit_status_page_incident_update` (writes): Correct the text or stage of an update already posted, e.g. a typo. The page shows the correction; subscribers are not notified again and its date is kept. - `list_maintenance_windows` (read-only): Maintenance windows, 20 per page, with their monitors, status pages, updates and status (upcoming, inprogress, completed). - `get_maintenance_window` (read-only): One maintenance window with its updates and the state of its subscriber notification. - `create_maintenance_window` (writes): Schedule a maintenance window: checks and alerts stop for its monitors during the window, and the status pages you pass announce it. Public once it has status… - `update_maintenance_window` (writes): Reschedule a maintenance window, rename it, change its monitors or status pages, or post a public update on it. The pages show the change; subscribers are not… - `complete_maintenance_window` (writes): End a maintenance window in progress now: checks and alerts resume on its monitors and the status pages show it as completed. - `cancel_maintenance_window` (writes): Cancel a maintenance window that has not started: it is deleted and leaves the status pages. Subscribers already told about it are not told it is cancelled. To… - `search_logs` (read-only): Search the project's logs, newest first. Logs search language (not SQL): free words are ANDed (whole words), "exact phrase", -word to exclude, service:api,… - `get_outage_logs` (read-only): Logs around one outage (incident) of the project: from 15 min before it started to 5 min after it ended. Returns warnings and errors grouped by message… - `summarize_log_errors` (read-only): Groups the project's errors (or warnings) of a time window by message pattern (numbers, ids and IPs normalized), most frequent first: count, share, trend (>1 =… - `list_log_dashboards` (read-only): Log dashboards of the project: name, tags, widget count, template, last update. With `uuid`, one dashboard in detail: its time range, variables, sections and… - `run_log_chart` (read-only): Aggregates the project's logs into a chart and returns a compact summary: per series min/max/avg/last and up to `max_points` points, a table (up to 50 rows) or… - `create_log_dashboard_from_template` (writes): Creates a log dashboard from a ready-made template (overview, errors-patterns, http-access, app-otel, containers, host-syslog, databases, jobs, ingestion-cost,… - `get_outage_checks` (read-only): Region-by-region evidence for one outage ("outage_…" or an incident key like "INC-12"): a verdict — "global" (every checked region failed), "partial" (some… - `find_correlated_outages` (read-only): Other incidents of this project that started within ±window_minutes (default 10, max 60) of an outage (outage_uuid, or incident key) or of a moment (at), each… - `get_recent_changes` (read-only): What changed on a monitor before a moment (default: the outage start) and shortly after: audit-log changes to the monitor and to its escalation policies… - `run_check_now` (read-only): Run the monitor's check right now from each of its regions (20 at most) and return per region: ok, status, total ms, error, failure layer and phase timings in… - `list_healthchecks` (read-only): Cron/heartbeat healthchecks of the project (jobs that ping Hyperping; monitors are list_monitors, servers list_servers): per healthcheck its hc_ uuid, name,… - `get_healthcheck` (read-only): One healthcheck in detail: schedule, grace, state and timing, escalation policy, uptime and downtime over the last 30 days, its last 20 pings (pings are kept… - `list_servers` (read-only): Servers of the project (machines running the Hyperping agent, agt_ uuids; not monitors or healthchecks): per server its name, hostname, status (online, stale =… - `get_server` (read-only): One server in detail: status, last seen, OS, agent version (and whether an update exists), hardware, group, tags, escalation policy; current memory and root… - `list_audit_log` (read-only): Who changed what in the project (the Audit Log page; owners and admins, Business plan): newest first, each event with its time, actor (user name and email, or… - `get_project_report` (read-only): Uptime of every monitor of the project over a period, worst first, in one call: per monitor uptime_pct, downtime (seconds + text), outage count, longest outage… - `get_outage_alerts` (read-only): Who was notified for one outage, and how: every alert delivery attempt (time, channel email/sms/phonecall/slack/teams/webhook/pagerduty/opsgenie/…, recipient:… - How its tools read to an agent (0 errors, 3 warnings, 1 note, about 18,861 tokens; rules at https://www.anchorterminal.com/check.md; not part of the score): - warn TC11 update_status_page: 3 parameters without a description: font, hide_from_search_engines, theme - warn TC21 get_monitor_mttr: described almost the same as get_monitor_mtta (80% of the same words) - warn TC23 server: 67 tools, about 18,284 tokens of definitions - note TC24 server: 67 of 67 tools have no outputSchema - JSON: https://www.anchorterminal.com/api/v1/tools/hyperping.json - Being indexed says nothing about quality, and nobody can pay for it. Ask for a review: https://www.anchorterminal.com/builders/#claiming