Loading ToolBench
Production-ready memory service for AI Agents using MCP Protocol
The server defines 5 tools with visible schemas and descriptions in src/index.ts. All tools have properly structured input schemas with type declarations and parameter descriptions. However, there are notable gaps in output schema documentation, error recovery guidance, and some descriptions lack specificity about when and why to use each tool. The naming follows verb_noun convention (read, write, search, delete, compact) which is clear. Parameter descriptions are present but often generic ('Memory content', 'Session ID for isolation'). Error handling returns text-only responses without structured guidance for LLM recovery. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) are present despite the server exposing tools with clearly different risk profiles (WRITE, DESTRUCTIVE, REVERSIBLE).
Compact multiple memories into a summary
Delete a memory by ID
Read a specific memory by ID
Search memories by semantic similarity
Write a new memory entry
Output schemas not documented. While input schemas are well-defined, the source code does not show return type schemas, field documentation, or response structure. LLMs cannot plan downstream calls or extract data without knowing what fields to expect.
Tool annotations missing. The 'delete' tool is marked DESTRUCTIVE and 'compact' is marked REVERSIBLE in the metadata, but the tool definitions do not include destructiveHint or idempotentHint fields required by the MCP spec to help LLMs understand operation safety and retry semantics.
Error responses are text-only without recovery guidance. The catch block in CallToolRequestSchema handler returns a plain text error message. Per the pattern:recovery-guide, error responses should indicate whether the error is retryable, user-fixable, or fatal, and suggest next steps (e.g., 'Memory not found. Try search() to verify the memory exists').
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 68 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 41 | - | v1 |
Description specificity gap on 'delete' tool. Description is only 28 characters: 'Delete a memory by ID'. This fails the minimum context requirement. Should explain consequences ('Permanently removes the memory and cannot be undone'), when to use it, and any prerequisites.
Description specificity gap on 'compact' tool. Description is only 46 characters: 'Compact multiple memories into a summary'. Does not explain the output format (is a summary created? are originals deleted? is this idempotent?), when to use it, or what the result looks like.
Parameter descriptions lack actionable constraints. 'sessionId' is described as 'Session ID for isolation' across three tools, but does not explain: format constraints, whether sessions are auto-created, what isolation means, or what happens if an invalid sessionId is passed. LLMs cannot infer these details.
No resource endpoint documentation for readOnlyHint patterns. Resources are listed (memory:/sessions, memory:/stats) but responses and return schemas are not documented in the code snippet, making it unclear what data they expose and how to use them.