net.hookpulse/hookpulse

Measured conclusion: Deep-tested. L2 outcome: tools_ok.

Dead-man switch for cron and webhooks: ingest URL, miss detection, alerts and a status feed.

Add to your agent

Copy this into your MCP client config:

{
  "mcpServers": {
    "hookpulse": {
      "url": "https://hookpulse.net/mcp",
      "transport": "streamable-http"
    }
  }
}

Measured tools (24)

• api_index read-only

  Full index of the HookPulse API.

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• health read-only

  Liveness.

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• create_guest

  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.

  Hints: read-only no · destructive no · idempotent no · open-world no

• list_endpoints read-only

  Lists the guest's/session's endpoints.

  Parameters:

  • guest_token (required) — string

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• create_endpoint

  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.

  Parameters:

  • guest_token (required) — string
  • name (required) — string — how you will recognise the routine in an alert; required, trimmed, max 80 chars, punctuation alone is rejected
  • tz — string — IANA time zone for cron, default UTC
  • cron — string — five-field cron, e.g. 0 3 * * *
  • tags — array — up to 8 tags to group the monitor; lower-cased, [a-z0-9._-], max 32 chars each
  • alert_to — string — E-mail to alert on a miss; without it, the account is alerted.
  • alert_url — string — Public HTTPS URL that receives a POST on a miss (Slack Incoming, Discord, n8n).
  • grace_sec — number — tolerance after the scheduled time, default 90, min 30
  • interval_sec — number — Tolerated silence, in seconds.
  • paused_until — string — maintenance window end (UTC ISO), max 30 days ahead
  • alert_repeat_sec — number — gap before the same incident alerts again, 3600..2592000; null keeps the 86400 default
  • max_duration_sec — number — ceiling for an open run in seconds, 60..86400; null or 0 turns it off

  Hints: read-only no · destructive no · idempotent no · open-world yes

• create_site

  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.

  Parameters:

  • guest_token (required) — string
  • check (required) — object — url (http/https, public; required), method (GET or HEAD), expect_status (200-399 by default, a range a-b or one code), keyword (text that must be on the page), timeout_ms (1000..30000)
  • name — string — how you will recognise the site in an alert; default: its host
  • tags — array — Up to 8 tags to group this monitor: lower-case letters, digits, `.`, `_` and `-`, at most 32 characters each. A comma-separated string works too. We lower-case and de-duplicate, so `Prod` and `prod` are the same tag.
  • alert_to — string — E-mail to alert on a miss; without it, the account is alerted.
  • alert_url — string — Public HTTPS URL that receives a POST on a miss (Slack Incoming, Discord, n8n).
  • interval_sec — number — seconds between checks, default 300
  • paused_until — string — maintenance window end (UTC ISO), max 30 days ahead

  Hints: read-only no · destructive no · idempotent no · open-world yes

• check_site

  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.

  Parameters:

  • id (required) — string — ID of the site monitor, from `Monitor.id`.
  • guest_token (required) — string

  Hints: read-only no · destructive no · idempotent no · open-world yes

• list_sites read-only

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

  Parameters:

  • guest_token (required) — string

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• import_crontab

  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.

  Parameters:

  • guest_token (required) — string
  • crontab (required) — string — the crontab text
  • apply — string — "1" to create the monitors

  Hints: read-only no · destructive no · idempotent no · open-world no

• get_endpoint read-only

  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.

  Parameters:

  • id (required) — string — Monitor ID, from `Monitor.id`.
  • token — string — endpoint token (query)
  • guest_token — string

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• delete_endpoint destructive

  Removes the owner's endpoint.

  Parameters:

  • guest_token (required) — string
  • id (required) — string — ID of the monitor to deactivate.

  Hints: read-only no · destructive yes · idempotent yes · open-world no

• list_events read-only

  Latest ingest pings.

  Parameters:

  • id (required) — string — ID of the monitor.
  • token — string — Monitor token, alternative to the `X-Hook-Token` header.
  • guest_token — string

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• ping_ingest read-only

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

  Parameters:

  • id (required) — string — Monitor ID, from `Monitor.ingest_url`.

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• signal_start read-only

  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.

  Parameters:

  • id (required) — string — Monitor ID, from `Monitor.ingest_url`.

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• signal_fail read-only

  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.

  Parameters:

  • id (required) — string — Monitor ID, from `Monitor.ingest_url`.

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• signal_exit_code read-only

  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.

  Parameters:

  • id (required) — string — Monitor ID, from `Monitor.ingest_url`.
  • exit_code (required) — number — Exit status, 0 to 255. Outside that range it is a 400.

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• ingest_key read-only

  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.

  Parameters:

  • guest_token — string

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• ingest_key_rotate destructive

  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.

  Parameters:

  • guest_token — string

  Hints: read-only no · destructive yes · idempotent yes · open-world no

• ping_slug read-only

  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.

  Parameters:

  • ingestKey (required) — string — Ingest key, from `GET /api/ingest-key`.
  • slug (required) — string — Name of the job; it becomes the monitor name.

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• signal_slug read-only

  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.

  Parameters:

  • ingestKey (required) — string — Ingest key, from `GET /api/ingest-key`.
  • slug (required) — string — Name of the job; it becomes the monitor name.
  • signal (required) — string — start, fail, or the exit code 0 to 255

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• status_feed_url read-only

  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.

  Parameters:

  • guest_token — string

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• status_feed_rotate destructive

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

  Parameters:

  • guest_token — string

  Hints: read-only no · destructive yes · idempotent yes · open-world no

• list_templates read-only

  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.

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• contact

  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.

  Parameters:

  • name (required) — string — What to call the person writing.
  • email (required) — string — Where to reply.
  • message (required) — string — What you want to say.
  • fuso — string — Consulting: the IANA time zone, such as `America/New_York`.
  • pais — string — Consulting: the country of the person asking.
  • site — string — Website of who is proposing.
  • tipo — string — Proposal: `patrocinio`, `parceria`, `anuncio` or `consultoria`. Turns on the fields below.
  • prazo — string — Consulting: when to start (`agora`, `1_mes`, `1_3_meses` or `explorando`).
  • espaco — array — Placement ids from `GET /api/partners`, up to 6.
  • duracao — string — Exposure in days: `30`, `90` or `365`.
  • empresa — string — Who is proposing, when it is a company.
  • formato — string — Consulting: `projeto` (per scope), `mensal` (monthly) or `assessoria` (advisory).
  • projeto — string — Consulting: the kind of project (`llm_privado`, `voz`, `dados_sensiveis`, `gpu`, `integracao` or `outro`).
  • horarios — array — Consulting: up to 3 times for the call, `YYYY-MM-DDTHH:MM` in that time zone.
  • whatsapp — string — Optional reply number with country code, such as +5561999999999.
  • orcamento — string — Advertising: `ate_100`, `100_500`, `500_2000`, `2000_mais` or `a_combinar`. Consulting, in US dollars: `ate_2000`, `2000_5000`, `5000_10000`, `10000_mais` or `nao_sei`.
  • pagamento — string
  • prefer_whatsapp — boolean — Request a WhatsApp reply. Requires whatsapp.

  Hints: read-only no · destructive no · idempotent no · open-world no

Publisher website Repository

Measured by MCPYP probing. Untested fields are omitted, never estimated. Listing is always free; MCPYP never proxies calls or stores user tokens.