Uptime watchdog and dead man switch for AI agents and cron jobs. Alerts you when a job goes silent.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.3/5 across 4 of 4 tools scored. Lowest: 3.6/5.
Each tool targets a distinct operation: create, check status, send signal, and configure alerts. No overlapping purposes; the tool descriptions make it clear when to use each one.
All tool names follow a consistent verb_noun pattern: create_heartbeat, get_heartbeat_status, ping_heartbeat, set_heartbeat_alert. The 'heartbeat' noun is uniform and the verbs clearly indicate the action.
With 4 tools, the server is well-scoped for a heartbeat monitoring service. Each tool serves an essential purpose in the lifecycle (create, monitor, alert), and there is no redundancy or unnecessary excess.
The tool set covers the core workflow: creating a check, pinging it, retrieving status, and setting alerts. Missing update/delete operations for checks are a minor gap, but agents can likely work around it via the claim_token; still, the coverage is solid for the stated purpose.
create_heartbeatAInspectCreate a Cronping heartbeat monitor (dead-man's-switch). Returns a ping_url to call on each successful run of your agent loop, worker, or cron job, plus a claim_token to manage it. If pings stop arriving within period+grace, Cronping raises an alert. No account required. After creating, send one verification ping (call ping_heartbeat with the returned id) to confirm setup — the check flips from 'new' to UP so you know it's wired correctly. Alternatively, pass pull_url to make a PULL check: Cronping fetches that URL on schedule and alerts if it fails — for targets that can't call a ping URL (a health endpoint, status page, or API).
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Label for what is monitored, e.g. "nightly-backup" or "research-agent-loop". | |
| No | Email address for DOWN and recovery alerts. STRONGLY RECOMMENDED — without an email or webhook_url, Cronping tracks status but cannot notify anyone when the job stops, which defeats the purpose. Use your operator's email. | ||
| pull_url | No | Optional. If set, creates a PULL check instead: Cronping itself fetches this URL every period_seconds and alerts if it fails — use for a target that can't call a ping URL (a public health endpoint, status page, or API). No ping needed. | |
| stuck_after | No | Optional. Flip to STUCK if the progress_token passed to ping_heartbeat stays identical for this many consecutive runs (default 3, 0 disables). Catches zombie runs that keep pinging but make no progress. | |
| webhook_url | No | https webhook (Slack/Discord/generic) for DOWN and recovery alerts. Set this OR email so someone is actually notified when the monitored job goes silent. | |
| grace_seconds | No | Extra slack before marking DOWN, in seconds. Default 3600. | |
| pull_contains | No | Optional (pull checks only). The fetched response body must contain this text to count as UP; otherwise Cronping alerts. | |
| period_seconds | No | How often you expect a ping, in seconds (min 60). Default 86400 (daily). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide only negative hints (readOnlyHint=false, etc.), so the description carries the transparency burden. It discloses the return values (ping_url, claim_token), the state transition from 'new' to UP after verification, the alerting behavior when pings stop, and the pull check semantics. It also notes that no account is required and that without email/webhook_url, no one gets notified. No contradiction with annotations.
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 description is longer than minimal but every sentence serves a purpose: defining the tool, explaining the verification step, and detailing the pull check alternative. It is front-loaded with the core purpose and avoids fluff. Slightly dense, but content-rich and logically organized.
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 fully accounts for the return values (ping_url, claim_token) and the id used for verification. It explains the different modes (ping vs pull), the alerting condition, and the setup confirmation step. For a tool with 8 parameters and no output schema, this is a complete and context-rich description.
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 100%, so the baseline is 3. The description adds value beyond the schema by explaining the overall workflow (verification ping, pull vs ping) and the purpose of returned values. However, it does not elaborate on individual numeric parameters beyond what the schema already says, so it doesn't reach the top score.
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 opens with a specific verb+resource: 'Create a Cronping heartbeat monitor'. It clearly distinguishes this from sibling tools (ping_heartbeat sends pings, get_heartbeat_status reads status, set_heartbeat_alert modifies alerts) by focusing on creation and the returned artifacts. The dead-man's-switch concept is explained, leaving no ambiguity about what the tool does.
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?
The description provides explicit when-to-use guidance: it is for monitoring agent loops, workers, or cron jobs. It also explains when to use the pull_url alternative instead ('for targets that can't call a ping URL'), and gives a recommended follow-up action (send one verification ping). It warns about the email/webhook requirement, helping the agent decide whether to set those parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_heartbeat_statusAGet the live status of a Cronping check (up/down/new, last ping time, ping count, and whether an alert channel is set).
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| claim_token | Yes | The claim_token returned by create_heartbeat. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is known. The description adds behavior context by enumerating the returned information (up/down/new, last ping time, ping count, alert channel), which is valuable since there is no output schema. However, it does not mention error or edge-case behavior.
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 description is a single, compact sentence that front-loads the action and then lists the exact data returned. Every word adds value.
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?
Despite the lack of an output schema and only partial parameter documentation, the description conveys the tool's purpose and return data adequately. Given the tool's simplicity and the annotations confirming read-only/idempotent behavior, it is reasonably complete for an agent to select. However, the ambiguity around the 'id' parameter prevents a 5.
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 only 50% (claim_token has a description, id does not). The tool description does not explain the parameters at all, leaving the meaning of 'id' ambiguous. While claim_token is documented in the schema, the missing id description is not compensated.
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 clearly states the tool's action ('Get the live status') and resource ('Cronping check'), and distinguishes it from sibling tools like create_heartbeat and set_heartbeat_alert by focusing on reading status rather than modifying or creating.
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?
The description implies usage for retrieving current status but does not explicitly state when to choose this over alternatives or provide exclusions. The context signals show sibling tools for creation and alerting, but the description lacks direct comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ping_heartbeatASend a heartbeat signal to a Cronping check. signal="success" (default) marks it UP and resets the timer; "start" records that a run began (for duration); "fail" marks it DOWN immediately and alerts. Optionally pass progress_token (a digest of your run's actual output) on success pings: if the same token repeats for several consecutive runs, the check flips to STUCK — catching a "zombie" job that keeps pinging on schedule while its real work has stalled.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The check id returned by create_heartbeat. | |
| signal | No | success | start | fail. Default success. | |
| progress_token | No | Optional. A short digest/hash of this run's output (e.g. last-processed id, row count, content hash). If it stays identical across stuck_after consecutive runs, the check flips to STUCK and alerts. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation idempotentHint is true, but the description reveals that repeatedly sending success with the same progress_token can flip the check to STUCK, meaning identical repeated calls produce different outcomes over time. This contradicts the idempotency hint, so the description is in direct conflict with annotations.
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 description is dense yet compact, using two sentences to cover signal effects, the progress_token mechanism, and the zombie-job use case. Every phrase earns its place with no filler, and the structure flows logically from basics to optional behavior.
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?
The description thoroughly covers the tool's behavior including state transitions and the STUCK mechanism, which is crucial for correct usage. It omits the response format and potential errors, but given the tool's simple nature and lack of output schema, the description is nearly complete. The idempotency contradiction slightly undermines overall contextual reliability.
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?
Even though schema coverage is 100%, the description adds substantial meaning beyond the schema: it explains what each signal value does (UP, duration, DOWN), and how progress_token behaves (consecutive identical tokens trigger STUCK). This transforms raw parameter definitions into actionable behavioral knowledge.
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 clearly states the tool sends a heartbeat signal to a Cronping check, with a specific verb and resource. It enumerates the three signal types and their distinct effects, making it obvious what the tool does and differentiating it from siblings like create_heartbeat and get_heartbeat_status.
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?
The description provides clear context for when to use each signal (success marks UP, start records beginning, fail marks DOWN) and when to use progress_token (on success pings to detect zombie jobs). It doesn't explicitly name alternatives or exclusions, but the usage context is evident from the signal semantics.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
set_heartbeat_alertAAdd or change the alert channel on an EXISTING Cronping check (use this instead of creating a duplicate). Sets the email and/or webhook (Slack/Discord/generic https) that Cronping notifies when the monitor goes silent or recovers. Without an alert channel a check tracks status but can't warn you — call this once per check to make the dead-man's-switch actually protect you.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The check id returned by create_heartbeat. | |
| No | Email address to notify (e.g. the operator/owner). Pass empty string to clear. | ||
| claim_token | Yes | The claim_token returned by create_heartbeat. | |
| webhook_url | No | Optional https webhook (Slack/Discord/generic) to notify. Pass empty string to clear. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotency and non-read-only behavior. The description adds context beyond that by explaining the notification triggers ('when the monitor goes silent or recovers') and the consequence of not setting an alert channel. This enriches behavioral understanding without contradicting annotations.
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 description is concise and front-loaded. The first sentence states the core purpose, the second adds technical detail, and the third explains the usage context. Every sentence earns its place, with no redundant or filler content.
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?
The description covers the tool's purpose, when to use it, and the importance of setting an alert channel. It implies prerequisites ('EXISTING') and the id/claim_token are documented in the schema. Given the tool's moderate complexity and the presence of annotations, the description is sufficiently complete.
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 the parameters are already well-documented. The description mentions email and webhook types but does not add significant meaning beyond what the schema provides. It provides no additional syntax or format details, so a baseline of 3 is appropriate.
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 clearly states the tool's function: 'Add or change the alert channel on an EXISTING Cronping check.' It identifies the specific resource (alert channel) and the action (add/change), and explicitly distinguishes it from creating a duplicate, which differentiates it from sibling tools like create_heartbeat.
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?
The description provides explicit guidance: 'use this instead of creating a duplicate' and 'call this once per check.' It also explains when alerts are needed, stating that without an alert channel a check 'tracks status but can't warn you,' clarifying the tool's role relative to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!