Loading ToolBench
FastMCP server for KubeArchive - manage archived Kubernetes resources
The KubeArchive MCP server has significant gaps in definition quality. While all four tools have basic descriptions and input schemas are partially visible, the implementation reveals critical issues: (1) Three tools have minimal descriptions (10-20 chars); (2) Parameter descriptions exist but are sparse; (3) Output schemas are not documented, tools return strings (JSON serialized), not structured objects; (4) No error handling guidance for LLMs; (5) Tool naming is adequate but descriptions lack WHEN/WHY context; (6) No pagination support despite list_archived_resources accepting a limit parameter without offset/cursor; (7) The source code snippet is incomplete (cut off mid-context manager), preventing full validation of implementation details.
Get detailed information about a specific archived resource.
Get the historical timeline of a specific Kubernetes resource.
List archived Kubernetes resources from KubeArchive.
Search archived resources using a query string.
Tool descriptions are too short and lack WHEN/WHY context. 'Get detailed information about a specific archived resource' (56 chars) does not explain when to use this vs list_archived_resources, what structure is returned, or what prerequisites exist.
Output schemas are not documented. All tools return 'str' (JSON serialized), but LLMs cannot infer the structure of returned fields (names, types, nesting). This forces LLMs to parse unstructured text.
No error handling guidance. Tools raise generic exceptions ('Failed to list archived resources: {e}') without telling the LLM what to do next (retry, ask user, use a different tool). No categorization of errors as retryable vs fatal.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 47 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
list_archived_resources accepts 'limit' but provides no 'offset', 'cursor', or 'page' parameters. Without pagination metadata, LLMs cannot iterate through large result sets. Returns JSON array but no 'total_count' or 'next_cursor' field documented.
Parameter 'resource_id' (get_archived_resource) lacks format guidance. No description of what 'resource_id' looks like, how it's generated, or how to obtain it from list/search results. LLMs cannot reliably chain list → get calls.
No per-parameter constraints documented. 'limit' parameter has no min/max bounds stated in descriptions. 'query' parameter (search) has no length limit or format requirements. Unbounded inputs invite invalid LLM calls.
Hard-coded defaults and credentials in source. KUBEARCHIVE_API_BASE, KUBEARCHIVE_NAMESPACE, SERVICE_ACCOUNT are hardcoded; SSL verification is disabled ('verify=False') with a comment 'insecure but useful for dev/testing', unsuitable for production.