Loading ToolBench
Kubernetes resource, log, and event query server. Provides AI assistants with access to Kubernetes resources, logs, and events through MCP tools.
The server defines two tools with clear read-only semantics and detailed descriptions. However, schema completeness is inconsistent. debug_read has reasonable input schema structure but lacks explicit type definitions for nested flag objects. debug_help has minimal schema. Descriptions are comprehensive and well-written (exceeding 100 characters), which is good for context, but parameter-level descriptions in the schema itself are generic. Error handling guidance is embedded in descriptions rather than structured into responses. The TSL query language documentation is excellent, but tool composition and output schema documentation are absent.
Get detailed help for debug_read subcommands. WHEN TO USE: Before calling debug_read, call debug_help("<command>") to learn the available flags and their meaning. Commands: get, list, logs, events Omit command for an overview of all subcommands.
Query Kubernetes resources, logs, and events. Use debug_help for flag details. Subcommands (pass as "command"): get Get a single resource (flags: resource, name, namespace, output, query) list List resources of a type (flags: resource, namespace, all_namespaces, selector, sort_by, limit, output, query) logs Retrieve container logs (flags: name, namespace, container, previous, tail, since, sort_by, output, query) events List Kubernetes events (flags: namespace, all_namespaces, resource, name, sort_by, limit, output, query) The "query" flag accepts TSL (Tree Search Language) syntax for filtering. IMPORTANT: Query field names must match the actual JSON object structure returned by the command. Use output=json without a query first to discover the available field paths for each resource type. Common field paths for pods: name, namespace, status.phase, metadata.labels, spec.nodeName, status.containerStatuses[0].restartCount Common field paths for events: type, reason, message, count, firstTimestamp, lastTimestamp, involvedObject.kind, involvedObject.name Shortcut fields: "name" and "namespace" are hoisted from metadata for convenience. Query examples: "where status.phase = 'Running'" Filter pods by phase "where name ~= 'nginx-.*' order by metadata.creationTimestamp desc" Regex match + sort "select name, status.phase where status.phase = 'Running'" Select fields (JSON output) "where type = 'Warning'" Filter events by type "where level = 'ERROR'" Log levels (always UPPERCASE) "where logger ~= 'plan.*'" Filter logs by logger (JSON/zap) "where raw_line ~= '.*search-term.*'" Full-text log search Examples: {command: "get", flags: {resource: "pod", name: "my-pod", namespace: "default"}} {command: "list", flags: {resource: "pods", namespace: "kube-system", query: "where status.phase = 'Running'"}} {command: "list", flags: {resource: "pods", namespace: "default", output: "json", query: "select name, status.phase"}} # Discover log field names — always start here {command: "logs", flags: {name: "deployment/my-app", namespace: "ns", tail: 5, output: "json"}} {command: "logs", flags: {name: "deployment/nginx", namespace: "default", tail: 200, query: "where level = 'ERROR'"}} {command: "logs", flags: {name: "deployment/my-app", namespace: "ns", container: "sidecar", tail: 50}} {command: "logs", flags: {name: "my-pod", namespace: "ns", output: "json", query: "select timestamp, level, message where level = 'ERROR'"}} {command: "events", flags: {namespace: "default", query: "where type = 'Warning'"}}
Input schema for debug_read.flags is weakly typed, declared as 'object' with no property schema, making it impossible for clients to validate or discover available flags programmatically. Flags like 'resource', 'name', 'namespace', 'query', etc. are documented in text but not in machine-readable JSON Schema.
Output schema is not documented for either tool. Clients cannot know what fields to expect in responses (e.g., does debug_read return raw kubectl output, parsed JSON, or a structured object?). This forces LLMs to reason about response structure without guidance and risks parsing errors.
Parameter descriptions in the schema are minimal ('Command-specific parameters (e.g. resource: 'pod', name: 'my-pod', namespace: 'default')'). Individual flags (resource, name, container, tail, etc.) lack their own descriptions, type information, valid value enums, and constraints.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 53 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 42 | - | v1 |
debug_help has trivial schema (command parameter only) with generic description. No enums, no constraint on valid commands (get, list, logs, events), no description of what 'omit command' does.
Error handling is not structured. Descriptions mention 'Use debug_help for flag details' and 'Query field names must match actual JSON object structure', but no tool returns structured error responses with actionable guidance (e.g., 'Invalid query syntax: expected WHERE clause. Try: where status.phase = "Running"').
No pagination or result limiting documented. If kubectl returns thousands of resources, no limit parameter or next-cursor mechanism is present, risking context window exhaustion.
Tool composition risk: debug_read output is raw kubectl/TSL results (text or JSON), but there is no explicit guidance on which fields are returned or how they chain to other tools. Example: if an LLM calls list with namespace='default', the response structure is opaque.