Loading ToolBench
MCP server providing hierarchical tree storage on top of Cloudflare KV with authentication-less access
Three tools are explicitly registered with basic type definitions, but the server exhibits critical gaps in definition quality. Tool descriptions are present but brevity-appropriate; parameter descriptions are adequate but lack constraint/format guidance. Input schemas use loose typing (String primitives instead of proper JSON Schema objects with type/description pairs). Output schemas are entirely undocumented, the tools return JSON.stringify() text wrapped in a generic content array with no formal schema declaration. Error handling is minimal, no recovery guidance, no categorization of failure modes. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) are present despite having clearly read-only and write operations. The server is HTTP-based and stateless, but lacks modern protocol features like per-request _meta logLevel, structured output declarations, and multi-round-trip request handling. Overall, this is a minimally functional MCP server with domain logic but insufficient production polish.
get the child nodes of a given path in the global kv storage
get a value at a given path in the global kv storage
store a value at the given path in the global kv storage
Input schemas use primitive String types instead of JSON Schema objects. Each tool parameter is declared as { path: String } or { path: String, value: String }, which bypasses proper JSON Schema structure (no 'type': 'string', no constraints like minLength/maxLength, no explicit 'description' field in the schema object itself). This forces LLMs to rely entirely on parameter names and context, not machine-readable constraints.
Output schemas are completely undocumented. All three tools return { content: [{ type: 'text', text: JSON.stringify(result) }] }, wrapping raw JSON strings with no formal declaration of what fields are inside. LLMs cannot predict the response structure and must parse unstructured text, risking errors and wasting tokens.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). getValue and getChildren are clearly read-only; setValue is clearly destructive. These hints help agents understand side effects and plan retry logic correctly.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 47 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 31 | - | v1 |
Error handling is generic and non-instructive. Tools do not validate inputs (e.g., path format, value encoding) before operating. If an operation fails (e.g., KV storage is unavailable), the error response is not documented. LLMs receive no recovery guidance or error classification (retryable vs. fatal).
Tool descriptions are correct in content but minimal (25 - 33 characters). 'get a value at a given path in the global kv storage' lacks context on WHEN to call this vs getChildren, what data format is expected, what happens if the path does not exist, or how errors are signaled.
Parameter descriptions lack format/constraint guidance. The 'path' parameter description ('The path in the KV tree to retrieve the value from') does not specify: is path a string? Does it use '/' separators like '/users/john' or '::' like 'users::john'? What happens if path is empty or undefined? (Code shows default to '/', but this is not documented.)
setValue returns a multi-field response (priorValue, stored, replaced) with no schema documentation. LLMs must infer the structure from context. If any field is null or missing under certain conditions, the agent has no advance warning.
No pagination, limits, or result count constraints documented. getChildren could theoretically return thousands of child nodes; the tool description does not specify a max or advise on pagination. Large result sets risk context window overflow.