cronstable
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| CRONSTABLE_WEB_TOKEN | No | Bearer token the `cronstable mcp` stdio bridge sends to the cronstable HTTP API. Read from the CRONSTABLE_WEB_TOKEN environment variable. Optional when the daemon's API is unauthenticated (the default), but required when the daemon sets `web.authToken`. |
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": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"listChanged": false
} |
| completions | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| cron_get_statusB | Show each job's status: running, disabled, or scheduled. |
| cron_list_jobsA | List jobs with schedule, enabled/running state, next run, and last outcome. Optional name substring |
| cron_get_jobB | Show details for one job (schedule, command, last run, live resources, retry/slot state). |
| cron_list_runsA | Show saved run history, success rate, and duration statistics for one job (most recent |
| cron_get_job_trendsB | Per-window (1h/24h/7d/30d/all) success-rate and duration statistics from the saved run history for one job. |
| cron_get_job_resourcesB | CPU/RSS time series for a job's live and recent runs (monitorResources jobs), plus its resourceLimits caps and each capped run's limits record, which says whether the caps applied and whether the run hit its memory cap. |
| cron_get_clusterA | This node's cluster/leadership view (peers, quorum, role, live load). Returns enabled:false if no cluster is configured. |
| cron_get_fleetB | Run status for each job on each node. Returns enabled:false when cluster peer communication is unavailable. |
| cron_get_nodeB | This node's live whole-host CPU/memory (optionally with the recent history). |
| cron_query_metricsB | Parsed samples from the Prometheus /metrics exposition, optionally filtered by a metric-name substring |
| cron_get_versionA | Show the server version, job-set ID, and job count. |
| cron_tail_job_logsA | Last retained stdout/stderr lines of a job, with a |
| cron_schedule_pressureA | Upcoming runs for enabled schedules over the next |
| cron_schedule_duplicatesA | Jobs with identical run times (for example, */5 and 0-59/5 in the same time zone). Use this to find schedules that could be spread out. |
| cron_suggest_slotA | Suggest a time with fewer scheduled runs in the next 24 hours. For |
| cron_validate_scheduleA | Check a cron expression before saving it as a job: valid true/false with the engine's exact error (including wrong-field hints for Quartz-style forms), the plain-English description, the normalized form, advisory warnings, and the first scheduled run, all from the server's scheduling engine. The dialect includes L (last day), L-n (n days before it), nW / LW (nearest / last weekday) and Ln / d#n (last / nth weekday: L5 = last Friday, 5#3 = third Friday). |
| cron_explain_scheduleA | Decode a cron expression into a plain-English description, its next |
| cron_why_no_runA | Explain field-by-field why a job's schedule did or did not select a timestamp ('day-of-week Tuesday is not in Monday and Friday'), with the previous and next scheduled runs and notes on this dialect's day-field AND rule and DST effects. |
| cron_list_poolsB | Show pool capacity, queued work, and recent queue outcomes. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| triage_job_failure | Find why a job failed using its runs, trends, logs, and host health. |
| blast_radius | Identify jobs and workflows affected by a failing job or workflow. |
| fleet_health_summary | A summary of cluster, node, and job health. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| status | Live status of every job. |
| cluster | This node's cluster/leadership view. |
| fleet | The cluster-wide jobs x nodes matrix. |
| version | Show the server version, job-set ID, and job count. |
TDQS
Scored across 19 tools
Most tools target clearly distinct concerns: schedule analysis (pressure/duplicates/suggest), validation/explanation, job inspection, run history, resources, cluster, node metrics, and logs. A few boundaries blur: cron_get_status vs cron_list_jobs (both report per-job state), cron_list_runs vs cron_get_job_trends (both derive stats from saved history), and cron_validate_schedule returns a plain-English description overlapping cron_explain_schedule. Descriptions generally disambiguate these, but an agent could misselect among the status/stats pairs.
All names share a consistent `cron_` prefix and snake_case verb_noun form (list_jobs, get_job, tail_job_logs, query_metrics). Minor deviations exist: cron_why_no_run is a question-phrase rather than verb_noun, and cron_schedule_pressure/duplicates use a noun-after-verb-noun ordering. Still easily readable and predictable.
At 19 tools the surface is on the heavy side, but the domain genuinely spans schedule diagnostics, job detail, run trends, resource telemetry, cluster/fleet views, node metrics, and logs. Each tool maps to a distinct capability rather than being filler, so the count is reasonable though at the upper edge.
The surface is rich for inspection and analysis but has a striking lifecycle gap: there is no tool to create, update, enable/disable, delete, or trigger a job — cron_validate_schedule explicitly validates 'before saving it as a job', implying mutation happens outside this server. Read/observe coverage is strong, but an agent asked to modify schedules would hit a dead end.