Semantic Vector Memory for Coding Agents - Long-term context and fact tracking using vector embeddings and Qdrant
The Recall MCP server provides two well-motivated semantic memory tools with moderately good descriptions and reasonable schema coverage. Both tools have clear, substantive descriptions (250-350 chars each) that explain what they do and when to use them. ingest_memory includes thoughtful metadata guidance with examples. recall_memory has detailed mode explanations and filter options. However, there are notable gaps: parameter descriptions are present but inconsistent in detail; some schema types are defined but lack proper constraints; no explicit output schemas documented; and error handling lacks recovery guidance. The server demonstrates domain expertise in vector memory operations but falls short of production-grade tool quality standards. STDIO-only transport is a hard limitation.
Ingest content into semantic vector memory with optional event metadata. Automatically chunks content, generates embeddings, and stores with metadata for both semantic and temporal retrieval. RECOMMENDED METADATA STRUCTURE: event_type: "decision" | "discovery" | "milestone" | "preference" | "error" | "success" tags: "topic1,topic2,topic3" context: "Why this memory was created" outcome: "What happened or was decided" EXAMPLE - Decision Event: metadata = { "event_type": "decision", "tags": "architecture,embeddings", "context": "Comparing 4 embedding models", "outcome": "Selected Arctic for 93.3% accuracy" }
Search memory using semantic similarity OR temporal queries. SEMANTIC MODE (default): - Search by meaning: "What decisions about embedders?" - Supports hybrid mode with BM25 keyword boosting - Returns ranked results by relevance CHRONOLOGICAL MODE: - Search by time range (no query needed) - Filter by session, event type, tags - Returns results ordered by timestamp (newest first) HYBRID MODE: - Combines semantic + keyword search via Reciprocal Rank Fusion - Semantic scores reweighted by keyword match (BM25) - Best for mixed precision/recall queries
Output schemas not documented. ingest_memory and recall_memory have no declared return types, forcing LLMs to infer what fields are available.
recall_memory lacks constraints on numeric parameters. top_k and min_score (0-1) have no minimum/maximum bounds in schema or description. LLMs could pass top_k=0 or top_k=999999, or min_score=-5.
ingest_memory 'metadata' parameter is declared as 'object' with no schema. The description provides recommended structure but no enforcement. LLMs may pass arbitrary objects; suggested fields are not validated. JSON Schema should define properties, required fields, and types.
No error handling guidance. Neither tool documents what errors are retryable, how to recover from 'not found', or how to adapt if semantic search returns no results. Per pattern, 'Error responses must tell the LLM what to do next.'
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 63 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
recall_memory filters (time_range, event_types, tags) accept comma-separated strings but lack clear format specification. Time range example '2025-10-01,2025-10-11' is provided but not formally specified (is it ISO 8601? what about timezone?).
query parameter in recall_memory is marked 'required for semantic/hybrid, optional for chronological' but schema has no conditional logic or explanation of when it's truly optional. This undocumented dependency could cause LLM misuse.