Loading ToolBench
Persistent project-aware memory for AI coding tools. Built on MCP. Knows your project, remembers your decisions, costs almost nothing.
Locus Memory presents a well-intentioned memory system with 17 tools covering exploration, search, recall, and lifecycle operations. However, the implementation has several material gaps that prevent it from reaching production quality. All tools have descriptions and visible input schemas in the source code (packages/core/src/server.ts), which is a strong foundation. The naming convention is consistent (memory_* prefix), making discovery straightforward. However, parameter descriptions are sparse or missing in several cases, output schemas are not documented, and error handling guidance is absent. The tool portfolio is well-composed, each tool has a single responsibility, but several tools combine read and write operations in ways that could be split (e.g., memory_config can both get and set). The semantic search and recall tools are sophisticated, but their parameter documentation (e.g., what exactly does 'semantic' search do vs. 'full-text'?) is underdeveloped. Average tool score across the 17 is 62, anchored by strong naming and schemas but held back by incomplete descriptions, missing output documentation, and no error recovery guidance.
Audit the memory database for integrity and consistency issues
View memory events grouped by date calendar with event counts
Compact the memory database to reduce size and improve query performance
Get or update Locus server configuration settings
Run diagnostics on the Locus installation and database
Explore memory at a given path in the project structure
Delete memories from the database by event ID or filter criteria
Output schemas not documented. The server code defines input schemas but does not expose output/response schemas for any tool. LLMs cannot plan downstream operations or extract fields without knowing what fields are returned.
Parameter descriptions are sparse or absent. Many parameters lack explanation of their purpose, constraints, or expected values. For example, memory_search's 'limit' param is described only as 'Max conversation results (default 20)', no explanation of what values are valid or why 20 is the default.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 59 | <=2025-11-25 | v2 |
Import Codex CLI skill definitions and session data into Locus memory
Get the current state of the project (files, dependencies, structure)
Completely erase all memory data from the database
Recall memories using semantic and episodic memory layers with question-based retrieval
Explicitly store a memory entry into episodic memory
Review recent events in the memory database with optional filtering
Scan the project for code exports, imports, and dependency relationships
Search memory with semantic and full-text search, with optional filters by time range, file path, event kind, or source
Get current status of the Locus memory system (file count, database size, ingest metrics)
View events organized by time buckets (days, weeks, or months)
Destructive operations (memory_forget, memory_purge) require a 'confirm' parameter but do not explain what confirmation token is expected, how to obtain it, or what format is valid. This creates ambiguity, an LLM does not know whether 'confirm' expects a yes/no string, a UUID, or a specific phrase.
No error handling guidance. The server does not document what errors each tool can return, whether they are retryable, or what the agent should do on failure. E.g., if memory_scan fails due to a timeout, should it retry, fallback to a different strategy, or report to the user?
memory_config has dual responsibility: it can both retrieve and modify configuration. This violates single-responsibility principle, the tool should be split into memory_get_config (read-only) and memory_set_config (write). This clarity helps LLMs avoid accidental config mutations.
memory_search and memory_recall both accept timeRange with identical structure (from/to/relative) but the description and usage nuances are not clearly differentiated. Why call memory_recall instead of memory_search? When should LLMs prefer one over the other?
Semantic search behavior is opaque. memory_search description says 'semantic and full-text search' but does not explain the ranking algorithm, what embeddings are used, or whether the LLM can tune the search strategy (e.g., weight toward semantic vs. lexical).
memory_scan accepts 'strategy' enum (full, git-diff, mtime) but does not explain the trade-offs: latency, coverage, or when to pick which. Agents will guess, documentation should guide the choice.