Give Claude a perfect memory. Local-first MCP server with hybrid search (BM25 + semantic embeddings) and a lightweight knowledge graph for personal AI memory management.
Engram is a well-structured memory/knowledge-graph server with 18 tools covering entity management, memory persistence, and consolidation. Tool names follow verb_noun conventions (remember, recall, edit_memory, delete_memory, etc.), which is excellent. All 18 tools have descriptions present. Input schemas are fully defined with JSON Schema format, including type declarations and parameter descriptions. However, there are notable gaps: (1) Output schemas are NOT documented, the source shows tool definitions but no explicit return type specifications; (2) Error handling guidance is absent, tools do not indicate what errors are possible, how to recover, or whether operations are retryable; (3) Some parameter descriptions lack constraint details (e.g., 'limit' params mention defaults but no max bounds); (4) No confirmation/dry-run pattern for destructive operations (delete_memory, delete_entity, delete_relationship, merge_entities). Descriptions range from 60-180 characters, generally adequate but some could be more action-oriented. Tool composition is sound, each tool does one thing (respect single-responsibility principle). The knowledge-graph abstraction (entities, relationships, memories) is well-modeled. Transport is STDIO-only, which triggers a HARD CAP at 50 for protocolReadiness.
Run memory consolidation (requires ANTHROPIC_API_KEY). Synthesizes recent memories into digests and detects contradictions. This is like the brain's sleep consolidation process.
Create a new entity (person, organization, or place) in the knowledge graph.
Create a relationship between two entities. Example: 'Alice' works_at 'Google', 'John' lives_in 'Paris'.
Delete an entity and all its relationships from the knowledge graph.
Delete a memory permanently (soft-delete, recoverable from database backups).
Delete a specific relationship between two entities.
Output schemas not documented. Tools return data but the response format is never declared in tool definitions, forcing LLMs to guess expected fields and causing chaining failures.
Error handling guidance absent. No error descriptions tell LLMs what to do on failure (retry, ask user, give up). Tools lack recovery paths.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 63 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 26 | - | v1 |
Update an existing memory's content, importance, or emotional weight. Use when user corrects information or clarifies previous statements.
Detect potential duplicate entities in the knowledge graph based on name similarity.
Get the status of memory consolidation: unconsolidated memories count, digests created, unresolved contradictions.
Get detected contradictions in the memory system.
Get detailed information about an entity, including all observations (memories) and relationships.
Get statistics about the memory system: total memories, entities, relationships, storage usage, etc.
List memory digests (consolidated summaries of memory batches).
List all entities (people, organizations, places) in the knowledge graph. Optionally filter by type or search by name.
Merge duplicate entities by moving all observations and relationships from one entity to another, then deleting the source.
Search stored memories. Call this at the START of every conversation and before answering any question about the user, their preferences, history, people they know, or anything previously discussed. Also call before remember to avoid storing duplicates.
Store new information the user shares. Always call recall first to check for duplicates — if similar info exists, use edit_memory to update it instead. Extract entities (people, organizations, places) and relationships from the content. Workflow: recall → remember (if new) or edit_memory (if updating).
Update entity details such as name, type, or metadata.
No confirmation or dry-run pattern for destructive operations. delete_memory, delete_entity, delete_relationship, and merge_entities (irreversible) can be called directly without requiring confirmation, risking accidental data loss.
Parameter constraints underspecified. 'limit' parameters appear in list_entities, list_digests, get_contradictions without explicit maximum bounds (e.g., '1-50'). Also, 'importance' and 'emotional_weight' in remember accept 0-1 but lack concrete anchor guidance in descriptions.
STDIO transport only. Server is not remotely accessible and cannot work with hosted/cloud MCP clients. This is a HARD ARCHITECTURAL LIMITATION that caps protocolReadiness at 50.
Descriptions for destructive operations too brief. delete_memory ('Delete a memory permanently...') and delete_entity lack clear warnings about irreversibility and when to use edit_memory vs delete_memory.