Loading ToolBench
Exposes Kubernetes cluster information as tools for Claude via the MCP protocol. Uses the official `mcp` package (mcp.server.fastmcp) and the kubernetes Python client.
Four well-named tools with clear, actionable descriptions (150 - 250 chars each). All parameters have types and descriptions. Input schemas are complete with proper JSON Schema. However, output schemas are not formally documented, responses are returned as JSON strings without explicit schema declarations. Error handling is present but minimal (returns error objects without recovery guidance). No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite all tools being read-only. Naming follows verb_noun pattern consistently (list_, get_). Parameters use sensible defaults and avoid secrets. Composition is sound, each tool has one responsibility.
Retrieve recent Kubernetes Events for a namespace. Events record things like pod scheduling, image pull failures, OOMKill notices, node pressure, and other cluster activity. Use this tool when the user wants to know what has been happening in the cluster recently, why a pod failed to start, or to get a high-level summary of cluster activity. This is equivalent to `kubectl get events`.
Return the rollout status and replica counts for one or all Deployments in a namespace — i.e. desired vs ready vs available vs updated replicas. Use this tool when the user asks about deployments, rollout progress, whether a deployment is healthy, or how many replicas are running.
Fetch recent log output from a specific pod (and optionally a specific container within that pod). Use this tool when the user wants to debug a pod, read error messages, see application output, or investigate why a pod crashed. Works for both currently-running pods and terminated/previous container instances.
List all pods in a Kubernetes namespace that are NOT in a Running or Succeeded state (e.g. CrashLoopBackOff, Pending, OOMKilled, Error). Use this tool when the user asks about unhealthy pods, failing workloads, pods that are crashing, or wants a health-check of a namespace.
Output schemas not formally documented. Tools return JSON strings but no schema definition is provided for the response structure. LLMs cannot reliably parse or plan downstream calls without knowing expected fields.
No tool annotations present. All four tools are read-only (Risk: READ_ONLY declared), but readOnlyHint is not set in tool definitions. This prevents clients from optimizing caching and retry logic.
Error responses lack recovery guidance. ApiException errors return raw reason and HTTP status (e.g., 'Kubernetes API error: Forbidden (HTTP 403)') without suggesting next steps or alternative tools.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 60 | 2026-07-28+ | v2 |
get_pod_logs returns plain text without structured metadata. Response lacks pod_name, namespace, container, timestamp fields that downstream tools or logging systems might need for context.
No pagination support. list_failed_pods and get_cluster_events can return unbounded results. Large clusters may return hundreds of items, exhausting context windows. No limit parameter or cursor-based pagination.