Loading ToolBench
A secure database server for storing LLM memories with content validation
LLM Safe DB is an HTTP-based memory store with 6 tools. Naming is verb-forward and clear (store, get, search, validate, check). Most tools have descriptions (50-150 chars) and structured JSON Schema inputs with type definitions and constraints. However, descriptions lack LLM-optimization guidance (e.g., 'When to use instead of...' and 'Returns' sections), some parameter descriptions are minimal, and output schemas are not documented in code. Error handling exists but is generic. No tool annotations present. Overall, this is competent but lacks the depth expected of production-grade memory tools.
Get memories for a user or session
Get validation statistics
Health check endpoint
Search memories by keyword (similar to memory-mcp)
Store a new memory after validation
Validate content without storing it
Output schemas not documented in code. No visible return type documentation for any tool. LLMs cannot plan downstream tool calls or extract needed fields without knowing what structure is returned.
Tool descriptions lack LLM-optimization guidance. Missing 'When to use', context about prerequisites, and what the tool returns. E.g., storeMemory says 'Store a new memory after validation' but does not explain: What happens to duplicates? What does success return? What validation rules apply?
searchMemories has inconsistent parameter type for 'limit': described as string in schema but should be integer (matching getMemories). This type mismatch invites LLM confusion.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 52 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 36 | - | v1 |
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) present. LLMs cannot distinguish which tools are safe to retry, which modify state, and which are read-only without explicit marking.
Parameter descriptions in searchMemories and validateContent are terse (under 50 chars) and lack constraint details. E.g., validateContent says 'Content to validate (required, must be a string)' but does not mention length limits, character restrictions, or what validation actually checks.
Error handling is generic (controller catches exceptions, returns 'Internal server error'). No recovery guidance (e.g., 'Try again', 'Call search_memories first', 'Invalid constraint: X must be Y'). LLMs receive no actionable feedback.
No documented parameter relationships. E.g., userId and sessionId are both optional in getMemories and searchMemories, but it's unclear if both, one, or neither are required. LLMs must guess the intent.
storeMemory description does not indicate it modifies state. LLMs need to know which calls are idempotent and which are not to plan retries safely.