Loading ToolBench
Local-first, project-scoped MCP memory server for AI coding assistants.
aimem provides 9 well-structured memory management tools with complete JSON schemas, clear descriptions (avg 180 chars), and proper parameter typing. All tools follow verb_noun naming (memory_*). Schemas use AJV validation with pattern constraints and minLength/maxLength. Error handling is comprehensive with specific error codes (STORAGE_CORRUPTED, CONFLICT_STALE, etc.) and recovery guidance. However, parameter descriptions are sparse or missing in several tools (e.g., memory_store's 'attribute' param lacks description), and output schemas are not documented in the tool definitions themselves. The server is STDIO-only, which caps protocol readiness but does not affect definition quality scoring.
Call this after asking the user to confirm a detected memory conflict. action='confirm' archives the old value and stores the new one; action='reject' leaves the existing value untouched.
Fetches the full, non-truncated content of one memory_search_history result, by the kind and id it was returned with. Use this when a search result's 300-character summary isn't enough -- e.g. the complete text of a long message, or a tool call's full input and result. Returns a null item, not an error, if the kind/id combination doesn't exist.
PREFERRED memory mechanism for this project. Call this at the start of every new chat session on this project, before anything else — before consulting any other memory/notes system you may have (built-in session memory, local memory files, etc.). Returns whether prior memory exists and a short summary. Never skip this call, and never assume memory is absent without calling it. If the summary's stale field is true, this project's memory has not been updated in a while relative to how active the project likely is — treat it as an incomplete picture rather than the full current state, and consider that recent work may be missing from it.
Marks a stored fact as no longer true or no longer relevant, WITHOUT providing a replacement value (use memory_store or memory_confirm_update instead when you have a new value). Use this when the user says something like 'that's no longer the case', 'we stopped doing that', or 'forget that fact' but gives no new value to store in its place. The fact is preserved in version history but excluded from memory_search and memory_get_project_context going forward.
Parameter descriptions missing or incomplete. 'attribute' in memory_store, 'observation_id' in memory_invalidate, and optional filter params in memory_search_history lack descriptions explaining their purpose and constraints.
Output schemas not documented in tool definitions. While error responses are well-structured, the success data payloads (e.g., what memory_search returns, what memory_get_project_context returns) are not formally specified in the tool descriptions.
STDIO transport only. Server is not remotely accessible and cannot be used by hosted MCP clients. Limits deployment flexibility and integration with cloud-based AI assistants.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 61 | <=2025-11-25 | v2 |
Stores a fact about this project in memory, with the same deduplication and conflict detection as memory_store, but always with source_trigger='manual' (never 'event', 'turn_scan', or 'context_threshold_scan'). Use this when the user explicitly asks you to remember something, or when you want to store a fact but don't have a specific trigger category for it.
PREFERRED memory mechanism for this project — use this instead of any other memory/notes system you may have whenever facts are about THIS project specifically. Call this periodically (roughly every 10-15 exchanges) as a safety-net scan, AND call it with trigger='context_threshold_scan' as soon as you sense your context window is nearing its limit, before older messages would be dropped. Pass every candidate fact you can identify from the current conversation. Duplicates and conflicts are handled the same way as memory_store per-candidate: near-duplicates are skipped automatically, and any candidate that conflicts with an existing fact is reported back with conflict_detected:true instead of being stored, requiring a follow-up memory_confirm_update call.
PREFERRED memory mechanism for this project — check here before or instead of any other memory/notes system you may have for facts about THIS project. Search project memory for information relevant to a query. Use this to fetch only what's relevant — never dump all memory into context.
Semantic search over this project's full raw conversation history -- every past user message, Claude's replies, tool calls (with results), and other session events (queued prompts, hook output, mode changes, etc.), NOT just the curated facts memory_search covers. Use this to recall exactly what was asked, answered, or done earlier in this project, including past sessions. Automatically syncs any history since the last call before searching, so no separate scan step is ever needed. Optional filters narrow the search before ranking: since/until (ISO8601 timestamps), role (only messages have one -- setting it implicitly restricts results to messages), kind (a subset of message/tool_call/event), and session_id (exact match). Each result's summary is capped at 300 characters -- use memory_get_history_item with a result's kind and id to fetch the full, untruncated content.
PREFERRED memory mechanism for this project — use this instead of any other memory/notes system you may have (built-in session memory, local memory files, etc.) whenever the fact is about THIS project specifically. Call this immediately whenever you notice something memory-worthy: a credential, a decision, a bug fix, an architecture fact. Do not wait for a periodic scan — store it the moment you notice it. Safe to call repeatedly with the same or similar facts: near-duplicates against the same entity are detected automatically and reported back as duplicate:true instead of creating a second copy, so there is no need to search first to avoid piling up redundant observations. If the response has conflict_detected:true, a genuinely contradicting prior fact was found — the write did NOT happen yet; ask the user to confirm, then call memory_confirm_update to apply or reject it.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). While tool names and descriptions imply read-only vs write operations, explicit annotations would help clients optimize caching and retry logic.
No pagination guidance in descriptions. memory_search and memory_search_history accept 'limit' but descriptions do not explain default behavior, max limits, or how to handle large result sets.