Model Context Protocol server for Kubernetes cluster management with special support for OpenShift
Critical gaps across all dimensions. Tool definitions are inferred from test files and scattered source locations rather than centrally registered with explicit schemas. No input parameter schemas visible in provided code. Descriptions are minimal (10-30 chars, well below 50-200 char baseline for LLM optimization). No output schemas documented. No error handling guidance. Tool names lack clarity on what distinguishes similar operations (e.g., 'targets_list' vs 'configuration_contexts_list'). No evidence of parameter validation, type definitions, or composition patterns.
List available Kubernetes configuration contexts
List Kubernetes events
List Kubernetes namespaces
List available targets (clusters/contexts)
No input schemas visible. Tool definitions appear inferred from test files (mcp_tools_test.go) rather than explicitly registered with JSON Schema. Cannot verify parameter types, constraints, or descriptions.
Descriptions are trivial (10-30 chars). 'List Kubernetes namespaces' and 'List Kubernetes events' lack context on WHEN to use each tool, what they return, or how they differ. Baseline for LLM optimization is 50-200 chars.
Naming ambiguity: 'configuration_contexts_list' and 'targets_list' both appear to list Kubernetes contexts/clusters. No clear distinction in names or descriptions. LLMs will conflate them.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 33 | 2025-06-18+ | v2 |
No output schemas documented. LLMs cannot plan downstream tool calls or extract required fields (e.g., namespace names, event IDs) without knowing response structure.
No error handling guidance. No indication of retryable vs fatal errors, or what the LLM should do if a list operation fails (e.g., 'Cluster unreachable, try a different context').