Loading ToolBench
A Kubernetes MCP Server that provides tools for interacting with Kubernetes resources through the Model Context Protocol
Koffee presents a Kubernetes tool suite with 12 tools showing consistent structure and good naming conventions. Most tools follow verb_noun patterns (list_clusters, get_cluster_version, delete_resource). All tools have descriptions and input schemas are present for most. However, there are critical gaps: (1) Parameter descriptions are inconsistent, some tools like get_pod_logs have required parameters ('kind') that don't appear in the documented input schema, suggesting either documentation drift or schema validation issues. (2) Output schemas are completely missing, no tool declares what fields it returns, forcing LLMs to guess response structure. (3) Error handling is not visible in the code sample, and descriptions lack recovery guidance. (4) Some descriptions are adequate but not optimized for LLM reasoning (e.g., 'Get detailed information about a specific resource' is vague about what 'detailed' means). (5) Tool annotations are present and correctly used (readOnlyHint, idempotentHint, destructiveHint), which is excellent. Average tool quality is mid-C to C+, pulled up by consistent naming and basic structure, pulled down by missing output schemas and incomplete parameter documentation.
Apply a configuration to a resource by file name. The resource name must be specified. This resource will be created if it doesn't exist yet
Delete a resource with the specified name and namespace if it's namespace-scoped
Get all supported API resource types in the cluster, including built-in resources and CRDs
Get the cluster version
Get the logs for a container in a pod or specified resource. If the pod has only one container, the container name is optional
Get detailed information about a specific resource
List the local kube cluster context information
Missing output schemas on all tools, LLMs cannot predict response structure, forcing them to reason about unknown fields and risk misinterpreting results. Baseline expects 100% of A-grade tools to have documented return types.
get_pod_logs declares 'kind' as a required parameter in description but 'kind' does not appear in the input schema properties, suggests documentation drift or incomplete schema definition. This causes validation failures and LLM confusion.
top_node has no input schema at all (no documented parameters or properties). Tool is barely usable without knowing what inputs it accepts.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 54 | 2025-06-18+ | v2 |
| 2026-03-09 | D | 53 | - | v1 |
List all instances of a resource type
Execute a command in a container. If the container is empty, it uses the default container or the first container in the pod.
Switch the kubernetes context
Display resource (CPU/memory) usage of nodes
Display resource (CPU/memory) usage of pods. It allows you to see the resource consumption of pods
Unclear whether it accepts namespace, context, or other parameters.
Parameter descriptions are generic or incomplete. E.g., 'namespace': 'Namespace (required for namespace-scoped resources)', does not clarify what 'namespace' is or how the tool handles cluster-scoped vs namespace-scoped. Baseline expects 100% of A-grade tools to have meaningful parameter descriptions.
Descriptions lack recovery guidance or prerequisites. E.g., 'Execute a command in a container' does not explain that the pod must be running, or what to do if it isn't. Per pattern, descriptions should state WHAT, WHEN, and prerequisites.
No visible error handling or error guidance in code sample. Tools likely return raw Kubernetes API errors (e.g., 'context not found') without actionable recovery hints. Per pattern, errors should tell the LLM what to try next.
Destructive tool delete_resource lacks confirmation or dry-run option. Agents can delete resources irreversibly without safeguard. Pattern recommends confirmation step for irreversible operations.
apply_resource accepts raw YAML/JSON 'manifest' as a single string parameter. No validation hints, schema constraints, or error guidance for invalid manifests. LLMs may pass malformed YAML, causing silent failures.
Pagination is not visible for list_resources and list_clusters. If these return large lists (100+ items), context window exhaustion and degraded LLM reasoning result. Baseline expects pagination support for list tools.