Skip to main content
Glama

hookpulse

by net.hookpulse
OverviewDiscussionsAdmin

create_endpoint

Creates a dead-man endpoint. Use cron+tz+grace_sec for a real schedule (mutually exclusive with interval_sec) or interval_sec for plain silence detection. max_duration_sec alerts when a run opened by /in/:id/start hangs. May return 402 x402 when it leaves the free tier. This response is the only one that shows the monitor's token and the templates — keep them. The second monitor, or an interval below the free minimum, answers 402 with accepts[]: pay and repeat. 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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tzNoIANA time zone for cron, default UTC
cronNofive-field cron, e.g. 0 3 * * *
nameYeshow you will recognise the routine in an alert; required, trimmed, max 80 chars, punctuation alone is rejected
tagsNoup to 8 tags to group the monitor; lower-cased, [a-z0-9._-], max 32 chars each
alert_toNoE-mail to alert on a miss; without it, the account is alerted.
alert_urlNoPublic HTTPS URL that receives a POST on a miss (Slack Incoming, Discord, n8n).
grace_secNotolerance after the scheduled time, default 90, min 30
guest_tokenYes
interval_secNoTolerated silence, in seconds. Below the free minimum, it costs.
paused_untilNomaintenance window end (UTC ISO), max 30 days ahead
alert_repeat_secNogap before the same incident alerts again, 3600..2592000; null keeps the 86400 default
max_duration_secNoceiling for an open run in seconds, 60..86400; null or 0 turns it off

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / name / description
      Previous value: -"Name to recognise the monitor in the alert."New value: +"how you will recognise the routine in an alert; required, trimmed, max 80 chars, punctuation alone is rejected"
  2. Changed7 schema fields changed
    • addedInput schema / properties / alert_repeat_sec
      Added value: +{
+  "description": "gap before the same incident alerts again, 3600..2592000; null keeps the 86400 default",
+  "type": "number"
+}
    • addedInput schema / properties / cron
      Added value: +{
+  "description": "five-field cron, e.g. 0 3 * * *",
+  "type": "string"
+}
    • addedInput schema / properties / grace_sec
      Added value: +{
+  "description": "tolerance after the scheduled time, default 90, min 30",
+  "type": "number"
+}
    • addedInput schema / properties / max_duration_sec
      Added value: +{
+  "description": "ceiling for an open run in seconds, 60..86400; null or 0 turns it off",
+  "type": "number"
+}
    • addedInput schema / properties / paused_until
      Added value: +{
+  "description": "maintenance window end (UTC ISO), max 30 days ahead",
+  "type": "string"
+}
    • addedInput schema / properties / tags
      Added value: +{
+  "description": "up to 8 tags to group the monitor; lower-cased, [a-z0-9._-], max 32 chars each",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
    • addedInput schema / properties / tz
      Added value: +{
+  "description": "IANA time zone for cron, default UTC",
+  "type": "string"
+}
  3. Changed4 schema fields changed
    • addedInput schema / properties / alert_to / description
      Added value: +"E-mail to alert on a miss; without it, the account is alerted."
    • addedInput schema / properties / alert_url / description
      Added value: +"Public HTTPS URL that receives a POST on a miss (Slack Incoming, Discord, n8n)."
    • addedInput schema / properties / interval_sec / description
      Added value: +"Tolerated silence, in seconds. Below the free minimum, it costs."
    • addedInput schema / properties / name / description
      Added value: +"Name to recognise the monitor in the alert."
  4. First observed

TDQS

A4.5/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does so extensively: it discloses 402 billing responses, the one-time visibility of token and templates, alert throttling rules, the free-minimum interval cost, and the distinct failure mode caught by max_duration_sec. This goes well beyond a generic 'creates a resource' statement.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The content is dense and mostly valuable, but the cron-versus-interval guidance appears twice in nearly equivalent wording, and billing, response, and alerting details are packed together without clear structure. It is informative but less concise and scannable than it could be.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 12-parameter creation tool with no annotations and no output schema, the description covers the critical behavior: mode selection, billing, alert throttling, and the must-keep response fields. It is not fully complete because the required guest_token parameter is never explained and the general success/error response shape is not described.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 92%, so the baseline is 3, but the description adds substantial decision-level meaning: cron/tz/grace_sec versus interval_sec, the concrete 03:00 backup example, max_duration_sec's role in catching hangs, and alert_repeat_sec's interaction with the 24h default. It turns raw parameters into operational choices.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb and resource: 'Creates a dead-man endpoint.' This clearly differentiates it from sibling operations like delete_endpoint, get_endpoint, and list_endpoints. The rest of the description clarifies that an endpoint is a monitor with either scheduled or silence-detection behavior.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit mode-selection guidance: use cron+tz+grace_sec for a real schedule, interval_sec for silence detection, and max_duration_sec for hanging runs. It also states the free-tier/billing condition and the 'pay and repeat' path. It does not explicitly compare this tool to sibling create_* tools, but the within-tool parameter guidance is strong.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All hookpulse toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources