Loading ToolBench
User-owned, cross-agent AI memory — open-source memory MCP server. Exposes the Cortex memory engine as MCP tools so ANY MCP client gets persistent, cross-session memory with BYOK (bring your own key), local SQLite DB, and zero phone-home.
Cortex Protocol demonstrates solid tool design with clear, domain-specific naming and comprehensive descriptions. All 6 tools have well-articulated purposes and parameter descriptions. However, input schemas lack formal type constraints (no enums, no min/max bounds), and output schemas are not documented. Error handling guidance is minimal. The memory-centric domain is well-served by the tool set, but schema rigor and error recovery patterns fall short of A-grade production standards.
Delete a memory by ID. Permanently removes a saved memory from the store.
List all memories (paginated). Returns a paginated list of all saved memories with optional filtering by kind or tags.
Save a durable memory for the user (facts, preferences, decisions, project context worth remembering across sessions). Optionally set `kind` to the ONE that best classifies it: preference = how the user likes the agent to behave; fact = stable info about the user or world; project = ongoing work; instruction = a hard rule to always follow; event = a dated thing that happened; relationship = a person the user knows. Optionally attach short `tags`. Do NOT store secrets.
Retrieve relevant memories by semantic similarity to a query. Returns the top-k most relevant memories ranked by relevance (not date). Use at the start of a task to load anything relevant you may have saved before.
Exhaustive dossier about ONE specific entity — a person, place, project, org, thing, or the user themselves. Use for 'tell me everything about X', 'what do you know about my ⟨…⟩', or 'who is X'. Returns the entity, its labeled relationships (both directions), and every memory about it — the full enumeration that ranked `recall` can't give. For a single fact or fuzzy lookup use `recall` instead. Requires write-time graph extraction (set CORTEX_GRAPH=1); with it off no entities are built and this returns an entity-graph-disabled notice.
No output schemas documented. LLMs cannot predict response structure (fields, types, pagination). Downstream tool chaining and result parsing require guesswork.
Input schemas lack formal constraints. 'kind' parameter accepts free-form strings instead of enum (preference|fact|project|instruction|event|relationship). 'limit' and 'offset' in list_memories have no min/max bounds. LLMs can pass invalid values.
recall_about and recall_timeline describe feature flags (CORTEX_GRAPH, CORTEX_EPISODIC) but do not guide LLM recovery if features are disabled. Error responses should suggest enabling flags or using fallback tools.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 59 | 2026-07-28+ | v2 |
List memories on a timeline by WHEN each event happened (episodic recall) — oldest→newest, undated items last. Use for time-scoped or 'what happened' questions ('what happened last week', 'my history with X', 'when did I …'). Optional ISO-8601 `since`/`until` (YYYY-MM-DD) bound the range. Requires write-time episodic extraction (set CORTEX_EPISODIC=1); with it off no events are dated and this returns an empty-timeline notice.
forget tool lacks confirmation or dry-run pattern. Destructive operations should support a confirmation step to prevent accidental data loss when agents make mistakes.
list_memories description does not specify result limit or pagination behavior. Baseline rubric requires stating limits (e.g., 'Returns up to 50 memories per page') to prevent context window exhaustion.