Loading ToolBench
Shared project-memory MCP server for AI coding agents (Claude Code, Codex, ...)
Strong domain-specific design with clear, detailed descriptions for a specialized memory-management tool. All 7 tools have descriptions (194 - 450 chars, well above baseline 194 avg). Input schemas present with types and descriptions. However, output schemas are not documented in the source code, and tool annotations (readOnlyHint, destructiveHint) are missing despite clear risk classifications. Naming is domain-appropriate but unconventional (memoize_* prefix rather than verb_noun). Error handling guidance is implicit in descriptions but not explicit in tool responses.
Inspect up to 20 stored memories at once for maintenance, including stale or suspended content and full sources. Returns ledger, revision, freshness and writable for each copy. Use names for a batch, or no names to page through the store. Reuse snapshot from status or a maintenance claim, or pass nextCursor alone, to avoid rescanning. Snapshots expire after five minutes. Content is explicitly unverified: compare it with current sources before using or saving it. Ordinary project navigation should use memoize_recall.
Mark a memory entry as obsolete and remove it from the store. Requires confirmation and the entry's current revision to prevent accidental deletion.
Coordinate bounded maintenance batches for memory entries. Claim a batch of stale or suspended entries for work, inspect them, update them with revision checks, and release or block items. Follow organizer guidance in results.
Merge multiple memory entries into one canonical entry, checking and committing the whole merge together. Provide the canonical entry's expectedRevision (null if new) and each superseded entry's ledger, name, and revision. Preserve distinct facts and source coverage.
Read project memories. Without `topic`: returns an index of entries (names, summaries, staleness — no content). With `topic`: returns the entry content if fresh or verified; if stale, returns the changed source files to re-read instead — pass includeStale=true to also get the stored (outdated) body, e.g. to rewrite it. Call before analyzing project files. Use memoize_inspect for raw notes and full sources during maintenance.
Output schemas not documented. Tool descriptions explain what is returned (e.g., 'returns which files changed externally and which memory entries are stale'), but formal output schema definitions are not visible in source code. LLMs cannot plan downstream tool calls without knowing response structure.
Tool annotations missing. memoize_update, memoize_merge, memoize_invalidate, and memoize_maintenance are marked as WRITE or DESTRUCTIVE in the risk field, but no readOnlyHint, destructiveHint, or idempotentHint annotations are present in the schema. Agents cannot distinguish safe from unsafe operations without explicit hints.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 53 | <=2025-11-25 | v2 |
Project-memory staleness check. Call at session start, after external changes, and to verify maintenance completion. Returns which files changed externally and which memory entries are stale, verified (auto re-baselined), or suspended (sources unresolved).
Create or replace a memory entry. For an existing entry, pass its inspected or recalled revision as expectedRevision to prevent conflicts. Omit expectedRevision only when creating a new entry. Producer plugins are sources of truth — follow the producer guidance in the tool description.
Naming convention non-standard. All tools use memoize_* prefix (domain-specific) rather than verb_noun pattern (e.g., get_memory, create_memory, update_memory). While internally consistent, this deviates from the 90% baseline of A+ tools starting with action verbs. LLMs may struggle to infer intent from names alone.
Error handling guidance not explicit in tool definitions. Descriptions mention staleness and suspension states but do not provide recovery guidance (e.g., 'If stale, call memoize_recall with includeStale=true'). Error responses should tell LLMs what to do next.
Parameter relationships underdocumented. memoize_maintenance has conditional logic (action determines which of token/items/reason apply), but these dependencies are not explicitly stated in parameter descriptions. Agents may pass invalid combinations.