Kube Check
Related Servers
Alternatives to Kube Check
No user-submitted related servers found.
Related Servers
- AlicenseBqualityAmaintenanceEnables agents to audit Kubernetes manifests without a cluster: scanning YAML text or whole directories with file:line evidence, browsing the rule catalogue with why/fix rationale, resolving RoleBindings into each subject's effective permissions, and running a self-check that the rules fire.5MIT
- AlicenseAqualityCmaintenanceEnables AI agents to audit Kubernetes manifests for configuration traps that pass linters but silently break production, via read-only tools to audit YAML, list known traps, and explain trap details.3MIT
- AlicenseNot gradedqualityBmaintenanceEnables read-only inspection of Kubernetes resources and Terraform plans, retrieval of policy findings, and schema and policy validation of manifests and patches without applying changes.MIT
- AlicenseNot gradedqualityCmaintenanceMCP server to lint and validate Kubernetes-related manifests(Helm, FluxCD, ArgoCD, Kustomize, etc.)73 PyPIMIT
- AlicenseNot gradedqualityBmaintenanceEnables MCP clients to audit, generate, debug, and learn Kubernetes, OpenShift, ROSA, Helm, and RHACS/StackRox configurations through read-only-first tools, playbooks, cited local knowledge, and hardened manifest generation that runs offline unless network access is explicitly enabled.Apache 2.0
- AlicenseAqualityBmaintenanceEnables coding agents to lint Dockerfiles and Kubernetes manifests through the Shipshape API, returning an A–F grade, score, pass/fail status, and every finding with its line, fix, and reference. Uses the user's own marketplace key, reports remaining plan quota, and explains errors in plain language.1MIT
TDQS
Scored across 3 tools
The three tools target distinct activities: API version lifecycle lookup (api_versions), manifest validation (check_manifests), and field schema documentation (field_help). There is mild overlap between api_versions and check_manifests since both surface deprecated/removed APIs, but the descriptions make the boundary clear (lookup vs. file-level validation).
All names are snake_case, which is good, but the patterns differ: api_versions is a noun phrase, check_manifests is verb_noun, and field_help is noun_noun. Readable but no single predictable convention.
Three focused tools is on the lean side but each covers a distinct, well-motivated capability for Kubernetes manifest checking. No filler tools and no obvious redundancy.
The surface covers the key lifecycle needs: API version/deprecation status, manifest validation with fixes, and field documentation including CRDs and Helm/Kustomize-aware behavior. Minor gaps like live-cluster validation or explicit schema browsing are acceptable for the stated scope.