No user-submitted related servers found.
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.