MCP AutoMem

Create a typed relationship between two memories. This builds a knowledge graph that improves recall by surfacing related context. **When to use:** - After storing a new memory: link it to related existing memories - When a bug fix relates to an original feature implementation - When a new decision updates or invalidates a previous one - To connect patterns with their concrete examples **Relationship types:** - RELATES_TO: General relationship (default) - LEADS_TO: Causal relationship (A caused B) - DERIVED_FROM: Implementation of a decision/pattern - EXEMPLIFIES: Concrete example of a pattern - EVOLVED_INTO: Updated version of a concept - INVALIDATED_BY: Superseded by another memory - CONTRADICTS: Conflicts with another memory - REINFORCES: Strengthens another memory's validity - PART_OF: Component of a larger effort - PREFERS_OVER: Chosen alternative - OCCURRED_BEFORE: Temporal ordering **Examples:** - associate_memories({ memory1_id: "bug-fix-123", memory2_id: "feature-456", type: "RELATES_TO", strength: 0.9 }) - associate_memories({ memory1_id: "new-decision", memory2_id: "old-decision", type: "EVOLVED_INTO", strength: 0.8 })

Check the health status of the AutoMem service and its connected databases (FalkorDB graph + Qdrant vectors). **When to use:** - Before a session to verify the memory service is available - When memory operations are failing unexpectedly - To check storage statistics **Example:** - check_database_health({})

Permanently delete a memory and its embedding. Use sparingly - consider updating instead. **When to use:** - Memory contains incorrect information that can't be corrected - Memory is a duplicate - Memory contains sensitive information that shouldn't persist - Memory is no longer relevant and clutters recall results **Example:** - delete_memory({ memory_id: "abc123" })

Search and retrieve relevant memories using semantic search, keywords, tags, time filters, and graph expansion. This is the primary tool for accessing stored knowledge. **When to use:** - At conversation start: recall context about the current project/topic - Before making decisions: check for past decisions on similar topics - When debugging: search for similar past errors and their solutions - When implementing: find established patterns and preferences - For complex questions: use expand_entities for multi-hop reasoning **Search strategies:** - Semantic: Use natural language queries like "authentication timeout issues" - Tags: Filter by project or category with tags: ["my-project", "bug-fix"] - Time: Use time_query for recency like "last 7 days" or "today" - Multi-query: Pass multiple queries in 'queries' array for broader recall - Multi-hop: Use expand_entities=true for questions requiring connected reasoning **Examples:** - recall_memory({ query: "database architecture decisions", tags: ["my-project"], limit: 5 }) - recall_memory({ queries: ["auth patterns", "login flow", "JWT tokens"], limit: 10 }) - recall_memory({ tags: ["bug-fix"], time_query: "last 30 days", limit: 5 }) - recall_memory({ query: "What is Sarah's sister's job?", expand_entities: true }) // Multi-hop - recall_memory({ query: "Python style preferences", language: "python", context: "coding-style" })

Store a memory with optional tags, importance score, and metadata. Use this to persist important information for future recall. **Content size guidelines:** - Target: 150-300 characters (one meaningful paragraph) - Maximum: 500 characters (auto-summarized if exceeded) - Hard limit: 2000 characters (rejected) - Format: "Brief title. Context and details. Impact/outcome." **When to use:** - After making a decision: store the reasoning and outcome - When discovering a pattern: store the pattern and where it applies - After fixing a bug: store the root cause and solution - When learning user preferences: store what they prefer and why **Examples:** - store_memory({ content: "Chose PostgreSQL over MongoDB for user service. Need ACID for transactions.", tags: ["architecture", "database"], importance: 0.9 }) - store_memory({ content: "User prefers early returns over nested conditionals in validation code.", tags: ["code-style", "preferences"], importance: 0.7 }) - store_memory({ content: "Auth timeout fixed by adding retry with exponential backoff. Root cause: flaky network.", tags: ["bug-fix", "auth"], importance: 0.8 })

Update an existing memory's content, tags, importance, or metadata. Use this to correct or enhance memories rather than storing duplicates. **When to use:** - To correct inaccurate information in a memory - To add tags that were forgotten - To adjust importance based on new understanding - To add metadata after the fact **Examples:** - update_memory({ memory_id: "abc123", importance: 0.95 }) // Increase importance - update_memory({ memory_id: "abc123", tags: ["project-x", "critical", "auth"] }) // Add tags - update_memory({ memory_id: "abc123", content: "Updated: PostgreSQL chosen for ACID + team expertise" })