Loading ToolBench
A read-only Kubernetes MCP server: list resources, get resource details, retrieve pod logs, discover API resources, and perform base64 encoding/decoding operations - all while maintaining security through read-only access.
The server provides 6 tools with complete input schemas and descriptions. However, several issues limit the score: (1) two utility tools (base64_encode, base64_decode) do not match the Kubernetes domain and dilute focus; (2) output schemas are not documented, LLMs cannot plan downstream tool composition; (3) parameter descriptions lack constraint details (e.g., max_lines numeric bounds, time format examples for 'since'); (4) no error handling guidance, tools fail silently without recovery hints; (5) naming is clear and action-oriented (get_*, list_*) but lacks depth in descriptions about when to use each tool vs alternatives. The Kubernetes-specific tools (get_logs, get_pod_metrics, get_node_metrics) are well-named and have reasonably detailed input specs, but descriptions do not explain dependencies (e.g., metrics-server prerequisite mentioned but not actionable guidance on what happens if missing).
Decode base64 text
Encode text to base64
Get pod logs with advanced filtering options including grep patterns, time filtering, and previous logs
Get CPU and memory usage metrics for nodes in the Kubernetes cluster. Requires metrics-server to be installed
List containers in a pod for log access
Get CPU and memory usage metrics for pods in the Kubernetes cluster. Requires metrics-server to be installed
Output schemas not documented. LLMs cannot plan tool composition because they do not know what fields are returned (e.g., does get_logs return raw text or structured objects? Does get_pod_metrics return CPU/memory as strings or numbers?). This violates the pattern:tool-chain requirement.
Parameter descriptions lack constraint details. 'max_lines' is described as a number but has no min/max bounds (e.g., is 0 valid? 1M?). 'since' accepts 'durations like 5m, 1h' but does not state whether invalid formats are rejected or silently ignored. This forces LLMs to guess valid ranges.
No error handling or recovery guidance. If metrics-server is missing, what does the tool return? An error code? Null values? An empty list? The description states 'Requires metrics-server to be installed' but provides no actionable recovery path (e.g., 'If this fails, ask the user to install metrics-server' or 'Falls back to estimated metrics from kubelet').
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | D | 58 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 58 | - | v1 |
base64_encode and base64_decode are utility tools that do not relate to the Kubernetes domain. They dilute focus and clutter the tool palette. If needed, they should be optional or moved to a separate utility server. Most agents have built-in base64 support or can use native LLM capabilities for trivial encoding.
Tool descriptions do not explain when to use each tool vs alternatives. For example, 'get_logs' vs 'get_pod_containers', when should an agent call containers first? The description should say: 'Call this first if the pod has multiple containers and you want to see which containers are available, then call get_logs with the specific container name.'
Parameter 'context' in all tools claims to default to 'current context from kubeconfig' but does not document error handling if the context does not exist. What happens if an invalid context is passed? Does the tool fail? Does it use the current context anyway?