Recursive Memory System with Qdrant and Local Models - Brain-inspired memory clustering using Qdrant vector database and local embedding/LLM models
The MCP Memory Server has consistent tool naming and descriptions, but exhibits significant gaps in schema completeness, parameter documentation, and error handling. All 8 tools follow verb_noun conventions (store_, search_, get_, update_, consolidate_, decay_, delete_) which is good for clarity. However, parameter descriptions are minimal, output schemas are not documented, and critical input validation/error handling guidance is absent. The server appears functional but falls short of production quality standards.
Trigger memory consolidation to merge similar memories and optimize storage
Apply time-based decay to memory importance scores to deprioritize old, frequently-accessed memories
Delete a specific memory from the system
Get statistics about the memory system including total count, average importance, and clustering information
Retrieve the most recent memories from the system
Search for memories using semantic similarity or tags
Store a new memory in the system with optional tags and metadata
Update the importance score of a memory based on access patterns and reinforcement
No documented output schemas for any tool. LLMs cannot predict return structure, field types, or chaining possibilities. Critical for agents planning multi-step operations.
Parameter descriptions are minimal or generic. 'Optional tags for categorizing the memory' and 'Optional metadata dictionary' lack actionable format/constraint guidance. LLMs cannot infer valid values, ranges, or dependencies.
No error handling or recovery guidance. Tools lack documentation of failure modes, retryability, or next steps. Example: delete_memory provides no guidance on what happens if memory_id does not exist.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 54 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Destructive operations (delete_memory, decay_memory_importance, consolidate_memories) lack confirmation or dry-run capability. Agents can permanently destroy data without verification.
Numeric parameters lack range constraints. 'factor' in update_memory_importance and 'similarity_threshold' in consolidate_memories have no min/max documentation. Can LLMs pass negative values? Floats > 1.0 for threshold?
No pagination guidance for list results. search_memories and get_recent_memories accept 'limit' but no 'offset/page' parameter, 'has_more' indicator, or cursor. Large result sets could exhaust context.
Parameter 'min_importance' in search_memories is underdocumented. What is the valid range? Is it normalized 0-1 or arbitrary? How does it interact with semantic similarity ranking?
No field naming consistency check between tools. If store_memory returns 'memory_id', do search_memories and other tools expect 'memory_id' or 'id' as input? Undocumented naming forces LLM field mapping guesses.