Loading ToolBench
AI Memory Infrastructure - Persistent memory for AI agents with semantic search, vector indexing, and advanced memory management
Engram MCP exposes 8 memory management tools with reasonable naming conventions and descriptions. All tools follow a consistent `memory_*` prefix pattern. However, critical gaps exist: (1) Most tools lack explicit input schemas in the source code provided, we see parameter names and descriptions in file references, but not full JSON Schema definitions with type constraints. (2) Several parameter descriptions are generic or lack detail about constraints (e.g., 'compress' boolean lacks guidance on when to use it). (3) No tool registration code or output schema documentation is visible. (4) Error handling guidance is absent, no recovery hints or actionable error responses defined. The tools address a coherent domain (semantic memory), and compositions chain well (e.g., memory_observe_tool_use feeds into memory_search), but definition quality trails production baselines due to incomplete schema visibility and missing error strategy.
Archive a tool's full raw output as an Episodic memory and return a compact summary
Create a new memory entry with semantic embedding
Retrieve context neighbors of a memory using semantic relationships
Retrieve a specific memory by ID
Retrieve the full raw output for a previously archived tool output
Assemble a structured working-memory markdown block for the current session
Input schemas are not explicitly visible or complete. Parameter names and descriptions are present, but no formal JSON Schema type definitions, ranges, or enums are shown in source code. This violates pattern:constrained-input and blocks validation.
No output schemas documented. Tools return structured data (memories, summaries, markdown), but the response format is not formally specified. LLMs cannot plan downstream operations without knowing field names and types.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 60 | 2026-07-28+ | v2 |
Observe and record a tool invocation as an Episodic memory
Search memories using semantic similarity
Numeric parameters lack ranges or bounds. 'limit' in memory_search, 'radius' in memory_expand, 'summary_tokens' in memory_archive_tool_output, and 'token_budget' in memory_get_working_memory have no documented min/max. Unbounded integers risk excessive results, timeouts, or token waste.
Error handling is not documented. No recovery guidance defined for missing IDs, invalid parameters, or service failures. Tools lack error classification (retryable vs user-fixable vs fatal) required by pattern:recovery-guide.
Optional parameters with defaults may hide side effects. memory_observe_tool_use defaults compress=true; memory_archive_tool_output defaults compress_summary=true. If defaults are lossy (e.g., data truncation), LLMs may omit the parameter and unexpectedly lose information. Pattern:default-values requires explicit cautioning.
No pagination guidance for memory_search. If searches return hundreds of results, LLM context window is exhausted. Pattern:paginated-result requires offset/limit and total counts. No indication whether search respects limit parameter or returns all matches.
Parameter ambiguity for memory_expand. 'radius' numeric unit is unclear, hops? semantic distance? Token range? LLM cannot infer appropriate values. Pattern:tool-description requires explicit format/range guidance.
memory_observe_tool_use and memory_archive_tool_output include 'session_id' parameter with default 'unknown'. Ambiguity: if omitted, how do agents later retrieve tool observations for a session? The default may silently lose session context. Pattern:tool-description requires explicit guidance on defaults.