k8s-cronjob-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| KUBECONFIG | No | Standard kubeconfig lookup path (must be absolute; MCP clients do not expand `~`), or in-cluster config when running in a pod. | |
| K8S_CONTEXT | No | Context to use instead of the kubeconfig's current one. Set this explicitly so the server cannot silently target the wrong cluster. Must be the context NAME from `kubectl config get-contexts`, not the cluster name. | |
| ALLOWED_NAMESPACES | No | Optional comma-separated allowlist of namespaces the server is confined to, e.g. `batch,reports`. Anything else is refused before any API call. Useful when you can only read some namespaces (403 at cluster scope). | |
| CRON_DEFAULT_TIMEZONE | No | Timezone for CronJobs that do not set `spec.timeZone`. Defaults to `UTC`; only set it if your kube-controller-manager runs in another timezone. | UTC |
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 |
|---|---|
| check_setupA | Check this server's configuration step by step (kubeconfig, context, auth helper, timezone, cluster reachability and read access to each resource) in the exact environment the MCP client runs it in. For every problem it says what is wrong, which environment variable to set and where. Run this first whenever another tool reports a configuration, permission or connection error. Read-only. |
| get_cronjob_statusA | Check whether a CronJob is running on schedule. Compares its cron schedule against the actual last scheduled run and returns a verdict: on-schedule, late, missed, currently running (or suspended), plus the next run time and whether runs take longer than the schedule interval (overrun: skipped, late or overlapping runs). |
| get_run_historyA | List retained Jobs for a CronJob (newest first) with start time, duration, status and pod exit code, plus a duration trend. Warns when history limits are too short to be useful. |
| find_silent_failuresA | Scan CronJobs (one namespace or all) for ones with no successful run in the last N days, even if nothing is erroring right now. Returns the CronJobs needing attention, most urgent first, with the pattern (failing, stalled, never-succeeded), time since last success and last failure. Also catches CronJobs that stopped firing after a recent success, reports CronJobs whose runs outlast their schedule interval as degraded, and flags at-risk ones whose runs use more than 80% of it. Suspended CronJobs are listed briefly. Every result says what time window and runs it is based on. |
| get_failure_detailsA | Explain why a Job failed. Finds its pods, reads container exit state, Kubernetes Events and a log tail (secrets masked), and returns a synthesized cause such as 'container OOMKilled at 340Mi, exit code 137' followed by the evidence. |
| list_active_runsA | List Jobs that are running right now (one namespace or all), including Jobs not created by a CronJob. For each: owning CronJob, start time, how long it has been running, pod counts, deadline, and whether it is taking more than twice its typical duration. Longest-running and overdue Jobs first. |
| list_cronjobsA | Overview of every CronJob (one namespace or all), one compact row each: schedule, effective timezone, health (failing, stalled, never-succeeded, degraded, overrunning, at-risk, healthy, suspended), next run, last scheduled run, last success and last result. Worst first. Use this to see what exists before drilling into one CronJob. |
| list_recent_failuresA | List Jobs that failed in the last N hours (one namespace or all), newest first, each with a synthesized cause (e.g. OOMKilled, exit code, image pull, deadline) and whether a later run of the same CronJob has succeeded since. Includes Jobs not created by a CronJob. Use get_failure_details for logs and events of one failure. |
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 8 tools
Each tool targets a distinct lens (setup diagnostics, single-CronJob schedule status, run history, silent failures, failure forensics, active runs, inventory, recent failures) and descriptions explicitly cross-reference when to use a sibling. Minor overlap remains between find_silent_failures, list_recent_failures and get_cronjob_status, which all surface problem states, and between list_active_runs and the 'currently running' verdict in get_cronjob_status.
All tools follow a verb_noun snake_case pattern (get_cronjob_status, list_recent_failures, find_silent_failures). Small deviations exist: check_setup lacks a resource noun and find_silent_failures inserts an adjective, but the convention is still predictable overall.
Eight tools is well-scoped for a CronJob monitoring server, and each tool earns its place by covering a distinct workflow (setup validation, health triage, drill-down, forensics). No redundant or filler tools are apparent.
For a read-only diagnostics/monitoring domain the lifecycle is well covered: configuration check, inventory, per-object status, history, failure explanation, active runs, and two failure-scan modes. The notable gap is the absence of any mutation tools (suspend/resume, manual trigger), which may be intentional for a strictly read-only server but limits remediation workflows.