MCP server that provides access to Kubernetes API resources through a set of tools for querying and inspecting cluster objects
This Kubernetes MCP server has 22 READ_ONLY tools covering cluster introspection. Major issues: (1) 9 of 22 tools lack descriptions entirely (list_nodes, list_services, list_deployments, list_ingresses, list_persistent_volumes, list_persistent_volume_claims, list_pods, list_events, list_config_maps, list_secrets, get_pod, get_service, get_node). (2) Input schemas are present only for tools with explicit parameters documented; many list_* tools lack input schema visibility. (3) Parameter descriptions are minimal or absent for list_* operations. (4) No output schemas documented anywhere. (5) No error handling guidance, recovery hints, or actionable error messages shown in source. (6) Tool names follow verb_noun convention (good), but lack context about what distinguishes list_pods from get_pod or whether pagination is supported. Average tool description length is ~40 chars for those with descriptions, below the 194-char baseline for A+ tools. Conservative scoring reflects these gaps.
Get a config map in the Kubernetes cluster
Get a deployment in the Kubernetes cluster
Get an ingress in the Kubernetes cluster
Get the namespaces in the Kubernetes cluster
Get a node in the Kubernetes cluster
Get a persistent volume in the Kubernetes cluster
Get a persistent volume claim in the Kubernetes cluster
9 of 22 list_* tools completely lack descriptions. LLMs cannot determine when to call list_pods vs get_pod, whether these return paginated results, or what fields are included.
Input schemas not visible for list_* tools. These likely accept namespace, label_selector, or other filtering parameters, but no schema documentation is provided in source. Cannot verify parameter types or descriptions.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 40 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 40 | - | v1 |
Get the Kubernetes API server version details
No output schemas documented for any tool. LLMs cannot plan downstream tool calls or extract the right fields from responses (e.g., does get_pod return pod.status.phase, and should it be passed to another tool?).
get_service, get_pod, get_secret lack descriptions entirely. Even get_* tools need to explain what they return and when to use them vs list_*.
No pagination, limit, or offset parameters documented for list_* tools. Large clusters may return hundreds or thousands of resources, exhausting LLM context. No indication of whether results are capped or how to fetch more.
No error handling guidance visible. LLMs need to know: if a pod is not found, should they try list_pods first? If a namespace does not exist, what are the alternatives? No recovery hints provided.
Tool names do not distinguish between cluster-level resources (nodes, namespaces, PVs) and namespace-scoped resources (pods, services, deployments). Description clarity would help LLMs avoid scope mismatches.