Local-first semantic memory server for AI agents. On-device LanceDB + Transformers.js, write-behind replication.
sovseal MCP server exposes 2 tools with basic schemas and descriptions. Naming follows verb_noun convention (store_memory, recall_memory), which is good. However, descriptions are sparse (12 - 17 words each), parameter documentation is minimal, output schemas are not documented, and error handling guidance is absent. The server lacks the LLM-optimized detail expected of production tools. Tool definitions are visible in source and properly registered, but quality falls in the D/C boundary due to incomplete parameter guidance and missing recovery instructions.
semantic search over the on-device store, top-K by L2
embed content and write to the on-device LanceDB store (write-behind; server replication runs asynchronously)
Descriptions are too brief (12 - 17 words) and lack LLM-actionable context. 'embed content and write to the on-device LanceDB store' does not explain WHEN to use this tool, what the async replication semantics are, or what happens on failure. Baseline for A-grade is 50 - 200 chars with clear intent, prerequisites, and recovery guidance.
Output schemas are not documented in source. store_memory and recall_memory return values are inferred from implementation (likely embeddings or memory IDs), but the tool definitions do not include explicit response types. LLMs cannot plan downstream calls without knowing what fields to expect.
Parameter descriptions are minimal or missing. recall_memory's 'topK' has a 2-sentence description (good), but store_memory's 'content' description does not specify format, length limits, or what constitutes valid embedding input. Baseline is a description per parameter stating format, constraints, and examples.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 39 | 2026-07-28+ | v2 |
No error handling guidance or recovery instructions. If store_memory fails due to LanceDB write errors or if recall_memory returns no hits, the LLM has no recovery path. Error responses should categorize failures (retryable vs. user-fixable) and suggest next steps.
store_memory description mentions 'write-behind; server replication runs asynchronously' but does not clarify consistency semantics or when data becomes searchable. An LLM may assume recall_memory can immediately retrieve just-stored content, causing incorrect behavior if replication lags.
recall_memory's topK parameter has a reasonable description but no explicit bounds (minimum 1, maximum 1000?). Unbounded numeric parameters let LLMs request absurd result counts that could break performance or memory limits.