Loading ToolBench
MCP server for per-project, in-repo memory system for Claude Code. Provides tools for searching, reading, writing, and managing project memory organized in tiers (project/local/user). Implements full CLI parity with thirteen tools: read tools (mk_search, mk_get, mk_timeline, mk_expand, mk_links, mk_cite, mk_recent_activity) and write/mutate tools (mk_remember, mk_trust, mk_lessons_promote, mk_forget, mk_queue_list, mk_queue_resolve).
The core-memory-kit MCP server demonstrates good definition quality with well-structured tool schemas and comprehensive descriptions. All 13 tools have detailed parameter schemas with proper enum constraints and pattern validation. Descriptions are thorough and explain WHEN/HOW to use each tool. However, some parameter descriptions could be more specific about ranges and edge cases, and output schemas are not explicitly documented. The toolkit has strong logical coherence around memory operations (search, retrieve, write, manage) with clear naming conventions (mk_* prefix). Error handling descriptions are present but generic. The server follows the verb_noun pattern well (search, get, expand, links, cite, timeline, remember, trust, promote, forget, queue_list, queue_resolve). A notable strength is the detailed parameter constraints (tier enums, ID patterns, trust levels) which guide LLM behavior effectively.
Generate a citation for a fact. Returns a formatted citation with ID, title, and metadata suitable for embedding in other documents.
Expand a fact with additional context. Retrieves the full observation with all linked facts, backlinks, and related observations.
Delete or tombstone a fact from memory. Marks the observation as deleted and removes it from search results.
Retrieve a single observation by its ID. Returns the full fact with all metadata, linked references, and related facts.
Promote a lesson from the project memory to the user's persona (user-tier lessons). Makes the lesson persistent across all projects.
Query the relational graph of facts and anchors. Retrieve backlinks (what points to a fact), forward links (what a fact links to), and cite relationships. Supports both fact IDs and document anchors (D-nnn, Task-nnn, ADR-nnnn, FR-nn, NFR-nn).
Output schemas not documented. While input schemas are well-defined, return types for all 13 tools lack explicit documentation. LLMs cannot reliably plan downstream operations without knowing what fields to expect (e.g., does mk_search return 'confidence' or 'trust_level'? Does it include 'related_facts'? How is pagination handled in responses?).
Pagination and result limits not consistently described. Tools like mk_search, mk_timeline, mk_links, mk_recent_activity accept 'limit' parameters but descriptions do not specify max/min ranges or whether results are capped. Rubric baseline: pagination tools should document limit bounds (e.g., '1 - 100, default 20').
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | B | 72 | <=2025-11-25 | v2 |
List pending items in the memory review/conflict/prune queues. Returns queued observations awaiting resolution.
Resolve a queued item by applying an action (approve, reject, or supersede). Processes the queue resolution and updates memory state.
Get recent activity in the memory system. Returns facts and events from the last N days, sorted by recency.
Write or update a fact in memory. Creates a new observation with optional tier, heading, state, and provenance metadata. Returns the ID and metadata of the written fact.
Search memory across facts and transcripts using keyword or semantic modes. Returns ranked observations matching the query with optional filtering by tier, scope, recency, trust level, and state.
Get a chronological timeline of observations. Returns facts sorted by creation date with optional tier/state filters.
Override the trust level of a fact. Updates how confidently the system ranks this observation in searches. Applies immediately without reindex.
Tool chaining IDs not guaranteed. mk_search/mk_timeline/mk_links return results but output schema not documented, unclear if they include the 'id' field needed to chain into mk_get, mk_expand, mk_remember (which accept IDs as input). This forces LLMs to make assumptions or request clarification.
Destructive operations lack confirmation or dry-run support. mk_forget is marked IRREVERSIBLE and mk_remember/mk_queue_resolve are WRITE operations, but there is no confirmation_request pattern or dry_run parameter described. Agents can accidentally delete facts without recovery.
Error handling not specified. Tool descriptions mention 'Returns' but do not document error conditions, recovery guidance, or retryability. E.g., mk_get with invalid ID should return 'Fact [id] not found. Try mk_search() to discover valid fact IDs.' instead of a bare error.
Parameter constraints under-specified. Descriptions mention enum values (e.g., 'tier' can be P/L/U, 'trust' levels) but lack guidance on implications or when to use each. E.g., what is the difference between 'explicit' and 'high' trust? When should an agent choose 'seed' vs 'low'?
Missing parameter descriptions for optional fields. mk_search has parameters like 'expires_at' (ISO 8601 date); mk_remember has 'related' (array of fact IDs). While types are present, descriptions lack format hints, examples, or constraints (e.g., 'ISO 8601 format, e.g., 2024-01-15', 'array of valid fact IDs matching pattern ^[PUL]-[2345679ABCDEFGHJKLMNPQRSTUVWXYZa]{8}$').
No security/permission documentation. mk_remember, mk_forget, mk_trust, mk_queue_resolve are write operations but tool descriptions do not mention permission requirements, audit trails, or who can invoke them. Production systems require 'this tool requires write:memory permission' and 'all calls are logged for audit'.
Tool purpose differentiation unclear. mk_get vs mk_expand both retrieve a fact by ID, but distinction is not explicit. Descriptions state get='full fact with metadata, linked references' and expand='full observation with linked facts, backlinks, related observations'. For LLMs, this is ambiguous, which one returns what, and when should each be called?
Dependency hints missing. mk_lessons_promote requires 'Project-tier fact ID', but description does not guide LLM: 'If you only have a fact name, call mk_search() first to find the ID.' This prevents wasted calls and multi-step confusion.