Loading ToolBench
MCP server for Kubernetes cluster management with support for federation, CAPI workload clusters, OAuth authentication, and comprehensive kubectl-like operations
The server provides 24 tools with generally good naming conventions (verb_noun pattern throughout) and comprehensive parameter descriptions. All tools have descriptions ranging from 50-500+ characters, well above the minimum. Input schemas are explicitly defined with types and descriptions for all parameters. However, there are several quality gaps: (1) Output schemas are not documented, responses are inferred from context but not explicitly specified; (2) Some descriptions are verbose and could be optimized for LLM consumption (e.g., 'logs' and 'list' are 300+ chars); (3) Error handling guidance is minimal, tools do not specify what errors they return or how to recover; (4) Some tools like 'describe' lack any description entirely (19 chars minimum threshold violated); (5) Composition issues exist, tools like 'create', 'apply', 'patch' are well-designed, but 'port_forward' + 'stop_port_forward_session' + 'stop_all_port_forward_sessions' represent fragmented session management; (6) No security pattern documentation (scope declarations, permission gates, audit trail patterns). Overall, the tools are functional and well-named, but lack production-grade polish in error recovery, output documentation, and security patterns.
List available API resources in the cluster
Check if you have permission to perform an action on a Kubernetes resource. Use this before attempting operations to get clear feedback about permissions.
Check the health status of a CAPI cluster. Returns overall health, component status, and individual health checks.
Get detailed information about a specific CAPI cluster including metadata, status, labels, and annotations.
List all Workload Clusters managed by CAPI that you have access to. Returns cluster name, organization, provider, release version, status, and age. Results are limited by default; use filters or increase limit to see more.
describe tool has no description (19 characters shown, appears to be missing full description)
Output schemas are not documented. While input schemas are complete, responses lack documented structure. LLMs cannot plan downstream calls or extract required fields without explicit output schema documentation.
No error handling documentation. Tools do not specify what error conditions they return, what the error messages are, or what recovery actions the LLM should take. For critical tools like delete, patch, and exec, this is a significant gap.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 67 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 46 | - | v1 |
Resolve a partial cluster name pattern to its full identifier. Useful when you only know part of a cluster name.
Check the health status of cluster components. Returns overall status, component health, and a node list (capped by nodesLimit). Per-node conditions are omitted by default; set includeNodeConditions=true to include them.
Get the current Kubernetes context
List all available Kubernetes contexts
Switch to a different Kubernetes context
Execute a command inside a pod container
Get a specific Kubernetes resource by name. Namespace Handling: - For namespaced resources (pods, services, deployments): Uses 'default' namespace if not specified - For cluster-scoped resources (nodes, namespaces, PVs, clusterroles): Namespace is automatically ignored - The tool automatically determines resource scope via Kubernetes API discovery
List Kubernetes resources with optional filtering. Namespace Handling: - Namespaced resources (pods, services, deployments): Uses 'default' namespace if not specified - Cluster-scoped resources (nodes, namespaces, persistentvolumes, clusterroles): Namespace is automatically ignored - Use 'allNamespaces=true' to list namespaced resources across all namespaces - The tool automatically determines whether a resource is namespaced or cluster-scoped via Kubernetes API discovery Examples: - List nodes: {"resourceType": "nodes"} - List pods in default namespace: {"resourceType": "pods"} - List pods in kube-system: {"resourceType": "pods", "namespace": "kube-system"} - List all pods: {"resourceType": "pods", "allNamespaces": true} - List CAPI clusters: {"resourceType": "clusters", "apiGroup": "cluster.x-k8s.io"} Ordering: events are returned newest-first (by lastTimestamp, then eventTime, then firstTimestamp). To make that ordering real, an event query is scanned up to an internal ceiling of 5000 matching events before 'limit' is applied, so 'limit' selects the most recent activity rather than an alphabetical slice. If a scan reaches that ceiling the response says so under 'metadata.ordering' (or '_meta.hint' with fullOutput) and older events were not read — narrow the query with namespace/fieldSelector/labelSelector for a complete answer. Since recency ordering cannot be expressed as a server-side page position, an event query returns no 'continue' token; passing one falls back to unsorted API order. All other resource types are returned in the API server's own order (namespace/name), so 'limit' selects an alphabetical prefix, not the newest or the worst. Supports both server-side selectors (labelSelector, fieldSelector) and client-side filtering for advanced scenarios.
List all active port forwarding sessions
Get logs from a pod container
Port-forward to a pod or service
Stop all active port forwarding sessions
Stop a specific port forwarding session by ID
Descriptions lack recovery hints. Many tools (especially read-only discovery tools) have generic descriptions. Missing guidance like 'Call this after listing to get full details' or 'Try with a partial name if exact match fails' limits agent planning.
Fragmented port-forward session management. Three separate tools (port_forward, list_port_forward_sessions, stop_port_forward_session, stop_all_port_forward_sessions) lack compositional clarity. Missing guidance on when to call each and how they relate.
No security/permission documentation. Tools like delete, exec, and create carry significant risk but lack scope declarations (read:pod, write:pod), permission gate guidance, or audit trail patterns. No indication of what RBAC checks are performed server-side.
Idempotency and retry behavior undefined. Tools like create, apply, and port_forward do not clarify whether they are idempotent. Agents retry on ambiguous failures, lack of idempotency guidance risks duplicate side effects (e.g., multiple port forwards to the same destination).
Descriptions are verbose for some tools (logs, list, describe). Descriptions over 300 characters waste tokens and bury key details. The logs tool description, for example, is ~400 chars and could be split into a concise description + structured parameter docs.