Dead-man switch for cron and webhooks: ingest URL, miss detection, alerts and a status feed.
Scored across 41 tools
The surface models a complex three-layer hierarchy (environment → collection → device input) plus monitors, signals, and ingest keys, and tools like create_environment/create_collection/create_device_input or the many list_* variants overlap conceptually. The unusually detailed descriptions do help an agent separate them, but boundaries remain fuzzy in places (e.g. get_collection_series vs get_device_input_batch vs list_device_input_history).
Nearly all names are snake_case verb_noun (create_endpoint, list_collections, delete_device_input, etc.), which is predictable and readable. Deviations exist in noun-only resources (billing, pricing, health, contact, api_index) and noun-first names (ingest_key, ingest_key_rotate, status_feed_url, ping_slug), so the convention is consistent but not airtight.
41 tools is heavy and sits firmly above the 25+ threshold, spanning monitoring, device collection, ingest, and status feeds. While the domain is genuinely broad, the count makes the set hard to navigate and there is noticeable granularity (e.g. separate rotate tools, many signal_* and ping_* variants).
Coverage is strong: full CRUD for endpoints, environments, collections and device inputs, plus rotation, ingest, status feeds, templating and crontab import. Only minor lifecycle gaps appear (no explicit delete/update for guest tokens or account-level operations), easily worked around.
Full index of the HookPulse API.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ID of the site monitor, from `Monitor.id`. | |
| guest_token | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds real behavioral context beyond the annotations: a hard rate limit (one call per 10 seconds per destination host, globally shared), the fact that this call does NOT emit an alert, and that it produces the first state of a new site. This explains why the annotations mark it non-idempotent and non-read-only for what sounds like a read-style 'check'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose is front-loaded, but the sentence 'One call every 10 seconds per destination host' is duplicated verbatim, which is pure waste. The remaining sentences earn their place but the repetition weakens the structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the trigger semantics, rate limit, and alert behavior well for a 2-param tool with no output schema. However, it leaves the required guest_token (auth) unexplained despite low schema coverage, which is a gap an agent must resolve elsewhere.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 50%, and guest_token has no schema description. The description says nothing about either parameter, so it does not compensate for the undocumented required guest_token and adds no meaning beyond the schema's 'id' entry.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource with an on-demand qualifier: 'Check a site monitor now.' It is clearly distinguishable from create_site/list_sites/delete_endpoint siblings, though it never names any sibling explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied rather than stated: the tool is for forcing an immediate check, and the description contrasts it with the automatic minute-interval check. There is no explicit when-not guidance or routing to an alternative tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| fuso | No | Consulting: the IANA time zone, such as `America/New_York`. | |
| name | Yes | What to call the person writing. | |
| pais | No | Consulting: the country of the person asking. | |
| site | No | Website of who is proposing. | |
| tipo | No | Proposal: `patrocinio`, `parceria`, `anuncio` or `consultoria`. Turns on the fields below. | |
| Yes | Where to reply. | ||
| prazo | No | Consulting: when to start (`agora`, `1_mes`, `1_3_meses` or `explorando`). | |
| espaco | No | Placement ids from `GET /api/partners`, up to 6. | |
| duracao | No | Exposure in days: `30`, `90` or `365`. | |
| empresa | No | Who is proposing, when it is a company. | |
| formato | No | Consulting: `projeto` (per scope), `mensal` (monthly) or `assessoria` (advisory). | |
| message | Yes | What you want to say. | |
| projeto | No | Consulting: the kind of project (`llm_privado`, `voz`, `dados_sensiveis`, `gpu`, `integracao` or `outro`). | |
| horarios | No | Consulting: up to 3 times for the call, `YYYY-MM-DDTHH:MM` in that time zone. | |
| No | Optional reply number with country code, such as +5561999999999. | ||
| orcamento | No | 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 | No | ||
| prefer_whatsapp | No | Request a WhatsApp reply. Requires whatsapp. |
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.
| Name | Required | Description | Default |
|---|---|---|---|
| tz | No | IANA time zone for cron, default UTC | |
| cron | No | five-field cron, e.g. 0 3 * * * | |
| name | Yes | how you will recognise the routine in an alert; required, trimmed, max 80 chars, punctuation alone is rejected | |
| tags | No | up to 8 tags to group the monitor; lower-cased, [a-z0-9._-], max 32 chars each | |
| alert_to | No | E-mail to alert on a miss; without it, the account is alerted. | |
| alert_url | No | Public HTTPS URL that receives a POST on a miss (Slack Incoming, Discord, n8n). | |
| grace_sec | No | tolerance after the scheduled time, default 90, min 30 | |
| guest_token | Yes | ||
| interval_sec | No | Tolerated silence, in seconds. | |
| paused_until | No | maintenance window end (UTC ISO), max 30 days ahead | |
| alert_repeat_sec | No | gap before the same incident alerts again, 3600..2592000; null keeps the 86400 default | |
| max_duration_sec | No | ceiling for an open run in seconds, 60..86400; null or 0 turns it off |
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | how you will recognise the site in an alert; default: its host | |
| tags | No | 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. | |
| check | Yes | 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) | |
| alert_to | No | E-mail to alert on a miss; without it, the account is alerted. | |
| alert_url | No | Public HTTPS URL that receives a POST on a miss (Slack Incoming, Discord, n8n). | |
| guest_token | Yes | ||
| interval_sec | No | seconds between checks, default 300 | |
| paused_until | No | maintenance window end (UTC ISO), max 30 days ahead |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare the write/openWorld/non-idempotent profile, and the description adds substantial behavior beyond them: failure is 'two failed checks in a row, one minute apart, from a server whose own connection is proven', alert dedup is 'at most once per 24h — or per alert_repeat_sec, or per interval, whichever is longer', and the response uniquely exposes token and templates. The trailing cron/max_duration_sec material is behavioral context for a different tool and dilutes the value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The core purpose sentence is restated almost verbatim in the second sentence, and the final third about cron/tz/grace_sec/max_duration_sec describes parameters this tool does not accept and are not in its schema. It is not front-loaded by purpose — the actionable defaults and example are buried mid-paragraph.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 8-parameter write tool with no output schema, the description covers alerting semantics and the token/templates return well. But the recurring cron/schedule advice is unactionable given no such parameters and directly conflicts with 'A site has no cron', leaving an agent uncertain whether scheduling options apply here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 88%, so the schema already documents nearly every field, including the check sub-object and defaults. The description adds a concrete example ({"check":{"url":"https://example.com/"}}) and the name-without-name default ('the name defaults to the host'), but this is largely redundant with the schema's own 'default: its host' and 'default 300' notes, so the baseline 3 fits.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description conveys a specific verb+resource: it creates an HTTP site monitor that polls check.url on an interval and alerts on failure/recovery, and it explicitly separates itself from the endpoint family ('A site has no cron, no max_duration_sec and no ingest URL'). However, the repeated opening ('HookPulse calls check.url every interval_sec and alerts when it goes down' stated twice) and the later cron/tz/grace_sec advice muddy a purpose that is otherwise clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied rather than stated: the check-based monitor is the site case, and 'A site has no cron...' hints that cron belongs to a sibling. But no sibling is named (create_endpoint/cron-style alternatives are never mentioned) and the closing advice to 'send cron+tz+grace_sec' conflicts with the earlier statement, leaving the when-to-use boundary ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Removes the owner's endpoint.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ID of the monitor to deactivate. | |
| guest_token | Yes |
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.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Monitor ID, from `Monitor.id`. | |
| token | No | endpoint token (query) | |
| guest_token | No |
Liveness.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
| Name | Required | Description | Default |
|---|---|---|---|
| apply | No | "1" to create the monitors | |
| crontab | Yes | the crontab text | |
| guest_token | Yes |
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.
| Name | Required | Description | Default |
|---|---|---|---|
| guest_token | No |
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.
| Name | Required | Description | Default |
|---|---|---|---|
| guest_token | No |
Lists the guest's/session's endpoints.
| Name | Required | Description | Default |
|---|---|---|---|
| guest_token | Yes |
Latest ingest pings.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ID of the monitor. | |
| token | No | Monitor token, alternative to the `X-Hook-Token` header. | |
| guest_token | No |
The state of every site you monitor (up, down, waiting, paused), with the last check.
| Name | Required | Description | Default |
|---|---|---|---|
| guest_token | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive, and a closed world, so the safety profile is fully covered. The description adds genuinely useful return context (the status vocabulary and inclusion of the last check) but says nothing about pagination, result size limits, or what a guest_token requires, which are the remaining behavioral unknowns for a list endpoint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single tight sentence with the resource scope front-loaded and no filler. It would be marginally stronger with an explicit verb ('Returns the state...'), but nothing in it is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter, read-only listing tool with no output schema, the description covers what comes back well enough to interpret results. It is incomplete on the two things an agent must still infer: how to supply guest_token and whether the list is bounded or paginated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the single parameter guest_token is never mentioned in the description, so the agent gets no information about how the token is obtained, whether it is per-user or per-site, or what happens on an invalid token. The parameter name alone has to carry the entire burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the specific resource and scope ('every site you monitor') and enumerates the possible states (up, down, waiting, paused) plus the 'last check' field, so the agent knows exactly what this read returns. It is implicitly distinct from singular siblings like check_site or create_site, but it never names or contrasts with them explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use or when-not-to-use guidance and no alternative is named. The plural phrasing 'every site you monitor' weakly implies bulk-listing usage, but the agent gets no rule for choosing this over check_site for a single target, matching the MID calibration where an unguided description scored 2.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Simulates the cron: GET on /in/:id. No credential on purpose — the caller is a cron, and the ID is already the secret.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Monitor ID, from `Monitor.ingest_url`. |
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.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Name of the job; it becomes the monitor name. | |
| ingestKey | Yes | Ingest key, from `GET /api/ingest-key`. |
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.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Monitor ID, from `Monitor.ingest_url`. | |
| exit_code | Yes | Exit status, 0 to 255. Outside that range it is a 400. |
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.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Monitor ID, from `Monitor.ingest_url`. |
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.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Name of the job; it becomes the monitor name. | |
| signal | Yes | start, fail, or the exit code 0 to 255 | |
| ingestKey | Yes | Ingest key, from `GET /api/ingest-key`. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, but the description states the tool 'creates its monitor' and sends start/fail/exit-code signals — clear state mutation and resource creation. This directly contradicts the read-only annotation, so the safety profile is actively misleading rather than merely incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core action and reasonably sized, but the sentence 'the first signal of a new name creates its monitor' is essentially repeated twice, and the cron/tz/grace_sec clause adds detail of limited use. Some of the length does not earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should ideally indicate what the agent gets back (e.g., success/noop/created). It thoroughly covers input behavior and monitor-creation semantics but is silent on return values, leaving an agent guessing about the response of a signaling call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so slug, signal and ingestKey are already documented. The description adds context (the slug 'becomes the monitor name', shared cron/tz/grace_sec rules) but no new syntax or format detail beyond the schema, so the baseline 3 for full schema coverage applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (send start/fail/exit code) and resource (a monitor identified by slug name), and explicitly distinguishes itself from the id-based variants by quoting the equivalent `/in/:id/...` endpoints 'for a fleet that only knows the ingest key: the job sends its name, not the monitor id.' An agent can differentiate it from signal_start/signal_fail/signal_exit_code/ping_slug without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a clear selection context: use this when the fleet only knows the ingest key and sends a name rather than a monitor id. It does not explicitly name the sibling alternatives (signal_start, signal_fail, signal_exit_code) or state when NOT to use it, so it stops short of full when/when-not/alternative coverage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Monitor ID, from `Monitor.ingest_url`. |
Rotates the status feed token; the previous URL stops working.
| Name | Required | Description | Default |
|---|---|---|---|
| guest_token | No |
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.
| Name | Required | Description | Default |
|---|---|---|---|
| guest_token | No |
Dead-man switch monitors for cron & AI agents with dependency-cascade alerts. No account needed.
Dead-man's-switch for cron jobs & AI agents. Import a crontab to arm one silent-miss alert per job.
Dead-man switch for AI agents & cron jobs: heartbeat with state capsule, alerts + resume links
Self-hostable uptime monitoring: create checks, read incidents, manage status pages.
Add one secure layer between your agents and this server.
