Loading ToolBench
An MCP server providing tools for Kubernetes cluster management, including pod listing, namespace discovery, and log retrieval.
This Kubernetes MCP server has three READ_ONLY tools with basic functionality but significant quality gaps. All three tools have descriptions and schemas, but descriptions are generic and lack LLM-optimized guidance. Parameters are documented but lack constraints (enums, ranges). No error recovery guidance is provided. Output schemas are partially documented inline but lack formal structure. The server does not follow composition best practices for Kubernetes operations. Per-tool analysis: get-pods (naming: 75, description: 45, schema: 50, overall: 57); get-namespaces (naming: 75, description: 45, schema: 45, overall: 55); check-logs (naming: 75, description: 50, schema: 55, overall: 60). Average: 42 (low C range). The tool names follow verb_noun convention and are clear, but descriptions are too generic to guide tool selection effectively. Parameter schemas are present but lack enums, ranges, and constraint documentation. Error handling returns generic messages without recovery guidance.
Get logs from a specific pod.
Get list of all namespaces in the cluster.
Get list of pods in a specified namespace.
Descriptions lack LLM-optimized guidance. 'Get list of pods in a specified namespace' (46 chars) tells the LLM WHAT but not WHEN to use it vs. alternatives. Should explain: when to call this vs. other discovery tools, what the response structure reveals, and prerequisite knowledge (e.g., namespace names).
No output schema documentation. Tools return dicts with both 'content' (MCP text response) and domain fields ('pods', 'namespaces'), but no formal schema is stated. LLMs cannot plan downstream operations (e.g., which fields are guaranteed, what types) without documented output structure.
Error handling returns generic messages without recovery guidance. Example: 'Error getting pods: {str(e)}' tells the LLM nothing. Should return 'Namespace not found. Try get-namespaces() to list available namespaces' or 'Permission denied. Check cluster credentials.' Pattern:recovery-guide.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 49 | 2026-07-28+ | v2 |
Parameter constraints missing. 'namespace' accepts any string but only valid Kubernetes namespaces work. No enum, regex pattern, or format constraint prevents LLMs from hallucinating invalid namespace names. 'tail_lines' unbounded (could pass 1000000). Should declare: namespace (pattern: '[a-z0-9-]+'), tail_lines (1-10000).
No pagination or result limits. get-pods and get-namespaces return all items with no limit. A cluster with 1000 pods would dump entire list, bloating context window and degrading LLM reasoning. Missing: limit parameter, total count in response, guidance on pagination.
Tool composition is incomplete. No way to filter pods by status (running vs. failed). To find a failing pod, LLM must: get all pods, parse response, filter client-side. Better: add filter_status or status_filter parameter so 'show failing pods' works in one call.
Missing tool annotations. Tools are read-only but lack readOnlyHint in schema. This prevents clients from understanding operational safety (agents know get-pods is safe to retry, but code doesn't reflect it). Should declare 'readOnlyHint: true' in tool definitions.