Loading ToolBench
MCP server for Kubernetes support bundles
Server provides 6 tools for Kubernetes support bundle analysis. Tool definitions include names, descriptions, and input schemas. Strengths: action verbs in naming (initialize_, list_, kubectl, read_, grep_), detailed descriptions with usage context and examples, consistent schema structure with type declarations and descriptions. Weaknesses: missing descriptions for several parameters across tools (verbosity appears in all tools but lacks explanation in schema), output schemas not documented, error handling guidance absent, no explicit response structure definitions. Tools follow a single-resource pattern well but lack inter-tool chaining guidance.
Search for patterns across files in the initialized support bundle. This tool searches through bundle files using grep-like pattern matching. PATTERN MATCHING: Supports standard regex patterns. Use grep_files to efficiently search large bundles without reading entire files. SCOPE: By default, searches the entire bundle. Optionally specify a subdirectory to limit the search scope. OUTPUT: Returns matching lines with file paths and line numbers for context.
Initialize a Kubernetes support bundle for analysis. This tool loads a bundle and makes it available for exploration with other tools. BUNDLE PERSISTENCE: Once initialized, a bundle remains active for all subsequent tool calls (kubectl, list_files, read_file, grep_files) until a different bundle is initialized. You don't need to re-initialize the same bundle repeatedly. Use `force=true` to switch to a different bundle or to reload the current bundle. Previously downloaded bundles can be quickly re-initialized by providing their path.
Execute kubectl commands against the Kubernetes cluster in an initialized support bundle. This tool allows you to query and inspect Kubernetes resources using standard kubectl syntax. EXECUTION CONTEXT: The command runs against the kubeconfig embedded in the active bundle. The bundle must be initialized first using the initialize_bundle tool. COMMAND EXAMPLES: - `kubectl get pods` - List all pods in default namespace - `kubectl get pods -n kube-system` - List pods in a specific namespace - `kubectl describe pod <pod-name>` - Get detailed information about a pod - `kubectl logs <pod-name>` - Get logs from a pod - `kubectl get nodes` - List cluster nodes - `kubectl get events` - Show cluster events
Output schemas not documented. Tools return TextContent responses but LLM context lacks clarity on field structure, pagination, or data format (e.g., does grep_files return line numbers, file paths, both?). This forces LLMs to infer response structure from examples rather than formal specs.
Parameter 'verbosity' appears in all 6 tools but lacks schema-level descriptions. Tools accept 'minimal|standard|verbose|debug' but the enum constraint and purpose are only visible in tool descriptions, not in input schema. Enum values should be formally declared in schema.
No error recovery guidance. Error descriptions (BundleManagerError, FileSystemError, KubectlError) are not visible in tool definitions. When operations fail, LLM receives no guidance on whether to retry, request user input, or invoke an alternative tool.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 57 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 36 | 2024-11-05+ | v1 |
List previously downloaded/initialized support bundles stored locally. This tool shows bundles that have been downloaded or initialized before and are available in local storage for quick re-initialization.
List files in the initialized support bundle. This tool shows the directory structure and available files for exploration. FILE EXPLORATION: Use this tool to discover what files are available in the bundle, then use read_file or grep_files to examine their contents. PATH HANDLING: Provide the path relative to the bundle root (e.g., 'cluster-resources/pods' or 'host-resources'). Use '/' or an empty string to list the root directory.
Read the contents of a file from the initialized support bundle. FILE READING: Reads the complete contents of the specified file and returns it as text. Use list_files first to discover available files. PATH HANDLING: Provide the path relative to the bundle root (e.g., 'cluster-resources/nodes/nodes.json'). FILE SIZE LIMITS: If a file is too large, the tool will return a truncation message with guidance on using grep_files or other tools for analysis.
No inter-tool chaining support. initialize_bundle description mentions 'bundle persistence' for subsequent calls but does not explicitly state what tools depend on it or what identifiers (e.g., bundle_id) are needed. No guidance on tool ordering or prerequisites.
Size limiting mentioned in code but not in tool definitions. read_file and grep_files mention truncation behavior in descriptions but do not declare max file size or result limits. LLMs cannot plan around size constraints they don't see.
Path parameter validation not explicit. list_files, read_file, and grep_files accept 'path' parameters with descriptions mentioning 'relative to bundle root' but no validation rules (e.g., must not contain '..', max length). LLMs can pass invalid paths.