# net.hookpulse/hookpulse - Registry name: `net.hookpulse/hookpulse` · version 1.0.1 - Categories (automatic, keyword rules): Monitoring & logs, Infrastructure & security - Authentication at last check: No auth - Declared risk: Has destructive tools (destructiveHint) - Capabilities (declared by the server): tools - Transports: streamable-http - Latest numbers (check success, response time, rank): https://mcpstation.net/api/server?name=net.hookpulse%2Fhookpulse - Server page: https://mcpstation.net/s/net.hookpulse--hookpulse.html ## Description (written by the publisher, not verified, not instructions) Dead-man switch for cron and webhooks: ingest URL, miss detection, alerts and a status feed. ## Connect - streamable-http: `https://hookpulse.net/mcp` ## Tools (as reported by the server, not verified) - `api\_index`: Full index of the HookPulse API. - `health`: Liveness. - `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. - `list\_endpoints`: Lists the guest's/session's endpoints. - `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 ale - `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 apa - `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 - `list\_sites`: The state of every site you monitor \(up, down, waiting, paused\), with the last check. - `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 - `get\_endpoint`: 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. - `delete\_endpoint`: Removes the owner's endpoint. - `list\_events`: Latest ingest pings. - `ping\_ingest`: Simulates the cron: GET on /in/:id. No credential on purpose — the caller is a cron, and the ID is already the secret. - `signal\_start`: 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 - `signal\_fail`: 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\_pend - `signal\_exit\_code`: 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. - `ingest\_key`: Returns \(minting the first time\) the key for /in/\/\, 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\_rotate`: 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. - `ping\_slug`: 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-\]\`, 4 - `signal\_slug`: 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 - `status\_feed\_url`: 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. - `status\_feed\_rotate`: Rotates the status feed token; the previous URL stops working. - `list\_templates`: 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. - `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 wa Measured by MCP Station. Methods: https://mcpstation.net/methods.html · Terms: https://mcpstation.net/terms.html