Loading ToolBench
MCP server for Reattend — give Claude, Cursor, and any AI tool persistent memory
Reattend MCP has clear, well-written tool descriptions (avg 180 chars, within baseline 194) and proper JSON Schema definitions for all 4 tools. Naming follows verb_noun convention (search_, ask_, save_, recent_). However, parameter descriptions lack specificity on constraints (e.g., 'limit' has no min/max bounds stated), and output schemas are not documented. Error handling is present but generic ('Search failed (${res.status})' without recovery guidance). No tool annotations (readOnlyHint/destructiveHint) despite clear risk profiles. Missing idempotency guidance for save_memory.
Ask a question and get an AI-generated answer synthesised from the user's saved memories. Best when the user needs a direct answer that may span multiple memories. Use search_memories when you just need to find or list specific items.
Get the user's most recently saved memories. Use this when the user asks what they've been working on, what was recently captured, or wants a summary of recent activity.
Save something to the user's Reattend memory. Use this when the user explicitly says to remember, save, note, or capture something. Also use it to record decisions made during this conversation if the user asks.
Search the user's Reattend memory for relevant information. Use this proactively when the user asks about anything they may have captured — meetings, decisions, notes, Slack messages, emails, or any saved context. Also use it before answering questions that might have relevant past context.
Output schemas not documented. LLMs cannot plan downstream calls or extract fields from search_memories, ask_memory, or recent_memories responses. Responses are text-only; structure is inferred from prose.
Parameter constraints lack specificity. 'limit' in search_memories and recent_memories states range in description ('1 - 10', '1 - 20') but no JSON Schema minValue/maxValue. LLMs may pass invalid values; server-side clamping hides the constraint from the agent.
Error messages are generic and non-actionable. 'Search failed (404)' or 'Query failed (${res.status})' do not guide the LLM on recovery. No distinction between retryable (429, 5xx) and user-fixable (invalid query) errors.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 62 | 2026-07-28+ | v2 |
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). save_memory is destructive (writes state) and non-idempotent (deduplication logic exists but not exposed); ask_memory has rate limits (429 handling). These should be declared via annotations.
save_memory 'context' parameter is optional but no guidance on when to use it. Descriptions should explain: 'Include context when the memory source or relevance is non-obvious (e.g., meeting name, decision rationale).'