Dual-memory system (episodic vector + semantic graph) with LLM reasoning for AI agents. CLI, MCP, HTTP API, WebSocket interfaces.
Engram-Mem provides 15 well-named tools with comprehensive descriptions and detailed parameter documentation. Most tools follow verb_noun naming conventions (engram_remember, engram_recall, engram_ask, etc.). Descriptions are substantive (150-300 chars typical), explaining not just what the tool does but when to use it and what it returns. However, critical gaps exist: (1) NO input schemas are visible in the source code, only docstring-style parameter documentation. The rubric requires JSON Schema with type definitions for proper validation and LLM parsing. (2) Output schemas are completely undocumented, tools return results but the exact structure is never formally declared. (3) Error handling is implicit in implementation but not documented in tool definitions. (4) No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite having clear READ_ONLY vs WRITE semantics. Tool definitions in episodic_tools.py, reasoning_tools.py, semantic_tools.py, and session_tools.py show solid naming and descriptions but lack the formal structure needed for reliable LLM integration at scale.
Add an entity node to the semantic knowledge graph.
Add a relationship edge between two entities in the knowledge graph.
Smart query that auto-routes to recall or think based on intent. Use this as the default entry point instead of engram_recall/engram_think. Questions with why/how/explain/compare → think (LLM reasoning). Simple keyword lookups → recall (vector search + federated).
Retrieve the full untruncated content of a specific memory by ID. Supports full UUID or 8-character prefix from engram_recall output.
Query the semantic knowledge graph for entities and relationships.
Search episodic memories by semantic similarity. By default returns compact format with 8-char ID prefix and 120-char preview. Use compact=False for full content, or engram_get_memory(id) for a single full entry.
No formal input schemas visible in source, tools defined via Python @mcp.tool() decorators with docstring parameters only. JSON Schema with types, constraints, and enums not present in code. This prevents reliable parameter validation and makes LLM tool calling less predictable.
Output schemas completely undocumented. Tools return results (dicts, lists, strings) but the exact structure of responses is never formally declared. LLMs cannot reliably parse or chain results without documented output types.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 55 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 55 | - | v1 |
Store a memory in engram's episodic (vector) memory.
Return context from recent past sessions to orient a new session. Call this at the start of a new session or after context compaction to recover what was done previously.
End the current session without a summary. Use engram_session_summary for structured closure.
Start a new memory session. All subsequent memories are tagged with session_id.
End the current session with a structured summary stored as a memory. This is the recommended way to close a session. The summary is stored as a DECISION memory for future context recovery.
Show engram memory statistics - counts for both episodic and semantic stores.
Summarize recent memories into key insights using LLM.
Combined reasoning across both episodic and semantic memory. Searches vector DB for relevant experiences, traverses knowledge graph for entity relationships, then synthesizes an answer using LLM.
Return chronological context: memories created around the same time as a given memory. Useful for understanding what was happening around a key event or decision.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear semantics. File episodic_tools.py marks engram_remember as WRITE and engram_recall as READ_ONLY, but this is metadata in code comments, not formal tool annotations. Agents cannot discover which tools are safe to retry or read-only without explicit hints.
Error handling not standardized. Implementation checks for invalid memory_type and returns error dicts, but error format is inconsistent and not documented in tool descriptions. Agents cannot reliably parse errors or know whether to retry, ask user, or give up.
engram_status tool lacks meaningful description (60 chars). Docstring is 'Show engram memory statistics - counts for both episodic and semantic stores.' Does not clarify when to call it vs other tools, what the output format is, or what insights it enables.
engram_ask and engram_think have overlapping purpose ('smart query' vs 'combined reasoning'). Tool descriptions mention auto-routing internally, but LLMs must choose between them upfront. No clear guidance on when to prefer one over the other.
No pagination or result limits documented for engram_recall, engram_query_graph, or engram_session_context. If these return hundreds of items, context window could be exhausted. Descriptions mention 'limit' parameter with defaults (5, 5, 20) but do not warn about max results or token costs.