Loading ToolBench
MCP server that gives AI assistants a persistent, semantically searchable memory for each codebase — decisions, conventions, gotchas, notes.
Strong semantic memory tool suite with well-structured schemas and clear descriptions. All 7 tools have explicit input schemas with proper type definitions and parameter descriptions. Tool names follow verb_noun convention (remember, recall, list_memories, get_memory, update_memory, forget, stats). Descriptions are substantive (100-200 chars typical), explaining WHAT the tool does and WHEN to use it. Key strength: parameter constraints (enums for categories, min/max for limits, minLength/maxLength for content). Weakness: output schemas are not documented in the source, LLMs cannot see what fields recall() or list_memories() return, forcing inference. Error handling is basic (generic try-catch in index.ts returns only error message text, no recovery guidance). No tool annotations (readOnlyHint, destructiveHint) despite clear risk levels (WRITE, DESTRUCTIVE, READ_ONLY). Forget tool correctly requires confirm:true to prevent accidental deletion, but lacks explicit confirmation flow documentation.
Permanently delete a memory. Requires `confirm: true` to prevent accidental deletion.
Fetch a single memory by id, including all metadata.
List recent memories with optional filters (category, tags, since-date). Useful for browsing or pagination — not semantic search. For semantic search, use `recall`.
Semantic search across saved memories. Returns the most relevant memories for a query, ranked by cosine similarity. Use this before writing new code to surface relevant decisions, conventions, and gotchas.
Save a new memory about the codebase: a decision, convention, gotcha, note, todo, or bug-fix story. The memory is embedded and indexed for later semantic recall.
Get memory counts for the current (or specified) project: total, by category, last-7-days, last-30-days.
Output schemas not documented. LLMs cannot see what fields recall(), list_memories(), get_memory(), or stats() return. This forces inference and risks misuse of response data.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk levels declared in metadata. Clients cannot distinguish safe tools from destructive ones without parsing descriptions.
Error handling returns only error message text. No recovery guidance, error classification (retryable vs fatal), or actionable next steps. E.g., 'Error in recall: invalid query' tells LLM nothing about what to try next.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 54 | <=2025-11-25 | v2 |
Update an existing memory. If `content` changes, the memory is re-embedded automatically.
stats tool description is vague ('Get memory counts for the current (or specified) project'). Does not explain what 'counts' means (total? by category? time windows?). Baseline: descriptions should be 50-200 chars and answer WHAT, WHEN, and WHY.
get_memory description lacks context. Does not explain when to use it vs recall() or list_memories(). LLMs need explicit guidance on tool selection criteria.