Loading ToolBench
MCP stdio server for Claude Code that provides memory search and storage capabilities. Allows Claude to search a user's memory store, save new memories, and manage project-specific context.
Two tools with complete JSON Schema definitions and detailed descriptions. memory_search has clear, actionable guidance (10-50 result limit, project scoping logic). memory_add is comprehensive with explicit type enum and supersedes pattern for deduplication. Both descriptions exceed 100 chars and explain WHEN/WHY to call. However, descriptions lack explicit error recovery guidance, and output schemas are not documented in the tool definitions themselves, LLMs cannot see what fields are returned. Parameter descriptions are strong (project scoping, type semantics), but no validation constraints (e.g., title length, content max size) are stated. Naming is verb-forward (memory_search, memory_add) and unambiguous.
Save a new memory to the store. You MUST call this proactively — don't wait for the user to ask. Save user corrections, project conventions, debugging findings, stated preferences, architecture decisions, workflow discoveries, and project state changes. A typical session should produce 3-10 memories. Be specific and include enough context that the memory is useful in future sessions. PROJECT SCOPING: If the memory is a user preference or cross-project rule (type=user/feedback/reference), leave `project` unset — it will be saved as global. If it's a specific fact about the current codebase (type=project), set `project` to the absolute git-root path of that project. Type=user is ALWAYS saved as global regardless. CORRECTING AN EXISTING MEMORY: if this memory corrects, replaces or updates one you just read, you MUST pass its id in `supersedes`. Writing a bare 'CORRECTION: ...' memory does NOT retire the old one — dedup will not catch it, because a correction is worded differently from what it corrects, and BOTH will keep being recalled as equally valid. Search first, then supersede.
Search the user's memory store using full-text search. Returns the top matching memories with snippets. Call this before any non-trivial task to retrieve relevant context, preferences, and past learnings.
Output schemas not documented. Tool definitions lack 'outputSchema' or return type documentation. LLMs cannot plan downstream calls or extract fields without seeing what memory_search returns (e.g., does it return id, title, content, score, project?) or what memory_add returns (confirmation, id, timestamp?).
No error recovery guidance. Descriptions state WHAT the tools do but not what to do if they fail. E.g., memory_search should document: 'If no results found, try broader keywords or check project scope.' memory_add should warn: 'If supersedes ID not found, the memory is saved as new.'
Parameter constraints missing. 'query' in memory_search has no length limit or format guidance. 'title', 'description', 'content' in memory_add have no max length, character restrictions, or validation rules. LLMs may pass oversized or malformed values.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 62 | 2026-07-28+ | v2 |
Pagination not explicit in memory_search. Description mentions 'top matching memories' and limit (default 10, max 50), but no 'offset', 'cursor', or 'total_count' documented. If results exceed 50, LLMs cannot iterate through all matches.
No tool annotations (readOnlyHint, destructiveHint). memory_search is read-only; memory_add is destructive (writes, can supersede). Explicit annotations in the tool definition help clients and LLMs understand safety and retry semantics.