Loading ToolBench
Memory System for Cursor using MCP - Provides persistent context awareness for Claude
This is a STDIO-only memory system for Cursor. The 8 tools are explicitly defined in index.js with basic schemas and descriptions. However, there are significant gaps: (1) Parameter descriptions are present but minimal, most are 20-40 characters, below the 72-character production baseline. (2) Output schemas are not documented, callers cannot predict the response structure (e.g., does retrieve_context return an array, a paginated object, or an object with 'results' and 'count' fields?). (3) Error handling lacks actionable recovery guidance; errors are logged but not returned to the LLM with clear next steps. (4) The vector embedding and similarity search are placeholder implementations with no guarantee that semantic similarity will work reliably. (5) Tool descriptions state WHAT happens but rarely explain WHEN to use each tool (e.g., the difference between retrieve_context, list_context, and search_similar is unclear to an LLM). (6) No tool annotations (readOnlyHint, destructiveHint, idempotentHint) are declared, which is critical for tools with side effects like delete_context and clear_all_context. (7) delete_context and clear_all_context lack confirmation logic, no dry-run, no double-confirmation pattern. Tools like save_context and update_context do not declare idempotency, risking silent duplicate inserts if the LLM retries on network hiccups. These gaps place the server solidly in the C-/D+ range for definition quality.
Clear all saved contexts from memory. WARNING: This is irreversible.
Delete a context entry by ID.
Get statistics about the memory system including total contexts, storage usage, and type breakdown.
List all saved contexts with optional filtering. View your memory storage.
Retrieve previously saved context from memory. Search by query or retrieve recent contexts.
Save important context or information to memory. This is the primary way to store persistent information.
Search for contexts similar to a given query using vector embeddings and semantic similarity.
Output schemas are not documented for any tool. LLMs and clients cannot predict response structure (e.g., is the result an array, paginated object, or single record?). This violates pattern:tool and pattern:response-shaper and forces callers to infer structure, increasing errors.
Parameter descriptions are too short (20-75 characters vs. production baseline of 72 chars average). Descriptions like 'Delete a context entry by ID' and 'Update an existing context entry by ID' lack WHEN/WHY context and actionable guidance. LLMs struggle to distinguish between similar tools (retrieve_context vs list_context vs search_similar) without clearer intent guidance.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 48 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 37 | - | v1 |
Update an existing context entry by ID.
Destructive and WRITE operations lack proper safeguards. delete_context has no confirmation parameter (only clear_all_context does). save_context and update_context do not declare idempotency, so LLM retries on network timeouts could create duplicate entries or apply the same update twice. This violates pattern:confirmation-request and pattern:idempotent-operation.
Tool annotations are missing. No readOnlyHint, destructiveHint, or idempotentHint declared in the tool definitions. This forces LLMs to infer which tools are safe to retry (read-only vs destructive) and which ones have side effects. Production tools should declare these hints explicitly.
Error handling is not actionable. The code logs errors to stderr but does not return structured error messages to the LLM explaining what to do next. For example, if update_context fails because the ID is not found, the tool should return 'Context ID 42 not found. Try list_context() to find a valid ID.' instead of a generic error. This violates pattern:recovery-guide.
Vector embedding implementation is a placeholder. The createEmbedding function uses simple trigonometric hashing (Math.sin, Math.cos, Math.tanh) instead of a real embedding model. This means search_similar will produce unreliable semantic matches. Production systems should integrate with an actual embedding API (OpenAI, Cohere, Ollama, etc.) or use a local model like sentence-transformers.
Tool descriptions do not explain WHEN to use each tool or what distinguishes them. For example, retrieve_context, list_context, and search_similar all fetch contexts but via different mechanisms (query, listing, or semantic search). An LLM cannot determine which to call without explicit guidance in the description. This violates pattern:tool-description.
Pagination is present in list_context but not in retrieve_context or search_similar. If a query returns 100+ contexts, list_context will paginate them, but retrieve_context and search_similar may not. The code sets 'limit' parameters for all three, but without documented output schemas, it's unclear whether all three are paginated or which fields indicate pagination state (e.g., next_cursor, total, has_more). This violates pattern:paginated-result.