Loading ToolBench
Local-first, zero-API memory for AI agents. Persistent, private, and yours.
Strong tool definitions with clear, agent-optimized descriptions (avg 180 chars, well within 10-1024 range). All 8 tools have explicit schemas with typed parameters and descriptions. Naming follows verb_noun convention (store_, search_, recall_, list_, update_, forget_). Error handling via _tool_boundary decorator converts exceptions to ToolError with recovery guidance. Key gaps: no tool annotations (readOnlyHint/destructiveHint), output schemas documented in docstrings but not in formal JSON Schema, and some parameter descriptions could be more prescriptive about constraints (e.g., min_score range 0.0-1.0 is stated but not enforced).
Permanently delete memories by tag and/or age. Use this to prune stale facts en masse — drop every memory tagged "scratch", or everything older than 90 days. At least one filter is required; an unfiltered call is rejected so the store can't be wiped by accident. Deletion is hard: matching rows are gone, not hidden.
Permanently delete one memory by id. Use this when a stored memory is wrong beyond correction, sensitive, or simply no longer wanted — prune it so stale facts stop outranking current ones. To fix a memory instead of deleting it, use update_memory. The delete is hard: the row is gone, not hidden.
Enumerate memories with tag filtering, ordering, and pagination. Use this to browse stored memories without requiring a search query — to audit memories, paginate through tag categories, or view memories in chronological or reverse-chronological order. Filtering and ordering only — no embedding model or scoring is used.
Report where memories are stored, how many there are, and which model is used.
Re-read a specific memory by id, or the most recent memories. Use this when you already know which memory you want (from a previous store_memory or search_memory call), or to catch up on what was recorded most recently. To find memories by meaning, use search_memory instead.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) in fastmcp registration. forget_memory and forget_memories are destructive but lack explicit annotation for agent safety.
Output schemas documented in docstrings but not formalized in JSON Schema. LLMs cannot parse return types from docstrings alone; formal schema enables downstream tool chaining and validation.
forget_memories requires at least one filter (tags or older_than_days) but no enum or explicit constraint in schema. Parameter descriptions state the requirement but schema validation is implicit.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 65 | 2026-07-28+ | v2 |
Find memories by meaning. Semantic search over everything stored, so "what database did we pick?" finds a memory that says "we went with SQLite". Results are ranked by similarity, highest first. To page through more matches, keep the same query and advance `offset` by `limit` — ranking is stable, so pages don't overlap or skip. An offset past the last match returns no results.
Save something worth remembering across sessions. Store durable facts, decisions, preferences, and project context — not transient chatter. The text is embedded locally so it can be found later by meaning, not just exact words.
Correct an existing memory in place. Use this when a stored memory is wrong — a misremembered decision, a misspelled name, a fact that has since changed. It edits the original record rather than adding a related one, and re-embeds the text so search finds the correction. Only the fields you pass are changed.
memory_stats description is minimal (8 words). Should explain what stats are returned and when to call it (e.g., 'Call to verify embedding model, storage location, and memory count before bulk operations').
No confirmation or dry-run pattern for destructive operations (forget_memory, forget_memories). Agents can permanently delete memories without a safety gate.