Loading ToolBench
Read-only diagnostics for a Kubernetes cluster and the local host, exposing diagnostic tools over MCP protocol
kubewhy provides 15 tools with consistent naming (verb_noun pattern: scan_cluster, list_pods, describe_pod, get_pod_events, get_pod_logs, list_nodes, list_deployments, list_jobs, get_service_endpoints, scan_references, get_platform_info, get_system_info, get_processes, get_top_cpu_processes, get_top_memory_processes). All tools have descriptions (avg ~80 chars, within baseline 34-392). Input schemas are present with type definitions and parameter descriptions. However, output schemas are NOT documented, tool_schema.py derives input schemas from Python callables but does not specify what each tool returns, forcing LLMs to infer response structure. Error handling is minimal; no recovery guidance or actionable error messages visible. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite all tools being READ_ONLY. Parameter descriptions are brief but present; some lack format/constraint details (e.g., 'limit' in get_top_cpu_processes has no min/max bounds). Composition is sound, tools are single-responsibility and chainable (e.g., scan_cluster → describe_pod → get_pod_logs). Security: no credentials in parameters (good), but no audit logging or permission gates visible.
Get detailed information about a specific pod including termination reason and resource limits
Get information about the platform this process runs on
Get events for a pod to understand what happened to it
Get logs from a pod container, redacted for common secret shapes
Get list of running processes on the local host
Get ready endpoints for a service to check if it has targets to receive traffic
Get system information including CPU, memory and disk usage
Output schemas not documented. tool_schema.py derives input schemas but does not specify return types or fields. LLMs cannot plan downstream tool calls or extract required data without knowing response structure.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). All 15 tools are READ_ONLY but lack explicit annotations. Agents cannot distinguish safe-to-retry operations from destructive ones.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 52 | <=2025-11-25 | v2 |
Get processes consuming the most CPU on the local host
Get processes consuming the most memory on the local host
List deployments in a namespace with ready vs desired replica counts
List batch jobs in a namespace with their completion status and failure reasons
List cluster nodes and their resource pressure status
List pods in a namespace with their status and health information
Scan the cluster for failing workloads across namespaces or within a specific workload
Scan for references to a resource across the cluster
Numeric parameters lack bounds. 'limit' in get_top_cpu_processes and get_top_memory_processes have no min/max constraints. Unbounded numbers let LLMs pass absurd values (e.g., limit=999999) that break APIs or cause timeouts.
No error handling guidance. Tool implementations do not document recovery paths. If a pod is not found or a namespace does not exist, LLMs receive no actionable error message or next-step guidance.
Parameter descriptions are minimal. Many lack format/constraint details. E.g., 'namespace' parameter has no guidance on valid namespace names, patterns, or how to discover available namespaces.