Loading ToolBench
A local-first, generic persistent memory layer for MCP agents
The server implements 21 well-structured tools with consistent naming patterns (verb_noun) and comprehensive input schemas. All tools have descriptions and documented parameters with types. However, there are several quality gaps: (1) Parameter descriptions are often minimal (5-20 chars), below the 72-char baseline for production tools. (2) Output schemas are referenced but not visible in the provided source, only input schemas are shown in toolInputSchemas. (3) Error handling patterns are implemented (errorReporting=true, MemoryAccessError, MemoryIdentityConflictError visible) but recovery guidance is not evident in the tool definitions themselves. (4) Tool descriptions are adequate but sparse (most 20-40 chars, well below the 194-char average). (5) Security considerations are present (AuthorizationService, AccessContext) but tool descriptions do not declare permission scopes. (6) The 21-tool set is well-composed with clear single responsibilities, space management, memory CRUD, search, links, feedback, and status. No evidence of multi-concern tools or 'and' patterns in names.
Archive a memory (soft delete)
Create a new memory record
Permanently delete a memory
Submit feedback on a memory or revision
List feedback records for a memory
Retrieve a memory by ID with full details
Retrieve a memory by logical key
Parameter descriptions are consistently minimal (5-20 characters), far below the 72-character production baseline. E.g., 'Feedback signal (useful, not_useful, etc.)' lacks context on signal semantics, when to use each, or how they affect memory ranking. LLMs cannot infer signal semantics from minimal descriptions.
Tool descriptions do not declare required permission scopes (e.g., 'read:memory', 'write:memory', 'manage:space'). The server implements AuthorizationService and SpaceAccessLevel, but descriptions omit scope requirements. LLMs cannot optimize authorization flow.
Destructive/irreversible tools (space_delete, memory_delete) lack confirmation or dry-run guidance in descriptions. No mention of whether these operations are reversible or if confirmation is required. LLMs may execute without user consent.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | 2025-06-18+ | v2 |
| 2026-03-09 | D | 50 | - | v1 |
Retrieve revision history of a memory
Create a link between two memories
List memories in a space with optional filtering
Merge multiple memories into a canonical memory
Restore an archived memory
Create a new revision of an existing memory
Search memories using semantic and lexical queries
Get indexing and operational status of a memory
Traverse memory relationships and links
Remove a link between two memories
Create a new memory space
Delete a memory space
List all memory spaces
Restore a deleted memory space
Output schemas are referenced in code (toolOutputSchemas) but not visible in the provided source. Cannot verify: (1) return field documentation, (2) pagination structure for list/search tools, (3) whether chaining IDs (spaceId, memoryId) are included in responses for downstream tool calls.
No enum constraints visible for parameters like 'signal' (in memory_feedback) or 'kind' (in memory_create). Free-form strings invite hallucinated values. Schema source (toolInputSchemas) not fully visible to confirm Zod enum definitions.
Tool descriptions lack WHEN/WHY guidance. E.g., 'List memories in a space' does not explain: should agents call this before search, or only when exploring? When is memory_get_by_key preferred over memory_get? LLMs must guess optimal tool selection.
Pagination parameters (limit, offset) documented but no guidance on max limits or default pagination sizes. Agents may request 10,000 items or use offset=999999 without server-side clamping guidance.
Error handling is implemented (MemoryAccessError, MemoryIdentityConflictError visible) but recovery guidance is not documented in tool descriptions. LLMs do not know if errors are retryable or require user action.