Manage Cronitor monitors and send telemetry pings — list, inspect, create, update, delete.
Scored across 6 tools
Each tool targets a distinct action: create, delete, get, list, ping, update. There is no ambiguity or overlap between them.
All tools follow the 'cronitor_<verb>_monitor' pattern with snake_case and consistent verb placement. Minor pluralization in 'list_monitors' is standard for listing endpoints.
6 tools cover the core lifecycle of monitors without unnecessary extras. The count is well-scoped for a monitoring server.
The set provides full CRUD operations plus telemetry via ping. There are no obvious gaps for managing monitors.
Creates a monitor in Cronitor (additive). Cronitor API: POST /monitors. Sends only the fields you provide.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Unique monitor id/key. | |
| name | No | Human-readable monitor name. | |
| note | No | Free-form note stored on the monitor. | |
| tags | No | Tags to group/filter monitors. | |
| type | Yes | Monitor type: job | check | heartbeat | site. | |
| notify | No | Notification list names to alert. | |
| request | No | For type=check: {url, method?, headers?, body?, ...}. | |
| schedule | No | Cron expression (job) or interval string, e.g. '0 9 * * *' or 'every 5 minutes'. | |
| assertions | No | Assertions, e.g. "response.code = 200". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide destructiveHint=true; description adds 'additive' and 'Sends only the fields you provide', clarifying behavioral traits beyond annotations. No contradictions.
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?
Two sentences with no unnecessary words. Front-loaded purpose and key API detail. Every sentence 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?
No output schema, but description covers creation purpose, API method, and partial field behavior. Lacks return value info, but sufficient for a create tool with well-documented schema.
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 describes all 9 parameters with 100% coverage. Description adds only 'Sends only the fields you provide' which reinforces optionality. Baseline 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?
Clearly states 'Creates a monitor in Cronitor (additive)'. Specifies the API endpoint (POST /monitors) and explicitly says 'additive', distinguishing from update/delete siblings.
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?
Does not explicitly state when to use this tool versus alternatives like cronitor_update_monitor. Provides guidance via 'Sends only the fields you provide' but lacks direct when/when-not context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PERMANENTLY deletes a monitor from Cronitor. Destructive and irreversible. Cronitor API: DELETE /monitors/{key}.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Monitor key/id to delete. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description reinforces the annotation destructiveHint=true by emphasizing destructive and irreversible nature, adding context beyond the annotation.
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?
Two concise sentences with critical information front-loaded ("PERMANENTLY deletes"), no unnecessary words.
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 simple 1-parameter delete tool with destructive annotation, the description is sufficiently complete; could mention return behavior but not essential.
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% and the description adds no additional meaning beyond the schema's description of the 'key' parameter.
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 uses a strong verb "PERMANENTLY deletes" and specifies the resource "monitor from Cronitor", clearly distinguishing it from sibling tools like list or update.
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 use when permanent deletion is intended but does not explicitly state when to use this tool versus alternatives or provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full detail for one monitor (latest_event, latest_invocations, passing status) — the 'is X healthy right now?' tool. Cronitor API: GET /monitors/{key}.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Monitor key/id (unique identifier). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already set readOnlyHint=true. The description goes beyond by detailing the return fields (latest_event, latest_invocations, passing status) and the API endpoint. This adds useful behavioral context 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?
Two sentences, no fluff. The purpose is front-loaded, and every word contributes meaning. Excellent structure for quick agent comprehension.
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 simple read operation with one parameter and no output schema, the description fully explains what the tool returns and its purpose. Combined with annotations, no gaps remain.
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% for the single parameter 'key', and its description already explains it as a unique identifier. The tool description does not add further semantic meaning, so the baseline score 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 action ('Get full detail') and the resource ('one monitor'), lists specific details included (latest_event, latest_invocations, passing status), and provides a colloquial purpose ('the is X healthy right now? tool'). This explicitly distinguishes it from siblings like list, create, or ping.
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 frames the tool as the go-to for checking a monitor's health status, giving strong usage context. It does not explicitly list when-not-to-use or alternatives, but the clear purpose and sibling list imply appropriate use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List monitors and their current passing/failing status. Cronitor API: GET /monitors (paginated via page + pageSize).
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number (1-based). Default 1. | |
| pageSize | No | Monitors per page. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true. Description adds that it returns passing/failing status and mentions pagination (page, pageSize). Does not contradict 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?
Single sentence with API endpoint and pagination info. No waste, front-loaded with core purpose.
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?
Simple listing tool with no output schema. Description mentions status and pagination. Annotations cover read-only. Complete enough for agent use, though return format is implicit.
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 covers 100% of params with clear descriptions. Description mentions pagination but adds no semantics beyond schema. Baseline 3 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?
Description clearly states 'List monitors' with their status, specifies verb and resource. Distinguishes from siblings like create, delete, get by focusing on listing.
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?
Implied usage: to retrieve all monitors. No explicit when-to-use or alternatives, but sibling names provide contrast. Could be improved with guidance on when to use get_monitor vs list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reports a telemetry event (run/complete/fail/ok/pause) for a monitor — records job/heartbeat activity and can clear or trigger alerts. Cronitor telemetry: GET {telemetryUrl}/p/{apiKey}/{monitorKey}?state=...
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Monitor key/id to ping. | |
| host | No | Optional host identifier. | |
| state | Yes | Telemetry state: run | complete | fail | ok | pause. | |
| metric | No | Optional metric, e.g. "count:1" or "duration:30". | |
| series | No | Optional series id to correlate run/complete pings. | |
| message | No | Optional message attached to the event. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include destructiveHint:true. Description adds that it can clear or trigger alerts and records job/heartbeat activity, providing context beyond the annotation. No contradictions found.
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?
Two concise sentences plus an example URL. Every sentence adds essential detail. No wasted words. Front-loaded with purpose.
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?
Given 6 parameters (2 required) and no output schema, the description covers the action and states. Lacks return value/response behavior, but sufficient for basic use. Slight gap in completeness.
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 parameters are well-documented there. Description adds an example URL but no new semantics beyond the schema. Baseline score of 3 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?
The description clearly states it reports telemetry events (run/complete/fail/ok/pause) for a monitor, recording activity and possibly clearing/triggering alerts. This specific verb+resource distinguishes it from sibling CRUD tools.
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 action is implied as the telemetry ping tool, but no explicit guidance on when to use vs alternatives or when not to use. Sibling names hint at CRUD, but description doesn't direct choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Creates or updates a monitor by key (e.g. change schedule, pause via paused:true). Cronitor API: PUT /monitors with a single monitor object. Sends only the fields you provide.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Monitor key/id to create or update. | |
| name | No | Human-readable monitor name. | |
| note | No | Free-form note stored on the monitor. | |
| tags | No | Tags to group/filter monitors. | |
| type | No | Monitor type: job | check | heartbeat | site. | |
| notify | No | Notification list names to alert. | |
| paused | No | Set true to pause the monitor, false to resume. | |
| request | No | For type=check: {url, method?, headers?, body?, ...}. | |
| schedule | No | Cron expression (job) or interval string, e.g. '0 9 * * *' or 'every 5 minutes'. | |
| assertions | No | Assertions, e.g. "response.code = 200". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare destructiveHint: true, consistent with description. Adds valuable context: only sends provided fields (partial update), and references API endpoint. No contradictions.
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?
Two concise sentences. Front-loaded with purpose and examples. No redundant or extraneous information.
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 core behavior and partial update, but lacks explanation of return values (output schema absent) and doesn't address constraints or error states for the 10-parameter tool.
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?
With 100% schema coverage, baseline is 3. Description adds value with examples ('change schedule, pause via paused:true') and clarifies behavior of the 'key' parameter. But does not detail all parameters.
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?
Clearly states 'Creates or updates a monitor by key' with example use cases. However, it overlaps with cronitor_create_monitor without fully differentiating, so not a 5.
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?
Indicates the API endpoint and partial update behavior ('Sends only the fields you provide'), but does not explicitly state when to use this vs. cronitor_create_monitor or provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
cronitor_create_monitorcronitor_delete_monitorcronitor_get_monitorcronitor_list_monitorscronitor_ping_monitorcronitor_update_monitorMonitor websites, APIs, and servers: create monitors, triage incidents, and query uptime stats.
Uptime monitoring that doesn't cry wolf: manage monitors, read incidents, record deploys.
Uptime monitoring: monitors, incidents, alerts, maintenance, on-call, status pages and telemetry.
Manage cron/heartbeat checks, read pings and flips, pause/resume/delete on Healthchecks.io.
Add one secure layer between your agents and this server.
