Loading ToolBench
Model Context Protocol server for Cluster API (CAPI) management. Provides tools to list, create, delete, scale, and manage Kubernetes clusters using Cluster API with AWS infrastructure provider support.
The CAPI MCP server has 7 tools with basic verb-noun naming (list_clusters, get_cluster, create_cluster, etc.), which follows naming conventions. However, critical gaps undermine quality: (1) All tool descriptions are extremely brief (10-45 chars), falling below the baseline average of 194 chars and often below the minimum actionable length of ~50 chars; (2) Parameter descriptions are minimal or absent, most are 1-3 words, far below the baseline of 72 chars; (3) No output schemas are documented in the visible source; (4) No error handling guidance or recovery suggestions; (5) No parameter validation rules, enums, or constraints documented; (6) No idempotency hints on destructive operations; (7) Tool definitions appear only in test files (test/e2e/mcp_tools_test.go), making it unclear if these are the actual registered definitions or test mocks. This suggests tools may be inferred rather than explicitly registered, capping individual tool scores.
Create a new Kubernetes cluster using Cluster API
Delete a Kubernetes cluster
Get detailed information about a specific cluster
Retrieve kubeconfig for a cluster
Get list of nodes in a cluster
List all clusters in the CAPI system
Scale a node pool in a cluster
Tool descriptions are critically short (10-45 chars vs. baseline 194 chars). Examples: 'List all clusters in the CAPI system' (34 chars), 'Get detailed information about a specific cluster' (48 chars). These lack context for LLM selection and do not explain WHEN to use each tool, WHAT it returns, or prerequisites.
Parameter descriptions are minimal or generic. Examples: 'Name of the cluster to retrieve' (32 chars), 'Name of the cluster' (19 chars). Most lack format constraints, valid value ranges, or examples. Baseline is 72 chars minimum. No enums defined even where constrained values are obvious (e.g., kubernetes_version should enumerate available versions).
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 39 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 54 | - | v1 |
No output schemas are documented. Tool definitions show input schemas only (e.g., create_cluster has cluster_name, template_name, kubernetes_version, variables). Outputs are entirely undocumented, LLMs cannot plan downstream tool calls or know what fields to extract (e.g., what does create_cluster return? A cluster ID? Status? Kubeconfig?). Baseline: 100% of A+ tools have documented return types.
Destructive operations (delete_cluster, create_cluster) lack error handling guidance, confirmation patterns, and recovery suggestions. No dry-run or confirmation step. No guidance on what to do if deletion fails or succeeds. LLMs cannot recover from failures independently.
Tool definitions visible only in test files (test/e2e/mcp_tools_test.go). No explicit registration, schema definitions, or handler implementations visible in the provided source. This suggests tools may be inferred from tests rather than being the actual production definitions, making it unclear if these are mock schemas or real tool specs. Per scoring rules: 'If you cannot see the actual tool definition in the source (only inferred), cap that tool's overall at 50.'
No pagination support visible for list_clusters. The tool accepts no limit, offset, or cursor parameters. If the CAPI system has many clusters, a single call could return an unbounded list, exhausting context. Baseline: tools returning lists should accept page/offset and limit parameters.
No validation rules or constraints on numeric parameters. scale_cluster accepts 'replicas' with 'minimum: 0' in schema, but no maximum is defined and no description of the upper bound or practical limits. No guidance on what happens if replicas is set to 10000 or a negative number despite the schema.
create_cluster accepts a 'variables' object parameter with no schema definition, description of expected keys/types, or examples. LLMs cannot know what 'variables' contains or how to structure it. This is underdocumented composition.
No mention of which tools require authentication, permissions, or scope declarations. No audit trail guidance. Per pattern: 'Each tool should declare what permissions it requires (e.g. read:email, write:calendar). This enables least-privilege agent configurations and clear audit trails.'