The Memory System That Learns You Back - Hybrid semantic + WordNet memory search with CXD classification
MemMimic MCP server exhibits significant definition quality gaps across the board. While tool names are reasonably clear (verb_noun convention), the server suffers from: (1) MISSING or INCOMPLETE OUTPUT SCHEMAS, no tool documents what it returns, making downstream chaining impossible for LLMs; (2) PARAMETER DESCRIPTIONS present but often generic/vague, e.g., recall_cxd's 'db_name' lacks format guidance, limit defaults to 5 with no bounds stated; (3) NO ERROR HANDLING GUIDANCE, tools like delete_tale and delete_memory_guided offer destructive operations with no recovery hints or validation messaging; (4) COMPOSITION ISSUES, tales interface conflates list/search/load/stats into one tool (violates single-responsibility); (5) NO IDEMPOTENCY GUARANTEES, stateful operations like remember and save_tale risk duplicates on retry. The codebase shows tool registration via MEMMIMIC_TOOLS object with basic schemas, but the Python bridge abstracts actual implementation, making it impossible to verify error messages, data validation, or output structure. Per-tool analysis reveals naming is competent (18-25 chars, action verbs), but 4/13 tools have descriptions under 50 chars (status, analyze_memory_patterns), hitting the hard floor. Schema completeness ranges from 40-70% across tools, most properties defined but no 'required' arrays, type constraints, or output documentation.
Analyze patterns in memory usage and content
Generate narrative from memory fragments
Delete memory with guided analysis
Delete tale with confirmation
Load specific tale by name
Hybrid semantic + WordNet memory search with CXD filtering
Store information with automatic CXD classification
NO OUTPUT SCHEMAS DOCUMENTED. No tool declares what fields it returns. LLMs cannot plan downstream tool calls or extract required data (e.g., memory_id for update_memory_guided, tale_name for context_tale). This violates the core pattern:tool requirement and forces agents to infer structure from experience, leading to hallucinations.
MISSING ERROR GUIDANCE for destructive tools. delete_tale and delete_memory_guided offer confirmation flags but no documentation of error states, recovery paths, or what happens on failure. Per pattern:recovery-guide, errors must guide LLM to next action. Currently: no guidance.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 44 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 31 | - | v1 |
Auto-detect create or update tale
Engage in Socratic self-questioning
Get MemMimic system status and health
Unified tales interface: list, search, load, and stats
Process input with full contextual memory
Update memory with Socratic guidance
PARAMETER DESCRIPTIONS INCOMPLETE. 'db_name' in recall_cxd lacks format guidance; 'memory_id' in update_memory_guided/delete_memory_guided not described beyond type; 'style' in context_tale offers enum values (auto, introduction, technical, philosophical) but no explanation of semantic differences. LLMs cannot select style intelligently without guidance.
SINGLE TOOL WITH MULTIPLE RESPONSIBILITIES. 'tales' tool combines list + search + load + stats into one interface. Per pattern:tool, each tool should do exactly one thing. This forces LLMs to reason about which mode to invoke (via query/load/stats booleans) rather than selecting a dedicated tool.
VAGUE SHORT DESCRIPTIONS. 'status' has 27-char description 'Get MemMimic system status and health', useful but doesn't hint at return fields (is it uptime? memory usage? database state?). 'analyze_memory_patterns' is 40 chars, does it return charts, statistics, or text analysis? LLMs must guess.
MISSING BOUNDS ON NUMERIC PARAMETERS. 'limit' defaults to 5 or 10 but no max stated (can an LLM pass 10000?). 'max_memories' in context_tale defaults to 15 but no bounds. 'depth' in socratic_dialogue states 1-5 range but no validation docs. Per pattern:constrained-input, numeric ranges must be explicit.
NO IDEMPOTENCY GUARANTEES. 'remember' and 'save_tale' are stateful but no documentation of retry behavior. If an agent retries after a timeout, will it create a duplicate memory/tale or update the existing one? Per pattern:idempotent-operation, this must be explicit.
PARAMETER NAME AMBIGUITY. 'confirm' boolean in delete_tale and delete_memory_guided, does true mean 'skip confirmation' or 'confirm deletion'? Dual-meaning flags confuse LLMs. Should be 'skip_confirmation' or 'require_confirmation' for clarity.