Loading ToolBench
MCP server for managing Kubernetes cert-manager resources
This server exhibits poor definition quality across multiple dimensions. Tool names follow verb-noun convention adequately (all start with verbs: list_, get_, renew_, switch_). However, descriptions are generic and lack actionable guidance for LLM selection. Input schemas are present but minimal, most parameters lack detailed type constraints, enums, or formatting guidance. Output schemas are completely undocumented, forcing LLMs to guess at response structure. Error handling is absent from visible code. The server implements a narrow domain (Kubernetes cert-manager) with 8 tools, but the definitions do not meet production quality standards for agent integration. Critical gaps: no output schema documentation, minimal parameter descriptions, no error recovery guidance, no per-parameter validation rules visible.
Get details of a specific certificate
Get the current active Kubernetes context
List certificates in Kubernetes cluster
List all available Kubernetes contexts
List cert-manager issuers
List all Kubernetes namespaces
Renew a certificate by triggering cert-manager renewal
Switch to a different Kubernetes context
No output schemas documented. LLMs cannot infer response structure, forcing them to guess which fields are returned and their types. For example, list_certificates likely returns a list of Certificate objects, but the exact fields, types, and nesting are invisible to the agent.
Parameter descriptions are generic and lack actionable guidance. E.g., 'Kubernetes namespace to list certificates from' does not explain what happens if the namespace does not exist, whether wildcard patterns are supported, or what the default is if omitted. LLMs cannot disambiguate or plan recovery.
No error handling guidance. If list_certificates returns empty, is it because the namespace does not exist, or are there simply no certificates? If renew_certificate fails, what should the LLM try next? No recovery paths visible.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 42 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 35 | - | v1 |
No pagination support visible for list_* tools. If a Kubernetes cluster has hundreds of certificates, how are results limited? No limit, offset, or cursor parameters present. LLMs may fetch massive responses that exhaust context.
Destructive and write operations (renew_certificate, switch_context) lack confirmation or dry-run support. An LLM could accidentally trigger certificate renewal or context switch without user approval. No idempotency hints or confirmation patterns visible.
Tool descriptions are too short (30-35 chars typical). Baseline from rubric is 194 chars average, p90=392. Descriptions under 50 chars cannot convey WHAT, WHEN, and PREREQUISITES. E.g., 'List all Kubernetes namespaces' is terse; it does not explain when an LLM should call this instead of list_contexts, or what the response structure contains.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). The server declares READ_ONLY and WRITE risk labels in metadata, but these are not exposed to the MCP protocol as tool annotations, limiting agent-side safety constraints.
Parameter names do not include type suffixes. E.g., 'context' could be a string ID, a name, or an object. The rubric recommends 'context_name' or 'context_id' for clarity. Ambiguous names force LLMs to reason about type mapping.