Loading ToolBench
Model Context Protocol server for Kubernetes — multi-cluster access with security modes and access-control flags.
Solid foundation with well-named, consistently described tools and proper input schemas. The server demonstrates good pattern coverage (17 tools across READ, WRITE, and ADMIN tiers) with explicit security annotations. However, output schemas are not formally documented, and parameter descriptions lack detail on constraints (ranges, enums, formats). Error handling is present but minimal, no recovery guidance or per-item failure reporting. Tool composition is clean (single responsibility, good naming), but some tools could include richer chaining metadata to reduce follow-up calls.
Create or replace an arbitrary Kubernetes object from a manifest. Requires K8S_ALLOW_APPLY=true. Pass the manifest as a JSON object with apiVersion, kind, metadata, and spec.
Create a new namespace.
Delete an arbitrary Kubernetes object by apiVersion/kind/name. Requires admin mode AND K8S_ALLOW_DELETE=true. Protected namespaces are refused. Irreversible.
Run a command inside a pod container and return its output. Requires admin mode AND K8S_ALLOW_EXEC=true. This is powerful — treat with care.
Fetch the full representation of a single pod.
Fetch recent logs from a pod container.
Output schemas are not formally documented in code. LLMs cannot infer return types from tools like list_pods or get_pod, they don't know which fields (name, namespace, status, readiness, restarts, node) to expect or how to chain results to subsequent calls.
Parameter descriptions lack constraint details (ranges, enums, formats). For example, 'tailLines' param in get_pod_logs says 'Lines from the end (default 200)' but doesn't specify min/max bounds or explain what 'default' means to the LLM. Similarly, 'replicas' in scale_deployment lacks a minimum value constraint.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 63 | 2026-07-28+ | v2 |
Read an arbitrary Kubernetes object by apiVersion/kind/name (e.g. apiVersion=apps/v1, kind=Deployment).
List the contexts (clusters) available in the loaded kube-config.
List deployments in a namespace with replica status.
List recent events in a namespace — useful for diagnosing failures.
List namespaces in the cluster. Namespaces outside the allowlist are filtered out.
List cluster nodes with readiness and kubelet version.
List pods in a namespace with status, readiness, restarts, and node.
List services in a namespace with type and cluster IP.
Trigger a rolling restart of a deployment (equivalent to `kubectl rollout restart`).
Set the replica count of a deployment.
Update the image of a named container in a deployment.
Error handling is functional but minimal. The toErrorResult() function in server.ts returns a text message but does not categorize errors (retryable vs. user-fixable vs. fatal) or provide recovery guidance. For example, if 'namespace not found', the LLM gets no hint to call list_namespaces first.
Tools like apply_manifest and delete_resource accept a 'manifest' object (JSON) but do not validate it against Kubernetes OpenAPI schema before submission. An LLM can pass an invalid manifest and receive a raw API error ('ApiException') with no guidance on what to fix.
Result sets from list_pods, list_deployments, list_services, list_nodes, list_events are not paginated or capped. If a namespace contains 1000 pods, all 1000 are returned, potentially exhausting the LLM's context window. No limit parameter or pagination cursor is visible.
When a destructive operation (delete_resource, exec_in_pod) requires admin mode AND environment flags (K8S_ALLOW_DELETE, K8S_ALLOW_EXEC), the tool description does not explain this dual gate. LLMs do not have visibility into environment config, they need the description to warn that the tool may be unavailable.