Loading ToolBench
A hybrid SQLite + FTS5 + Vector-based memory server with LangChain embeddings for persistent fact storage, semantic search, and UCMF (Ultra-Compact Memory Format) encoding.
This STDIO-based memory server has solid parameter schemas for most tools, but critical gaps in descriptions, missing error handling guidance, and weak naming patterns significantly limit its quality. 11 tools total; 9 have reasonable schemas but only 6 have descriptions exceeding 20 characters. Tool names lack consistent verb prefixes, and descriptions rarely answer WHEN to use each tool or what happens on error. No output schemas are documented, and error recovery guidance is absent. This is a typical C-/D+ community server: functional but not production-grade.
Create a timestamped backup of the entire memory database and JSON snapshot.
Delete a fact by ID from all stores (facts table, FTS index, vectors, UCMF).
Export all facts in UCMF format (compact one-line-per-fact representation).
Retrieve a single fact by its canonical ID.
Retrieve memory system statistics including fact counts, database sizes, and index health metrics.
Import facts from UCMF format (one fact per line). Performs validation and upserts all facts.
List all facts in the database with optional filtering by type and tags.
One-time migration tool to import existing companion_memory.json into the new database system.
STDIO-only transport, not remotely accessible; cannot be used with hosted MCP clients
No output schemas documented for any tool. LLMs cannot plan downstream calls or extract structured data without knowing what fields to expect.
Destructive tools (delete_fact, restore_memory) lack confirmation/dry-run patterns and do not warn the LLM about irreversibility in their descriptions.
get_fact and delete_fact descriptions are under 20 chars and provide no context. Descriptions such as 'Retrieve a single fact by its canonical ID' do not explain when to use them vs search_facts, or what an ID looks like.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 42 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 39 | - | v1 |
Restore the memory database from a backup file (full database restore).
Hybrid semantic and keyword search over facts. Combines FTS5 sparse search with vector similarity ranking.
Store a single fact with full UCMF metadata into the memory system. Automatically generates embeddings and updates all indexes.
No error handling guidance in any tool description. When a search returns no results, or restore_memory fails, there is no explanation of what the LLM should do next.
Tool names lack consistent action verbs. 'migrate_json' and 'export_memory' are inconsistent in style; some tools lack leading verbs (e.g., 'backup_memory' and 'restore_memory' are OK, but 'get_stats' and 'get_fact' are overly brief).
'id' parameter in get_fact and delete_fact has no description. The 'id' field is opaque (SHA-1 hash substring), the LLM has no way to know where to get valid IDs without calling list_facts first.
list_facts and search_facts both retrieve facts. LLM may conflate them. Descriptions should clarify: search_facts uses hybrid semantic + keyword search (useful for natural language queries); list_facts filters by type/tags (useful for enumeration).
backup_memory and restore_memory have no output schema. What does backup_memory return? A file path? A backup ID? How does the LLM know what to pass to restore_memory?
migrate_json has no input parameters documented and no description. Is it a one-time call? What does it return? When should it be called? The name is opaque without context.