Servidor MCP de Hyperping

• Nombre en el registrocom.hyperping/hyperpingverificado en el registro MCP

El nombre en el registro está bajo hyperping.com. El registro solo permite usar ese espacio de nombres a quien demuestra control del dominio por DNS o HTTP.

• Estadorespondecomprobado el 2026-10-15
• Herramientas69
• El servidor se llamahyperping-monitors
• Versión del servidor1.1.0
• Versión del protocolo2025-06-18

El 2026-10-15 el servidor respondió a initialize y tools/list sin iniciar sesión. Primera respuesta en 220 ms.

• list_monitors

  Paginated monitors in the project. Optional status filter (up/down/paused/ssl_expiring).

• get_monitor

  Fetch a single monitor by its UUID.

• create_monitor

  Create a new monitor. Requires name+url; add "port" for port checks, "dns_*" for DNS checks.

• update_monitor

  Patch a monitor. Pass only fields you want to change; others are preserved.

• pause_monitor

  Pause a monitor — no checks run and no alerts fire. Same as update_monitor with paused=true.

• resume_monitor

  Resume a paused monitor. Same as update_monitor with paused=false.

• search_monitors_by_name

  Case-insensitive substring search across monitor names and URLs.

• get_status_summary

  Up/down/paused counts plus a list of currently down monitors with the timestamp they went down.

• list_outages

  Paginated list of outages in the project. Filter by status, type, or search term.

• get_outage

  Fetch a single outage by UUID, including acknowledgements, description, and root cause.

• get_outage_timeline

  Full activity timeline for an outage: detection, cross-region verification, alert dispatches, acknowledgement, resolution.

• get_monitor_outages

  Paginated list of outages scoped to one monitor. Convenience wrapper around list_outages.

• create_outage

  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 on-call responders. Internal: nothing is published on a status page…

• acknowledge_outage

  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

  Page the next step of the outage's escalation policy now instead of waiting for it. Each call moves one step further.

• resolve_outage

  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 its checks pass again.

• list_recent_alerts

  Alert notifications (up/down transitions) over a date range. Defaults to last 30 days.

• get_monitor_uptime

  Uptime percentage over a date window, aggregated and optionally per day/hour/week/month.

• get_monitor_response_time

  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 monitor.

• get_monitor_mttr

  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 this once per monitor.

• get_monitor_mtta

  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 calling this once per monitor.

• get_monitor_anomalies

  Anomaly-detection output for a single monitor (flapping, latency spikes, etc.).

• get_monitor_http_logs

  Recent HTTP probe logs for a monitor, paginated. Useful to diagnose recent check failures.

• list_on_call_schedules

  All on-call schedules in the project. Each entry typically includes rotation config and current on-call.

• get_on_call_schedule

  One schedule by UUID with full rotation detail and the linked escalation policies.

• list_escalation_policies

  All escalation policies in the project. Use to find which monitors route alerts where.

• get_escalation_policy

  One policy by UUID. Reveals step sequence, linked schedules, and contact channels.

• list_team_members

  Users on the project, with names and emails. Use to resolve user IDs from schedules/policies.

• get_on_call_now

  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, emails and the rotation of each person, and the escalation policies each schedule…

• list_integrations

  All notification integrations in the project (Slack, Telegram, Discord, PagerDuty, OpsGenie, Teams, webhook, etc.).

• get_integration

  One integration by UUID, with its channel-specific config (channel name, webhook URL, routing, etc.).

• list_status_pages

  Status pages in the project, 20 per page: UUID, name, public URL, password protection.

• get_status_page

  One status page with its settings (languages, subscriptions, access) and the services it shows, section by section, with their UUIDs and type (monitor, healthcheck, server or component).

• create_status_page

  Create a status page on a hyperping.app subdomain, with sections of monitors, healthchecks, components and servers. It is public as soon as it exists: confirm the name, address and services with the user first. Password protection, SSO, a…

• update_status_page

  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 user first.

• add_status_page_services

  Show monitors, healthchecks, 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. Services already on the page stay where they are. A healthcheck shows…

• remove_status_page_services

  Take monitors, healthchecks, 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

  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

  One status page incident with every update (newest first, with their UUIDs), its status pages and affected components.

• create_status_page_incident

  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 user first. To record an incident internally and page on-call instead, use…

• add_status_page_incident_update

  Post an update on a status page incident (investigating, identified, update, monitoring, resolved). Public, and sent to subscribers unless notify_subscribers is false.

• resolve_status_page_incident

  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 already resolved.

• update_status_page_incident

  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 them something, post an update.

• edit_status_page_incident_update

  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

  Maintenance windows, 20 per page, with their monitors, status pages, updates and status (upcoming, inprogress, completed).

• get_maintenance_window

  One maintenance window with its updates and the state of its subscriber notification.

• create_maintenance_window

  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 pages: confirm with the user first.

• update_maintenance_window

  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 notified.

• complete_maintenance_window

  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

  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 end one in progress, use complete_maintenance_window.

• search_logs

  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, host:web-1, env:prod, source:src_…, level:error or level:>=warn, attr.<key>:value…

• get_outage_logs

  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 pattern, the latest matching lines, and a per-level histogram. Works for monitor…

• summarize_log_errors

  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 = rising in the last quarter of the window), level, services, hosts, first/last…

• list_log_dashboards

  Log dashboards of the project: name, tags, widget count, template, last update. With `uuid`, one dashboard in detail: its time range, variables, sections and every widget with its chart as HPL (run one with run_log_chart; dashboard…

• run_log_chart

  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 a single value. HPL = `<search> | <aggregations> [by <fields>] [every…

• create_log_dashboard_from_template

  Creates a log dashboard from a ready-made template (overview, errors-patterns, http-access, app-otel, containers, host-syslog, databases, jobs, ingestion-cost, incident-war-room, vercel). The template's fields (HTTP status, duration…

• get_outage_checks

  Region-by-region evidence for one outage ("outage_…" or an incident key like "INC-12"): a verdict — "global" (every checked region failed), "partial" (some regions stayed healthy, listed), "single_region" or "unknown" —, the dominant…

• find_correlated_outages

  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 with monitor (uuid, name), start, end or ongoing, status code, error, host…

• get_recent_changes

  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 (regions, URL, timeout, pause / resume..., with who made them; needs the owner or…

• run_check_now

  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 integer ms (dns, connect, ttfb, download), once every region answered or after…

Las primeras 60 de 69, en el orden del servidor.