Loading ToolBench
A Kubernetes MCP server that provides tools and resources for interacting with Kubernetes clusters
The server defines 10 tools with consistent verb-noun naming and mostly complete parameter schemas. However, descriptions lack depth for LLM optimization, and several patterns from the 54 Agentic Tool Patterns are missing. Tool descriptions range from adequate to generic; most fall short of the 50-200 character sweet spot for LLM reasoning. Parameters are typed and often have descriptions, but guidance on format constraints, dependencies, and expected values is sparse. Output schemas are not documented in tool definitions, and error handling guidance is minimal. The kubectl_generic tool (which accepts arbitrary shell arguments) poses a notable composition and security concern, it conflates multiple responsibilities and lacks input validation.
Count Pods in a Kubernetes namespace
Execute kubectl annotate command to add, update, or remove annotations on resources
Execute kubectl apply command to apply configuration to resources
Execute kubectl create command to create Kubernetes resources
Execute kubectl delete command to delete Kubernetes resources
Execute kubectl describe command for detailed information about Kubernetes resources
Execute any kubectl command with custom arguments - use this for kubectl functionality not covered by other specific tools
kubectl_generic accepts arbitrary shell arguments as a free-form string ('args' parameter), violating the single-responsibility and constrained-input patterns. This enables command injection risks and conflates multiple kubectl operations into one tool. LLMs cannot reason about valid argument combinations; validation must happen at runtime.
No output schemas are documented in tool definitions. LLMs cannot plan downstream operations without knowing what fields to expect. For example, kubectl_get returns structured data (JSON/YAML), but the tool description does not specify whether it returns raw API response, parsed objects, or a summary. This forces LLMs to guess field names and breaks tool chaining.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 54 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Execute kubectl get command for any Kubernetes resource type with advanced filtering options
Execute kubectl label command to add, update, or remove labels on resources
Execute kubectl logs command to get logs from pods
Tool descriptions are too generic or brief. Most fall well below the 50-200 character range recommended for LLM optimization. Examples: 'Execute kubectl get command...' (54 chars) lacks context on when to use it vs kubectl_describe. 'Execute any kubectl command...' for kubectl_generic (48 chars) tells the LLM nothing about intent or composition. Descriptions should explain what the tool does, when to use it, and what it returns.
No error handling guidance. Tool descriptions do not explain what errors might occur, whether they are retryable, or what the LLM should do next. For destructive operations like kubectl_delete and kubectl_apply, there is no mention of dry-run validation or confirmation workflows. This invites accidental deletions.
Parameter format constraints are missing or documented only in free-text descriptions. Examples: 'field_selector' and 'label_selector' accept arbitrary strings without specification of format (are they comma-separated key=value pairs? Do they follow kubectl syntax?). 'JSONPath expression' lacks a pattern or example. Descriptions should state constraints formally or via examples LLMs can follow.
Mutually exclusive parameters are not documented. For example, in kubectl_get, 'name', 'field_selector', and 'label_selector' should probably not all be specified together, but this is not stated. In kubectl_delete, 'name', 'filename', and 'label_selector' appear to be alternatives, but the descriptions do not clarify which combinations are valid.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). The server declares risk levels (READ_ONLY, WRITE, DESTRUCTIVE) in the tool metadata, but these are not exposed via MCP tool annotations. This forces the LLM to infer risk from the description and name alone.
Destructive operations lack confirmation or dry-run workflows. kubectl_delete and kubectl_apply accept a 'force' parameter and support 'dry_run', but the tool descriptions do not encourage or guide LLMs to use dry-run first. Without explicit guidance, agents risk executing destructive operations immediately.
Parameter descriptions for enumerated values do not use formal enum constraints in the schema. For example, 'output' in kubectl_get lists valid values in the description ('json, yaml, table, name, wide, custom-columns, jsonpath') but does not declare an enum type in the schema. This forces LLMs to parse the description text rather than selecting from a structured list.
Tool composition breaks for multi-step workflows. There is no explicit guidance on tool sequencing. For example, to get logs from a pod in a specific namespace, the LLM must call kubectl_logs with both pod_name and namespace; if the LLM has only a deployment name, it must first call kubectl_get to find pod names. Dependencies are not documented, forcing wasteful discovery calls.