Loading ToolBench
A read-only Kubernetes MCP server for safely interacting with Kubernetes clusters
Kubernetes-readonly-mcp is a well-structured read-only tool set with clear naming, comprehensive parameter descriptions, and proper schema definitions. All four tools follow verb-noun naming (list_*, get_*), have non-trivial descriptions (117-242 chars), and include full input schemas with typed parameters. Tool annotations are properly used to mark all tools as read-only, idempotent, and non-destructive. The main weaknesses are: (1) error responses return generic dicts without recovery guidance, (2) output schemas are not formally documented in descriptions, (3) some tools lack pagination support despite returning potentially large result sets, and (4) parameter constraint documentation could be more explicit (e.g., tail_lines has no min/max bounds stated).
Get logs from a pod in a specified namespace
List all deployments in a specified namespace
List all pods in a namespace or across all namespaces
List all services in a namespace or across all namespaces
Output schema not documented in tool descriptions. LLMs cannot determine what fields (name, namespace, ip, status, labels, node, containers, creation_timestamp) will be returned by list_pods, list_deployments, or list_services. This forces LLMs to infer structure and plan poorly for downstream processing.
Error responses return unstructured {'error': str(e)} dicts without recovery guidance. When a tool fails (e.g., namespace not found, API connectivity issue), the agent receives only a raw exception message and cannot determine whether to retry, ask the user for clarification, or try an alternative tool. Example: list_pods with an invalid namespace will return {'error': 'Not Found'}, the agent doesn't know if it should try list_pods without a namespace argument.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 63 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 22 | - | v1 |
No pagination support despite tools returning potentially large result sets. If a cluster has thousands of pods or services, list_pods and list_services will attempt to return them all at once, exhausting the context window. The rubric baseline (mxe:enforce-result-limits) requires capping at 20-50 items and offering pagination or a total_count field.
Parameter constraints not explicitly documented. get_pod_logs accepts tail_lines (integer) with no stated minimum or maximum. Without bounds, an LLM could pass tail_lines=-1 or 1000000, causing API failures. Baseline requires: 'Number of lines to show from the end (1 - 10000, default: all)'.
Secret redaction logic in _sanitize() function is sound, but not exposed to users via tool descriptions. The secret redaction mechanism (dropping data, stringData, and kubectl.kubernetes.io/last-applied-configuration) is implemented but invisible to agents, so they cannot reason about what sensitive data is being filtered or trust the tool. Documentation should state: 'Secret values are automatically redacted; only metadata and type are returned.'