Loading ToolBench
MCP server that exposes Kubernetes operations as tools for Claude to manage Kubernetes clusters, pods, and cluster status
This Kubernetes MCP server has a mixed quality profile. All 4 tools are explicitly registered with names, descriptions, and schemas present. However, parameter descriptions are minimal or absent, output schemas are undocumented, and error handling provides no recovery guidance. The tool descriptions are adequate (50-100 chars) but lack context about when to use each tool vs. alternatives. No tool annotations (readOnlyHint, destructiveHint) are present despite clear risk profiles. The schema definitions exist but lack depth, most parameters have only type and default, missing format constraints, ranges, and detailed descriptions required by the rubric baseline (100% of A+ tools document return types; 100% of A+ tool params have descriptions). Error messages in the implementation return boolean success flags and generic error strings rather than actionable guidance.
Create a simple Kubernetes pod with the specified name and container image.
Delete a Kubernetes pod by name.
Get general Kubernetes cluster information and node status.
Get all pods in a Kubernetes namespace with their status.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk classification. delete_pod is DESTRUCTIVE but has no annotation; get_pods is READ_ONLY but unmarked. LLMs cannot infer safety properties from names alone.
Output schemas completely undocumented. All 4 tools return unstructured strings (e.g., 'str' type in main.py return annotations). The rubric baseline requires 100% of A+ tools to have documented return types. Agents cannot structure downstream calls or extract fields.
Parameter 'namespace' lacks detailed description in schema. Only states 'Kubernetes namespace' and provides default.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 53 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 49 | - | v1 |
Error handling returns only success/error tuples with generic error strings (e.g., 'Failed to create pod: {error}'). No recovery guidance. Try get_pods() to list existing pods.').
create_pod and delete_pod have no confirmation or dry-run option. Per pattern:confirmation-request, irreversible operations (delete, create in production K8s) should support a confirm step to prevent agent mistakes.
Tool descriptions lack 'WHEN to use' guidance. get_pods and get_cluster_info both report cluster state but descriptions do not distinguish when to call each. WHEN should the LLM call it instead of a similar tool? What does it return?'
create_pod 'image' parameter lacks validation constraints in description. Should specify format (e.g., 'Docker image reference, e.g. nginx:latest, gcr.io/project/image:tag') to guide LLM input.
No pagination support in get_pods. If a namespace has 100+ pods, returning all as unstructured text will blow context window. Per pattern:paginated-result, tools returning lists should accept limit and offset/cursor parameters.
No permission checks or audit logging. Per pattern:permission-gate and pattern:audit-trail, destructive tools (delete_pod, create_pod) should verify caller authority and log who did what, when, and why for compliance.