Loading ToolBench
Standalone MCP memory server with embedded vector store for AI agents
llm-mem demonstrates solid tool definition quality with well-structured schemas and comprehensive parameter documentation. All three tools have properly typed JSON schemas with clear descriptions. The tool names follow verb_noun conventions (system_status, health_check, add_content_memory). Parameters are well-documented with types, descriptions, and appropriate defaults. However, there are notable gaps in error handling guidance, output schema documentation, and some parameter naming could be more explicit about type suffixes.
Add raw content to memory WITHOUT any AI transformation. The content is stored and embedded EXACTLY AS-IS, preserving all original phrases, keywords, and structure. Use this when: (1) you need EXACT PHRASE searchability - e.g., finding 'vegan chili' or '#PlankChallenge' later, (2) storing conversation logs, documents, or code snippets where original text matters, (3) you want predictable semantic search based on the actual content, not AI-extracted interpretations. For AI-processed structured facts and insights instead, use add_intuitive_memory.
Run an end-to-end check of the current configuration: validates the config, verifies build features match the configured provider, confirms required API keys are present, and probes the banks directory for write access. When `live=true`, it also issues a tiny embed("ping") and complete("...pong") against the configured backend to confirm the LLM and embedding endpoints actually respond. Use this at the start of a session (or whenever config changes) before relying on the system for real work. Static checks are free; live checks consume a few API tokens per call.
IMPORTANT: Call this tool first before any other tool. Returns the current status of the memory system including: backend type (local or remote), model availability and reachability, token usage statistics, model download status, and configuration details. It is preferable to use 'default' as the bank name for other tools, unless situations warrant otherwise.
Output schemas not documented. While input schemas are complete, tool response structures are not specified in the definition, forcing LLMs to infer what fields will be returned.
Error handling lacks recovery guidance. Tools do not document what errors are possible, which are retryable, or what the LLM should do next when a call fails.
add_content_memory combines multiple responsibilities: storing raw content, embedding it, linking to related memories, and handling metadata. This violates single-responsibility principle and could be split into separate tools.
Parameter 'metadata' in add_content_memory is declared as generic 'object' without specifying expected key/value types or structure. This lacks schema rigor and forces LLMs to guess valid metadata formats.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 63 | 2026-07-28+ | v2 |
add_content_memory's 'relations' parameter is an array of objects with 'relation' and 'target' fields, but no enum constraint on 'relation' type. This invites hallucinated relation types (e.g., 'parent_of', 'mentions', 'contradicts'), valid values should be enumerated.
Parameter descriptions for health_check's timeout fields (embed_timeout_secs, llm_timeout_secs) lack guidance on reasonable bounds (e.g., '5 - 60 seconds'). LLMs may pass extreme values.