Loading ToolBench
MCP server for interacting with Kubernetes clusters via kubectl
This server has 23 tools with schemas present, but significant gaps in parameter descriptions, output documentation, and error handling. Most tool descriptions are adequate (50-150 chars), but many parameters lack descriptions entirely or are generic. The server follows basic naming conventions but does not implement tool annotations (readOnlyHint/destructiveHint) despite having destructive operations clearly identified in the spec. Schemas are well-formed JSON Schema with types, but output documentation is missing entirely, LLMs cannot predict what fields to expect from tool responses. Error handling is minimal; no recovery guidance visible in the code.
Cleanup all managed resources
Get Kubernetes cluster information
Execute a command in a Kubernetes pod
Explain Kubernetes resource fields
Install a Helm chart
Apply a Kubernetes YAML manifest from a string or file
List, get, or set Kubernetes contexts
Create a Kubernetes resource from a manifest
No output schemas documented for any tool. LLMs cannot predict response structure, forcing them to guess what fields exist or what to extract. This violates the critical requirement that 'Tool responses must tell the LLM what to expect' (pattern:tool). Without response schemas, agents cannot chain tools effectively (e.g., kubectl_get returns a list but no indication of field names like 'metadata.name', 'status.phase', etc.).
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite the spec declaring risk categories. The server identifies destructive tools (cleanup, kubectl_delete, uninstall_helm_chart, node_management) but does not attach destructiveHint=true to schemas, preventing hosted MCP clients from validating safety before execution. This is a Spec Alignment gap for protocol version 2026-07-28.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 60 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 38 | - | v1 |
Delete Kubernetes resources
Describe a Kubernetes resource
Execute generic kubectl commands
Get Kubernetes resources
Get logs from a Kubernetes resource
Patch a Kubernetes resource
Manage Kubernetes rollouts for deployments, daemonsets, and statefulsets
Scale a Kubernetes deployment or statefulset
List available Kubernetes API resources
Manage Kubernetes nodes
Ping the Kubernetes MCP server
Start port forwarding to a Kubernetes resource
Stop port forwarding
Uninstall a Helm release
Upgrade a Helm release
STDIO transport only. The server uses StdioServerTransport, which cannot be accessed by remote/hosted MCP clients. This is a hard architectural constraint that limits integration to local Claude Desktop or CLI-only scenarios. No Streamable HTTP endpoint exists.
No error handling guidance in tool descriptions. When kubectl_delete fails (resource not found, permission denied, etc.), there is no indication of what the agent should do next. Error responses likely return raw kubectl stderr, which is not actionable for LLMs (e.g., 'error: resource type "deployment" not found' gives no recovery path).
Parameter descriptions are minimal or missing for several tools. 'node_management' operation param has no enum or description of valid operations (cordon? drain? delete?). 'kubectl_generic' accepts 'flags' and 'args' but does not document what flags are safe or how to structure them, inviting LLM hallucination of invalid kubectl syntax.
Multiple tools operate on the same resources (e.g., kubectl_get, kubectl_describe, kubectl_apply, kubectl_delete all act on Kubernetes resources) but their names do not always make the distinction obvious. 'kubectl_get' vs 'kubectl_describe' is clear, but 'kubectl_apply' + 'kubectl_create' is redundant in intent, the descriptions should clarify when to use each (apply is idempotent; create fails if exists).
The 'context' parameter is repeated across 20+ tools with a default of empty string. This is verbose and error-prone. A better pattern would be to set the context once (via server config or a separate 'set_context' tool) and default to the current kubeconfig context, reducing parameter clutter.
No pagination support in tools that return lists (kubectl_get, list_api_resources, explain_resource). If a cluster has 1000 pods, 'kubectl_get pods' will return all of them, exhausting context windows. Missing limit and offset parameters.
No confirmation or dry-run enforcement for destructive operations. 'cleanup' has no description of what it does or what it deletes, it could wipe the entire cluster. 'kubectl_delete' has a dryRun parameter, but 'uninstall_helm_chart' and 'node_management' do not. Agents could accidentally destroy production resources.