Manage Cronitor monitors and send telemetry pings — list, inspect, create, update, delete.
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/5 across 6 of 6 tools scored.
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.
cronitor_create_monitorCreate monitorACreates 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.
cronitor_delete_monitorDelete monitorAPERMANENTLY 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.
cronitor_get_monitorGet monitorAGet 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.
cronitor_list_monitorsList monitorsAList 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.
cronitor_ping_monitorPing monitor (telemetry)AReports 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.
cronitor_update_monitorUpdate monitorACreates 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.
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!
