watchcron-mcp
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| WATCHCRON_API_KEY | Yes | Your WatchCron API key |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_monitorsA | List all cron job monitors in your WatchCron project. Shows name, status, schedule, last ping time, and ping URL for each monitor. |
| get_monitorA | Get detailed information about a specific cron job monitor, including its status, schedule, ping URL, last ping time, and next expected ping. |
| create_monitorA | Create a new cron job monitor. Returns the ping URL that your cron job should call. Supports simple interval (every N seconds) or cron expression schedules. |
| update_monitorC | Update an existing cron job monitor's settings (name, schedule, grace period, tags). |
| delete_monitorB | Permanently delete a cron job monitor. This cannot be undone. |
| pause_monitorA | Pause or resume a cron job monitor. Paused monitors won't trigger alerts when pings are missed. |
| get_pingsB | Get recent ping history for a monitor. Shows when pings were received, their type (success/start/fail), source IP, and duration. |
| get_incidentsA | Get status change history (incidents) for a monitor. Shows when the monitor went down, recovered, or changed status. |
| list_channelsA | List notification channels configured in your WatchCron project (email, Slack, webhook, etc.). |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 9 tools
Each tool has a distinct resource+action target: monitor CRUD is split cleanly across list/get/create/update/delete, with pause_monitor covering the orthogonal state toggle. get_pings and get_incidents target clearly separate history types, and list_channels is the only channel tool, so there are no ambiguous boundaries.
All tools follow a consistent snake_case verb_noun pattern (list_monitors, get_monitor, create_monitor, delete_monitor, get_pings, get_incidents). The single deviation, pause_monitor, still fits the pattern even though it also resumes.
Nine tools is well-scoped for a cron monitoring service, with each tool earning its place across the lifecycle (create/list/get/update/delete) plus observability and notification surfaces. No redundant or filler tools.
Monitor lifecycle is fully covered (create, list, get, update, delete, pause/resume) with ping and incident history reads, so core workflows have no dead ends. The gap is channels: list_channels exists with no create/update/delete-channel counterpart, and there is no manual ping/test trigger.