Mockbird

heartbeat

Dead man's switch for cron jobs, scheduled tasks, and recurring agent runs — the INVERSE of uptime_monitor: the JOB pings Mockbird, and if the ping stops arriving the alert fires once (plus one recovery message when pings resume). action:"create" {name?, period_minutes, grace_minutes?, notify?}: period_minutes = how often the job runs (30–10080); grace defaults to half the period. With notify, missed check-ins hit that webhook; WITHOUT notify you get a pollable heartbeat instead — poll for missed-check-in transitions, no webhook needed. Returns a ping URL (curl -fsS -m 10 at the end of the job — or call this tool with action:"ping"), a public status page /status/:id, badge.svg, Atom feed, and {id, secret} — STORE id, secret AND ping_url; they cannot be recovered. Creation counts as the first ping. action:"ping" {ping_url}: check in (use this to arm a heartbeat for YOUR OWN recurring runs — ping each run, and a missed run alerts your human via the webhook or your next poll). action:"poll" {id, secret}: (webhook-less heartbeats) missed-check-in / checked-in-again transitions since your last poll plus the current ping age. action:"info" {id, secret}: last ping, ping URL, recent evaluations. action:"delete" {id, secret}: disarm. notify formats are the same as uptime_monitor (Slack/Discord native, HMAC-signed JSON otherwise). Limits: 5 live heartbeats per IP — deleting one frees the slot immediately; evaluation granularity 30 min; pollable heartbeats with no polls and no pings for 30 days are removed.

Input Schema

TableJSON Schema

Name	Required	Description
`id`	No	poll/info/delete: the heartbeat id (hb-…) returned by create.
`name`	No	create: a label for the job (shown on the status page), e.g. "nightly backup".
`action`	Yes	What to do.
`notify`	No	create (optional): the webhook URL to alert when the ping stops. Omit it to get a pollable heartbeat instead.
`secret`	No	poll/info/delete: the secret returned by create.
`ping_url`	No	ping: the ping URL returned by create (https://…/ping/p-…).
`grace_minutes`	No	create: extra slack before alerting (5–1440). Default: half the period.
`period_minutes`	No	create: how often the job is supposed to run, in minutes (30–10080).

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

First observedSep 6, 2026

TDQS

A4.9/5.0

Behavior5/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It richly describes side effects and lifecycle details: alert fires once plus a recovery message, creation counts as the first ping, id/secret/ping_url cannot be recovered, limits of 5 live heartbeats per IP, deleting frees a slot immediately, and idle pollable heartbeats are removed after 30 days.

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

Conciseness4/5

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

The description is long and dense, but nearly every clause carries essential behavioral information and the core concept is front-loaded. It could be better structured with clear action-by-action formatting instead of one long paragraph, but it contains no filler.

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

Completeness5/5

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

Given the tool has five actions, eight parameters, no output schema, and no annotations, the description is remarkably complete. It covers all actions, creation return values, ping usage, poll semantics, info, delete, notify formats, limits, recovery behavior, and cleanup policy. Nothing essential is left for the agent to guess.

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 100%, so the schema already documents each parameter, but the description adds crucial semantics beyond it: period_minutes range, grace defaulting to half the period, notify omission producing a pollable heartbeat, and the curl usage pattern for ping_url. This makes the parameters genuinely actionable rather than merely named.

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?

The description clearly defines the tool as a 'Dead man's switch' for cron jobs and scheduled tasks, stating that the job pings Mockbird and an alert fires when pings stop. It explicitly distinguishes itself as the INVERSE of uptime_monitor, so an agent can immediately tell the two apart.

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

Usage Guidelines5/5

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

The description gives explicit when-to-use guidance: use it for recurring jobs that must report in, and contrasts it directly with uptime_monitor. It also distinguishes between webhook-notified heartbeats and pollable heartbeats, and explains when to use ping, poll, info, and delete. The phrase 'use this to arm a heartbeat for YOUR OWN recurring runs' makes the primary use case unmistakable.

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

All Mockbird tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.2/5.0

Disambiguation5/5

Every tool targets a distinct resource or action: project creation, data seeding, record CRUD, traffic inspection, snapshots, and monitoring are all clearly separated. The four monitoring-related tools are carefully differentiated with cross-references, so an agent is unlikely to misselect.

Naming Consistency3/5

Most data and lifecycle tools follow a clear verb_noun pattern (add_resource, create_project, query_records, write_record), but several tools use noun phrases instead (heartbeat, snapshots, project_info, uptime_monitor, custom_route). The split is readable but not a consistent convention.

Tool Count5/5

14 tools is a reasonable, well-scoped size for a combined mock-API platform and monitoring utility. Each tool has a distinct job, and the monitoring tools complement the mock-API lifecycle tools without feeling redundant.

Completeness4/5

The toolset covers project creation/deletion, resource seeding, record CRUD, request inspection, snapshots, and external API monitoring. Minor gaps exist: resources can be added but not individually removed/updated, and custom routes have no delete or update path.

Resources

Need Help?