Loading ToolBench
This server has significant structural and quality gaps. While all 7 tools have basic names and some descriptions, the quality falls well below production standards. Descriptions are present but often translated from Chinese with minimal English prose, parameter descriptions are sparse or missing, no output schemas are documented, and error handling is minimal. The tools lack clear guidance on when to use them, what they return structurally, or how to recover from failures. Input schemas are visible but lack detail. No tool annotations (readOnlyHint/destructiveHint/idempotentHint) despite clear risk levels. The server mixes READ_ONLY, WRITE, and DESTRUCTIVE operations without guardrails.
创建一个新的命名空间 Args: namespace: 命名空间名称
创建一个新的 Pod Args: pod_name: Pod 名称 namespace: 命名空间，默认为 'default' image: 容器镜像，默认为 'nginx'
删除指定的命名空间 Args: namespace: 命名空间名称
删除指定的 Pod Args: pod_name: Pod 名称 namespace: 命名空间，默认为 'default'
获取指定 Pod 的事件 Args: pod_name: Pod 名称 namespace: 命名空间，默认为 'default'
获取特定 Pod 的日志 Args: pod_name: Pod 名称 namespace: 命名空间，默认为 'default' tail_lines: 返回的日志行数，默认为 50
No documented output schemas. Tools return plain strings (e.g., 'Pod {pod_name} created in namespace {namespace}.') with no structure. LLMs cannot parse structured data, extract IDs for chaining, or understand what fields to expect. This violates pattern:response-shaper and pattern:tool.
Descriptions are minimal and translated from Chinese, lacking LLM-optimized guidance. E.g., delete_pod description (35 chars) does not explain that this operation is irreversible, cannot be undone, or what happens to the pod. Descriptions under 50 chars cannot provide sufficient context for tool selection (rubric baseline: avg 194 chars).
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite explicit risk levels in metadata (READ_ONLY, WRITE, DESTRUCTIVE). The FastMCP framework supports annotations, they should be added to each tool to signal to LLMs which operations are safe vs. risky. Missing pattern:tool-annotation.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 50 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 43 | - | v1 |
获取指定命名空间或所有命名空间的 Pod 信息 Args: namespace: 可选的命名空间名称，如果为 None 则返回所有命名空间的 Pod
Parameter descriptions are minimal or absent. E.g., 'namespace' parameter in get_pods says 'can be None to return all namespaces' but does not clarify format, constraints, or whether it accepts partial matches. Rubric baseline: 100% of A+ tools have described params.
No error recovery guidance. Error responses are generic (e.g., 'Error retrieving pods: {str(e)}'). LLMs receive no direction on whether to retry, call a different tool, or ask the user. Violates pattern:recovery-guide.
Destructive operations (delete_pod, delete_namespace) lack confirmation or dry-run patterns. An LLM can delete a pod with no reversible step or confirmation. Violates pattern:confirmation-request.
No pagination or result limits. get_pods and get_pod_events can return arbitrarily many records. Rubric baseline: tools returning lists should accept page/offset/limit and return a total. This violates pattern:paginated-result and risks exhausting context windows.
Tools return verbose unstructured text (e.g., get_pods joins pod details with '\n---\n'). This is error-prone for LLMs to parse. Should return structured JSON with typed fields (name, namespace, status, ip, node, created_at).
No idempotency guarantees. create_pod and create_namespace will fail if called twice with the same inputs (resource already exists). Tools should either be idempotent or clearly document non-idempotent behavior and recovery (e.g., 'Pod already exists, returning existing pod details').
Hardcoded defaults may not reflect user intent. create_pod defaults image to 'nginx' without explanation. Agents should be able to override this, and the description should clarify that the default is applied only if image is omitted.