Hookpulse MCP server

• api_indexFree

  Full index of the HookPulse API.

• check_siteFree

  Check a site monitor now. One call every 10 seconds per destination host. One call every 10 seconds per destination host, for everyone: the button cannot hammer a site. The first state of a new site comes from here, without an alert — you are looking at it. After that, the state and the alerts come from the check that runs every minute.

• contactwrite actionFree

  Write to the people behind the product: a question, or a sponsorship/partnership/advertising proposal. One route for a question and for a sponsorship, partnership or ad proposal (`tipo`, with the placements of `GET /api/partners`). One message every 10 seconds per network: one that arrives sooner waits its turn and then goes out — no error. The message reaches the team by e-mail, with `email` as the reply address. For voice, send multipart/form-data: `dados` is this JSON (up to 32 KiB), and `audio` is one WebM, Ogg or M4A audio file (up to 2 MB). Audio can replace message. The browser records up to two minutes. Audio is attached to the owner's e-mail.

• create_endpointwrite actionFree

  Create a monitor for a routine. Use cron, tz and grace_sec for a schedule, or interval_sec for a fixed check-in interval. Set max_duration_sec to detect an open run that exceeds its time limit. With `check` the monitor is a site: HookPulse calls `check.url` every `interval_sec` (default 300) and alerts when it goes down — two failed checks in a row, one minute apart, from a server whose own connection is proven — and when it answers again. `{"check":{"url":"https://example.com/"}}` is enough; the name defaults to the host. A site has no `cron`, no `max_duration_sec` and no ingest URL. This response is the only one that shows the monitor's `token` and the `templates` — keep them. A miss alerts at most once per 24h — or per `alert_repeat_sec`, or per interval, whichever is longer. Send `cron`+`tz`+`grace_sec` instead of `interval_sec` for a real schedule: a 03:00 backup is late at 03:01:30, not 24 hours later. `max_duration_sec` catches the other failure: a run that starts and hangs, which plain silence detection only notices at the next scheduled time.

• create_guestwrite actionFree

  Creates a guest token hp_… Keep the token: without it there is no way back to the monitors, unless you have already tied them to an e-mail.

• create_sitewrite actionFree

  Monitor a website: HookPulse calls check.url every interval_sec (default 300) and alerts when it goes down and when it is back. With `check` the monitor is a site: HookPulse calls `check.url` every `interval_sec` (default 300) and alerts when it goes down — two failed checks in a row, one minute apart, from a server whose own connection is proven — and when it answers again. `{"check":{"url":"https://example.com/"}}` is enough; the name defaults to the host. A site has no `cron`, no `max_duration_sec` and no ingest URL. This response is the only one that shows the monitor's `token` and the `templates` — keep them. A miss alerts at most once per 24h — or per `alert_repeat_sec`, or per interval, whichever is longer. Send `cron`+`tz`+`grace_sec` instead of `interval_sec` for a real schedule: a 03:00 backup is late at 03:01:30, not 24 hours later. `max_duration_sec` catches the other failure: a run that starts and hangs, which plain silence detection only notices at the next scheduled time.

• delete_endpointwrite actionFree

  Removes the owner's endpoint.

• get_endpointFree

  Status of one endpoint (use the endpoint token if you have it). The monitor token only reads: it lets you put the state on a third-party dashboard without handing over the owner's credential. With a schedule it is here that `next_expected_at` says when the next run is due.

• healthFree

  Liveness.

• import_crontabFree

  Reads a crontab and proposes one monitor per scheduled line. Without apply=1 nothing is written; the proposal says what was ignored and why. Passwords in the command are redacted. The body is the crontab itself, as `text/plain`. Without `?apply=1` **nothing is written**: you get the proposal — what would become a monitor, what was ignored and why, and what still fits in the free tier. With `apply=1` it is all or nothing, under the same rules as `POST /api/endpoints`. Comments, variables and `@reboot` are ignored (there is no way to know when to expect a reboot); `@daily` and friends become the equivalent expression. The command becomes the monitor name, with passwords and tokens redacted first — the name travels in the alert e-mail, in the public dashboard and in the badge.

• ingest_keyFree

  Returns (minting the first time) the key for /in/<key>/<slug>, where a ping creates its own monitor inside the free tier. Instruments a whole fleet with no setup call per job. One key per owner. The key survives signing in: the crontab you deployed keeps working.

• ingest_key_rotateFree

  Rotates the ingest key; the previous one stops creating monitors. Existing ones keep working. Monitors already created keep working — rotating only revokes the power to create new ones.

• list_endpointsFree

  Lists the guest's/session's endpoints.

• list_eventsFree

  Latest ingest pings.

• list_sitesFree

  The state of every site you monitor (up, down, waiting, paused), with the last check.

• list_templatesFree

  Ingest snippets and the JSON HookPulse POSTs on a miss. It exists so nobody guesses the alert format: `miss_json` and `recovery_json` here are the same bodies that arrive at your `alert_url`. Slack and Discord receive only the field they read.

• ping_ingestFree

  Simulates the cron: GET on /in/:id. No credential on purpose — the caller is a cron, and the ID is already the secret.

• ping_slugwrite actionFree

  Create a monitor on its first check-in. The same slug uses the same monitor. A rejected creation writes no monitor or event. The slug becomes the monitor name and its identity: the same slug always means the same monitor, so a retry never creates a second one. Normalised to lowercase, `[a-z0-9-]`, 40 chars. Works by GET or POST.

• signal_exit_codeFree

  The shell exit status: 0 behaves like a ping, 1-255 record the code as a failure. `curl -fsS $ORIGIN/in/ID/$?` at the end of a script is the whole integration. `0` behaves exactly like a plain ping; 1 to 255 record the code and leave the failure for the cron.

• signal_failFree

  Record a failed run. The next five-minute check sends the alert with reason fail. The monitor's alert_repeat_sec controls repeated alerts; the default is 24 hours. Failing is not proof of life either: the clock keeps running. The ingest never sends e-mail and never calls out — it records `alert_pending` and the cron turns it into an alert with `reason: "fail"` within 5 minutes, under the same one-per-24h cap. Works by GET or POST.

• signal_slugwrite actionFree

  Send start, fail or an exit code by name, with the ingest key; the first signal of a new name creates its monitor. The same signals as `/in/:id/start`, `/in/:id/fail` and `/in/:id/:exit_code`, for a fleet that only knows the ingest key: the job sends its name, not the monitor id. The first signal of a new name creates the monitor, with the same rules and the same `cron`, `tz` and `grace_sec` as the plain ping by name.

• signal_startFree

  Says the run STARTED. Does not clear the dead-man clock: a routine that starts and hangs still becomes a miss. The next success records the duration. `start` is not proof of life: it does not move `last_event_at` and does not clear the miss counter, so a routine that starts and hangs still becomes a miss at the right time. The next success closes the run and records `last_duration_ms` — pass `?rid=` on both ends when runs can overlap, or the duration is measured against the wrong start. With `max_duration_sec` set on the monitor, a run left open past that ceiling alerts with `reason: "too_long"` on the next 5-minute check. Works by GET or POST.

• status_feed_rotateFree

  Rotates the status feed token; the previous URL stops working.

• status_feed_urlFree

  Public URL (JSON and RSS) with the status of all the owner's endpoints. The feed token only reads status: it does not create, change or delete. Whoever has the link sees the dashboard — treat it as a secret.

• –Code scanremote-only server, no package to scann/a
• Live reliabilityremote reachable in 1646ms20/20
• Tool poisoning24 tool descriptions checked15/15
• Auth qualityopen endpoint exposes 7 write-action tools with no auth3/15
• Maintenancelast push 2 days ago15/15
• Maintainer identityendpoint served from the registry-verified namespace domain8/10

Safety score

81/100

higher than 62% of 48,243 servers

Tools

24

the typical server has 7

Tools that change things

29%

typical: 0%. Fewer write tools means less an agent can break

Uptime

100%

of our recent checks; the typical remote server answers 100%

Response time

595 ms

faster than 27% of 30,027 servers

Grade history

• 2026-10-16restoreC → Bscore 81: Write-action tools reachable without authentication

Hookpulse: common questions

Is Hookpulse MCP server safe?

Mostly: it is graded B (81/100). Read the Hookpulse safety report

How do I install Hookpulse?

It runs remotely at hookpulse.net. Add it to Claude Code, Cursor, VS Code or Claude Desktop with the snippets above, or call it through the mcp.market gateway without installing anything.

Does Hookpulse need an API key?

Not as far as the registry entry and our scan can tell: no credentials are declared or required.

Is Hookpulse maintained?

The last commit was 22 days ago (2026-10-15). The latest release is v1.0.1.

Is Hookpulse up?

100% of our last 28 checks got an answer. We check remote servers about four times a day.

What can I use instead of Hookpulse?

Servers from other publishers that do the same job: Netdata MCP server.

How does Hookpulse compare with other MCP servers?

safety score 81/100 (higher than 62% of 48,243 servers); tools 24 (the typical server has 7); tools that change things 29% (typical: 0%. Fewer write tools means less an agent can break). Full comparison.