MCP Kubernetes Server - a Model Context Protocol server for interacting with Kubernetes clusters
mcp-k8s-go provides 9 Kubernetes-focused tools with consistent verb-noun naming (list-, get-, apply-, exec-) and clear descriptions. However, schemas are incomplete: parameter descriptions are present but lack formal type constraints (enums, ranges, patterns), and output schemas are not documented. Tool descriptions are adequate (50-150 chars) but could be more prescriptive about when to use each tool vs. alternatives. Error handling is minimal, no guidance on recovery steps or error categories. The server implements resources and prompts alongside tools, which adds value, but the tool definitions themselves are production-quality at ~C+ level.
Create or modify a Kubernetes resource from a YAML manifest
Execute a command inside a Kubernetes pod
Get logs from a Kubernetes pod
Get details of any Kubernetes resource like pod, node or service - completely as JSON or rendered using template
List all available Kubernetes contexts
List events from a Kubernetes cluster or namespace
List all namespaces in a Kubernetes cluster
List all nodes in a Kubernetes cluster
Output schemas are not documented. LLMs cannot infer what fields list-k8s-contexts, get-k8s-pod-logs, or apply-k8s-resource return, forcing them to guess about downstream chaining and field extraction.
Parameter constraints are missing. 'tail' (get-k8s-pod-logs) accepts any number but no bounds are documented. 'namespace' is optional in many tools but the heuristic for default behavior is not explained. No enums for 'context' parameter, LLMs must guess valid contexts.
No error handling guidance. If a pod or namespace does not exist, the tool presumably returns an error, but the description does not tell LLMs what to do next (e.g., 'call list-k8s-namespaces first to verify it exists'). No recovery hints.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 53 | 2025-06-18+ | v2 |
| 2026-03-09 | F | 23 | - | v1 |
List arbitrary Kubernetes resources
apply-k8s-resource and exec-k8s-pod-command are destructive (WRITE) but lack confirmation or dry-run capability. An LLM could accidentally apply invalid manifests or execute dangerous commands. No idempotency guarantee documented.
Parameter descriptions lack format and constraint details. 'manifest' (apply-k8s-resource) says 'YAML manifest' but does not specify whether it must be a single resource or list, or what happens if it's invalid. 'command' (exec-k8s-pod-command) does not specify shell quoting or multi-arg handling.
list-k8s-resources, list-k8s-namespaces, and list-k8s-events have no pagination parameters (limit, offset, page). For clusters with hundreds of namespaces or events, the response could be huge and blow context windows. No documented result caps.
'context' parameter appears in 8 tools with no explanation of how it maps to kubeconfig contexts. If a user says 'use production', does the context name need exact matching? Can it be partial? This ambiguity forces LLM guessing.
get-k8s-resource offers go_template parameter for custom rendering but provides no examples, format docs, or error guidance if the template is invalid. An invalid Go template will likely produce a raw error message the LLM cannot recover from.