MCP Integration

The Model Context Protocol (MCP) server gives AI agents access to your Hyperping project over HTTP. An agent can read monitors, uptime, incidents, on-call and status pages, and act on them: create and pause monitors, declare and resolve incidents, build status pages, publish status page incidents and schedule maintenance. Works with any MCP-compatible client: Claude Desktop, Claude Code, Cursor, Windsurf, mcp-inspector, or custom clients built on the MCP SDK.

Endpoint

URL
https://api.hyperping.io/v1/mcp
Methods
POSTGETDEL
Transport
Streamable HTTP · JSON-RPC 2.0
Auth
Bearer token
Scope
One project per key
Tools
28 read · 21 write

Quick start

  1. Create an API key

    In the dashboard sidebar, open API Keys and create a read_only or read_write key. A read_only key can call the 28 read tools; the 21 write tools need read_write. Keys are strictly scoped to one project.

  2. Add the server to your client

    Paste the mcpServers block below into your Claude Desktop, Cursor, or Windsurf config. Per-client instructions are in Agent setup.

  3. Restart the client

    Restart your client. Start asking questions: "What's down?", "SLA on the API monitor this month?"

Client configuration

Claude Desktop, Cursor, Windsurf, Claude Code. Add to the mcpServers block of your client config:

Streamable HTTP (recommended)JSON
{
  "mcpServers": {
    "hyperping": {
      "type": "http",
      "url": "https://api.hyperping.io/v1/mcp",
      "headers": {
        "Authorization": "Bearer sk_..."
      }
    }
  }
}

Older clients that only speak stdio can bridge via mcp-remote:

stdio bridge via mcp-remoteJSON
{
  "mcpServers": {
    "hyperping": {
      "command": "npx",
      "args": [
        "-y",
        "mcp-remote",
        "https://api.hyperping.io/v1/mcp",
        "--header",
        "Authorization: Bearer sk_..."
      ]
    }
  }
}

Tool reference

The server exposes 49 tools: 28 read and 21 write. Parameters marked ? are optional. UUIDs carry a prefix: monitors mon_, components comp_, servers agt_, status pages sp_, status page incidents inci_, maintenance windows mw_, incidents outage_.

Monitors 7 tools

list_monitors(status?, page?, limit?)read
Paginated list. status is up, down, paused or ssl_expiring (certificate expires within 30 days). limit defaults to 50, 200 at most.
get_monitor(uuid)read
One monitor with its full configuration.
search_monitors_by_name(query)read
Case-insensitive substring match across monitor names and URLs.
create_monitor(name, url, protocol?, port?, http_method?, regions?, check_frequency?, follow_redirects?, timeout?, expected_status_code?, request_body?, request_headers?, required_keyword?, paused?, alerts_wait?, dns_record_type?, dns_nameserver?, dns_expected_answer?, escalation_policy?, group_id?)write

protocol is http (default), icmp, port (with port) or dns (with the dns_* fields). http_method defaults to GET and timeout to 30 seconds, 60 at most. expected_status_code takes 200, "2xx" or "1xx-3xx", and regions: ["*"] checks from every region.

check_frequency is one of 10, 20, 30, 60, 120, 180, 300, 600, 1800, 3600, 21600, 43200 or 86400 seconds; under 30 seconds needs a Business plan. alerts_wait is in minutes: -1 (never), 0 (at once), 1, 2, 3, 5, 10, 30 or 60. Any other value is refused.

update_monitor(uuid, ...fields?)write
Takes the same fields as create_monitor, all optional. Only the fields passed change; the others are kept.
pause_monitor(uuid)write
No checks run and no alerts fire until the monitor is resumed. Same as update_monitor with paused: true.
resume_monitor(uuid)write
Checks and alerts start again. Same as update_monitor with paused: false.

Uptime and reporting 5 tools

get_status_summary()read
Up, down and paused counts, plus the monitors down right now with the time they went down.
get_monitor_uptime(from?, to?, resolution?, monitor_uuids?)read

Uptime percentage over the window, aggregated and per hour, day (default), week or month. from defaults to 30 days ago and to to now.

The answer is broken down per monitor, so pass every monitor in one call: one call per monitor costs about N times more against the rate limit. Omit monitor_uuids for the whole project.

get_monitor_response_time(from?, to?, resolution?, monitor_uuids?)read
Response time trend per monitor, with the same window, grouping and defaults.
get_monitor_mttr(from?, to?, monitor_uuids?)read
Mean time to resolve per monitor, in seconds.
get_monitor_mtta(from?, to?, monitor_uuids?)read
Mean time to acknowledge per monitor, in seconds.

Incidents Incident Management, "outages" in the API 8 tools

list_outages(page?, search?, status?, type?)read

20 per page. search matches a monitor name, URL or domain, or an INC-123 number.

status is all (default), ongoing or resolved. type is all (default), manual (declared by hand) or monitor.

get_outage(uuid)read
One incident with its acknowledgements, description and root cause.
get_outage_timeline(uuid)read
Detection, cross-region verification, alerts dispatched, acknowledgement and resolution. Takes an outage_ UUID or an INC-123 number.
get_monitor_outages(monitor_uuid, page?, status?)read
The incidents of one monitor, 20 per page.
create_outage(description, summary?, severity?, escalation_policy_uuid?)write

Declares an incident by hand, for a problem no monitor detects. With escalation_policy_uuid, the policy's on-call responders are paged; without one, nobody is. Nothing is published on a status page.

description is its title (255 characters at most) and summary the details for responders. severity is one of the project's severity keys (critical, major and minor by default); it defaults to the least severe, and an unknown key is refused.

acknowledge_outage(uuid)write
Marks an ongoing incident as handled: repeat alerts stop. Escalation steps still fire on schedule until the incident is resolved or its cause is fixed.
escalate_outage(uuid)write
Pages the next step of the incident's escalation policy now instead of waiting for it. Each call moves one step further.
resolve_outage(uuid)write
Resolves an incident declared by hand or a server incident, and sends the recovery to the channels it paged. Refused for an incident detected on a monitor, which resolves itself when its checks pass again.

Observability 3 tools

get_monitor_anomalies(uuid)read
Anomaly detection for one monitor: flapping, latency spikes.
get_monitor_http_logs(uuid, page?, limit?, level?)read
Recent probe logs, to diagnose failing checks. level filters on info, warn and error. limit defaults to 50, 200 at most.
list_recent_alerts(from?, to?, resolution?, monitor_uuids?)read
Alert notifications (up and down transitions) over a date range, the last 30 days by default. resolution defaults to day.

On-call 5 tools

list_on_call_schedules()read
Every schedule with its rotation and who is on call now.
get_on_call_schedule(uuid)read
One schedule (sch_) with its full rotation and the escalation policies linked to it.
list_escalation_policies()read
Every escalation policy, to see which monitors route alerts where.
get_escalation_policy(uuid)read
One policy (esc_): its steps, linked schedules and contact channels.
list_team_members()read
Names and emails of the project's users, to resolve the user IDs found in schedules and policies.

Integrations 2 tools

list_integrations()read
Every notification channel: Slack, Telegram, Discord, PagerDuty, Opsgenie, Teams, webhook and more.
get_integration(uuid)read
One integration (int_) with its channel settings: channel name, webhook URL, routing.

Status pages 6 tools

list_status_pages(page?, search?)read
UUID, name, public URL and password protection, 20 per page. search matches the name and hostname.
get_status_page(uuid)read
Settings (languages, subscriptions, access) and the services the page shows, section by section, with their UUIDs.
create_status_page(name, subdomain, description?, website?, language?, theme?, accent_color?, sections?, show_uptime?, show_response_times?)write

Creates a page at <subdomain>.hyperping.app, public as soon as it exists. Paused monitors are refused. Password protection, SSO, a custom domain and a logo are set in the dashboard.

sections is a list of { name, services }, 20 at most, where services are monitor and component UUIDs. language defaults to en and theme to system (or light, dark). show_uptime defaults to true and show_response_times to false.

update_status_page(uuid, name?, description?, language?, website?, theme?, accent_color?, font?, calendar?, auto_refresh?, hide_from_search_engines?, subscriptions?)write

Changes only the fields passed; the rest of the page is kept. An empty description or website removes it, and language names the language of the new description, keeping the other translations.

font is one of system-ui, Lato, Manrope, Inter, Open Sans, Montserrat, Poppins, Roboto, Raleway, Nunito, Merriweather, DM Sans, Work Sans. calendar shows the incident calendar, auto_refresh reloads the page every minute for a wall screen, and subscriptions lets visitors subscribe to updates.

add_status_page_services(uuid, services, section?, show_uptime?, show_response_times?)write
Adds up to 100 monitors and components to the section named, created at the end if the page has none by that name, or to the first section. Services already on the page stay where they are. Paused monitors are refused, as in the dashboard.
remove_status_page_services(uuid, services)write
Takes monitors and components off the page wherever they appear, groups included. Their display name and description on the page are lost.

Status page incidents public, on your status pages 7 tools

list_status_page_incidents(status_page_uuid?, status?, page?)read
Incidents published on status pages, newest first, 20 per page, each with its current stage and latest update. status is all (default), ongoing or resolved.
get_status_page_incident(uuid)read
One incident with its status pages, affected services and every update, newest first, each with its UUID.
create_status_page_incident(title, message, status_pages, type?, status?, affected_components?, notify_subscribers?, language?)write

Publishes the incident and its first update on the pages listed. Subscribers are notified unless notify_subscribers is false. It pages nobody on call; create_outage does that.

type is incident (degraded, default) or outage (down). status is investigating (default), identified or monitoring. title takes 240 characters at most; message allows basic HTML.

add_status_page_incident_update(uuid, message, status, notify_subscribers?, language?)write

Posts an update. Subscribers are notified unless notify_subscribers is false.

status is investigating, identified, update (keeps the current stage), monitoring or resolved. Any stage but resolved reopens a resolved incident.

resolve_status_page_incident(uuid, message, notify_subscribers?, language?)write
Closes the incident with a final resolved update. Refuses an incident that is already resolved, so subscribers never hear it twice.
update_status_page_incident(uuid, title?, language?, type?, add_status_pages?, remove_status_pages?, add_components?, remove_components?)write
Changes the title, type, status pages or affected services. The pages show the change at once; subscribers are not notified. The other translations of the title are kept.
edit_status_page_incident_update(uuid, update_uuid, message?, status?, language?)write
Corrects the text or stage of an update already posted, for example a typo. The page shows the correction; subscribers are not notified again and the update keeps its date.

Maintenance 6 tools

list_maintenance_windows(timeline?, page?)read
upcoming, ongoing or past windows, or all of them newest first, 20 per page. Each comes with its monitors, status pages, updates and status: upcoming, inprogress or completed.
get_maintenance_window(uuid)read
One window with its updates and the state of its subscriber notification.
create_maintenance_window(name, start_date, end_date, monitors, title?, message?, status_pages?, notify?, notify_minutes_before?, language?)write

Checks and alerts stop during the window for its monitors, components and servers. name is internal; title (defaults to name) and message are public on the status pages listed.

Dates need a timezone, for example 2026-10-04T02:00:00Z. notify is none (default), immediate or scheduled; a scheduled notice goes out notify_minutes_before the start (default 60, up to 10080).

update_maintenance_window(uuid, name?, title?, message?, start_date?, end_date?, add_monitors?, remove_monitors?, add_status_pages?, remove_status_pages?, language?)write

Reschedules, renames or retargets a window, or posts a public update on it with message; earlier updates stay. Subscribers are not notified.

A scheduled subscriber notice that has not gone out keeps its lead time when the start moves. At least one monitor must remain.

complete_maintenance_window(uuid)write
Ends a window in progress now: checks and alerts resume and the status pages show it as completed. Refused for a window that has not started or is already over.
cancel_maintenance_window(uuid)write
Deletes a window that has not started and takes it off the status pages. Subscribers already told about it are not told it is canceled. Refused for a window in progress (use complete_maintenance_window) or already over.

Outages and status page incidents

An incident in Incident Management and an incident on a status page are separate records, with separate tools.

Incident (outage_)Status page incident (inci_)
What it isAn internal incident, detected on a monitor or a server, or declared by hand.A write-up published on one or more status pages.
Who sees itYour team, under Incident Management in the dashboard.Anyone who opens the status page.
Who is toldThe on-call responders of its escalation policy.The page's subscribers, by email, SMS, Slack and Teams.
Write toolscreate_outage, acknowledge_outage, escalate_outage, resolve_outagecreate_status_page_incident, add_status_page_incident_update, resolve_status_page_incident, update_status_page_incident, edit_status_page_incident_update

One never creates the other: create_outage publishes nothing, and create_status_page_incident pages nobody. To page your team and tell customers, ask for both. The server's instructions to agents make the same distinction.

Public writes and notifications

Public at once
A new status page, its settings and services, status page incidents and their updates, and maintenance windows announced on a page show to visitors as soon as the call returns.
Notify subscribers
create_status_page_incident, add_status_page_incident_update and resolve_status_page_incident reach the page's subscribers by email, SMS, Slack and Teams unless notify_subscribers is false. create_maintenance_window notifies them only with notify: "immediate" or "scheduled"; the default is "none".
Page on-call
create_outage with an escalation_policy_uuid and escalate_outage page responders. resolve_outage sends the recovery to the channels the incident paged.
No notification
update_status_page_incident, edit_status_page_incident_update and update_maintenance_window change what the pages show without notifying subscribers. cancel_maintenance_window does not tell subscribers who already heard about the window.
Language
Text is filed under the status page's default language. Pass language (two letters, such as fr) when writing in another one. Updates default to the language of the incident title.

Tool annotations

Every tool declares MCP tool annotations. Clients such as Claude Code read them to decide which calls run freely and which ask you first. They are hints for the client: the server enforces read-only keys and project scope on its own.

readOnlyHint
true on the 28 read tools, false on the 21 write tools.
destructiveHint
The write overwrites or removes something that exists, such as a monitor setting, a service on a page or a maintenance window.
idempotentHint
Calling it again with the same arguments changes nothing more, as with pausing a monitor or resolving an incident.
openWorldHint
The write reaches people outside the dashboard: status page visitors, subscribers or on-call responders. false on every read tool.

The 21 write tools declare these values:

Write tooldestructiveHintidempotentHintopenWorldHint
Monitors
create_monitor---
update_monitor-
pause_monitor--
resume_monitor--
Incidents
create_outage--
acknowledge_outage--
escalate_outage--
resolve_outage-
Status pages
create_status_page--
update_status_page
add_status_page_services-
remove_status_page_services
Status page incidents
create_status_page_incident--
add_status_page_incident_update--
resolve_status_page_incident-
update_status_page_incident
edit_status_page_incident_update
Maintenance
create_maintenance_window--
update_maintenance_window-
complete_maintenance_window-
cancel_maintenance_window

Security

Project scope
API keys are bound to exactly one project in the database (FK-constrained). req.projectuuid is resolved server-side from the key. Client headers cannot override.
Row-level isolation
Every read and write is scoped to the key's project. The controllers filter by projectuuid, and where a tool goes through a dashboard controller or a status page's settings (status page incident edits, status page settings and services), it first checks the incident, update, status page, monitor and component UUIDs against the project. Cross-project access returns an error, never data, and the UUIDs an agent passes to a write tool are checked before anything is published.
Read-only enforcement
Every write tool refuses a read_only key with a clear error. Enforced at the tool handler, not at the route, and the attempt is recorded in the audit log.
Role gating
Session-auth endpoints (reporting, schedules, on-call, integrations) run hasAccountRole with the user's actual project role. viewer keys cannot invoke write-adjacent endpoints.
Revocation
Deactivating a key in the dashboard blocks the next MCP call immediately. No TTL to wait out.

Audit log

MCP writes show up in the project's audit logs like REST writes made with an API key. Audit logs are available on the Business plan.

Write succeeds
An ApiKeyWriteAction entry with the API key as its target, as for a REST write made with that key.
Write refused
A read_only key that calls a write tool leaves an ApiKeyPermissionDenied entry under that key.
Reads
Reads leave no audit log entry.
Legacy tokens
Legacy project tokens have no API key to log against, so their writes leave no ApiKeyWriteAction entry, as on REST. The entries a resource records on its own, such as CreateMaintenance, are still written.

Not available via MCP

⚠Scoped out by design
  • Deletion of monitors, status pages, status page incidents and their updates, and incidents declared by hand. Delete them from the dashboard or the REST API, or pause a monitor instead. The one exception is cancel_maintenance_window, which deletes a maintenance window that has not started.
  • Status page subscribers, password protection, SSO, custom domains and logos. Recurring maintenance: create_maintenance_window schedules one window per call.
  • Billing, API key management, SSO settings, teammate invites, password reset.

Query patterns

Ask in plain language; the agent chains the calls. The IDs below are examples.

Pattern 01

Find who is on call for a monitor

"Who's on call for the checkout monitor right now?"

  1. search_monitors_by_name with query: "checkout", then get_monitor to read its escalation policy.
  2. get_escalation_policy for the linked schedule UUIDs.
  3. get_on_call_schedule for the user on call now, and list_team_members for their name and email.
Pattern 02

Declare an incident and page on-call

"Payments are failing at checkout. Open a critical incident and page the payments team."

  1. list_escalation_policies to find the policy, here esc_payments.
  2. As the server instructs, the agent shows you the title, severity and policy, and waits for your go.
  3. create_outage with description: "Payments failing at checkout", severity: "critical" and escalation_policy_uuid: "esc_payments". The incident appears under Incident Management and the on-call responders are paged.
Pattern 03

Acknowledge, then resolve

"I'm on it. Stop the alerts, and close the incident once payments are back."

  1. list_outages with status: "ongoing" to find outage_payments.
  2. acknowledge_outage: repeat alerts stop. If nobody answers, escalate_outage pages the next step now.
  3. resolve_outage once the fix is out: the recovery goes to the channels that were paged. An incident detected on a monitor closes itself when checks pass again.
Pattern 04

Tell customers checkout is down

"Post on our status page that checkout is down and we're investigating."

  1. list_status_pages to pick sp_acme, and get_status_page for the UUID of the checkout service, mon_checkout.
  2. The agent drafts the title and message, shows them to you and waits for your go.
  3. create_status_page_incident with status_pages: ["sp_acme"], type: "outage" and affected_components: ["mon_checkout"].
  4. Later, add_status_page_incident_update with status: "monitoring", then resolve_status_page_incident.
Pattern 05

Stand up a status page with sections

"Create a status page for Acme with an API section and a Checkout section."

  1. list_monitors for the UUIDs, here mon_api and mon_checkout.
  2. The agent confirms the name, the address and the services with you: the page is public as soon as it exists.
  3. create_status_page with name: "Acme Status", subdomain: "acme" and sections: [{ name: "API", services: ["mon_api"] }, { name: "Checkout", services: ["mon_checkout"] }]. The page goes live at acme.hyperping.app.
  4. Later, add_status_page_services with services: ["comp_cdn"] and section: "Infrastructure" adds a section at the end.
Pattern 06

Fix a typo in a posted update

"The last update on the checkout incident says 'resolvd'. Fix it without emailing everyone again."

  1. get_status_page_incident on inci_checkout to find the update and its UUID.
  2. edit_status_page_incident_update with that update_uuid and the corrected message. The page shows the fix; subscribers are not notified again and the update keeps its date.
Pattern 07

Extend or cancel a maintenance

"The database upgrade needs 30 more minutes." or "Cancel Sunday's maintenance."

  1. list_maintenance_windows with timeline: "ongoing" or "upcoming" to find mw_db_upgrade.
  2. To extend: update_maintenance_window with a later end_date, such as "2026-10-04T04:30:00Z", and message: "The work is extended by 30 minutes.". The page shows the update; subscribers are not notified.
  3. To cancel one that has not started: cancel_maintenance_window. To end one in progress early: complete_maintenance_window.

Limits

Pagination
Up to 200 monitors per page. Incidents, status pages, status page incidents and maintenance windows come 20 per page.
Batch size
Up to 100 UUIDs per services list and per add_* or remove_* list, and 20 sections per new status page.
Rate limit
Per project: 60 tool calls a minute and 600 an hour, plus 5 / 20 for initialize. Calls also count toward the REST API quota. Over the limit, the JSON-RPC error carries retry_after_seconds.
Response size
Large windows (for example, 30-day alert history) can be capped by narrowing from / to.

Next steps