Loading ToolBench
An MCP server that exchanges an incoming Athenz Access Token for a scope-narrowed one (via ZTS, over mTLS) before forwarding each tool call to the upstream docs API
Three tools with explicit schemas and descriptions, but significant gaps in parameter documentation and output schema clarity. Tool names follow verb_noun convention (get_, delete_, post_). Descriptions exist but are brief (34-89 chars) and lack actionable guidance. No output schemas documented. Error handling and recovery guidance absent. Naming is clear but descriptions fall short of the 50-200 char LLM-optimized baseline.
Delete a document with the specified ID from the API running on local Kubernetes. IMPORTANT: doc_id must be the numeric integer ID. If you only know the document name, call get_k8s_docs first to look up the ID, then use that integer ID here. Forwarded endpoint: DELETE /api/docs/{doc_id}
Get the list of documents from the API running on local Kubernetes. Forwarded endpoint: GET /api/docs
Post a new document to the API running on local Kubernetes. Forwarded endpoint: POST /api/docs
Parameter descriptions missing. Input schemas define types (integer, string) but lack descriptions explaining what each parameter controls. 'doc_id' and 'name'/'content' have no guidance for the LLM.
Output schemas not documented. No specification of what fields get_k8s_docs returns, what delete_k8s_doc confirms, or what post_k8s_doc yields. LLM cannot plan downstream calls or extract required data.
Tool descriptions too brief and lack context. 'Get the list of documents' (34 chars) and 'Post a new document' (45 chars) do not explain WHEN to use each tool, what the response contains, or dependencies. Baseline is 50-200 chars for LLM-optimized descriptions.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 60 | <=2025-11-25 | v2 |
No error handling or recovery guidance. Descriptions do not explain what happens on failure (e.g., 'If doc_id not found, call get_k8s_docs first'). No actionable error messages documented.
delete_k8s_doc lacks confirmation/dry-run pattern. Destructive operations should support a confirmation step to prevent accidental data loss. No mention of idempotency or retry safety.