Loading ToolBench
Infinite memory for Claude Code - MCP server inspired by MIT RLM paper. Provides tools for persistent memory management, context navigation, chunking, and semantic search.
The RLM server provides 14 tools with explicit schemas and descriptions, deployed via FastMCP. Naming is consistent (all prefixed 'rlm_') and descriptions are present and substantive (100 - 300+ chars). However, several parameter descriptions lack specificity about formats and constraints, and output schemas are not documented in the code. Schemas are inferred from parameter annotations rather than explicitly shown in JSON Schema format. Error handling guidance is minimal. The server demonstrates moderate maturity but lacks the polish expected of production-grade tools (patterns from 54 Agentic Tool guidelines are incompletely applied).
Save content to an external chunk file for later retrieval. Use this to externalize parts of the conversation that you might need to reference later but don't need in active context. This helps manage long conversations by keeping important history accessible without loading it into the main context window. Phase 4 enhancements: - Auto-generates summary if not provided - Detects duplicate content and returns existing chunk ID Phase 5.5 enhancements: - Supports project/ticket/domain for multi-session organization - New chunk ID format: {date}_{project}_{seq}[_{ticket}][_{domain}] Phase 9 enhancements: - chunk_type categorization to separate temporal snapshots from permanent insights - Types: "snapshot" (current state, will be replaced), "session" (work log), "debug" (bug + fix reference). Use "insight" to be redirected to rlm_remember().
Remove an insight from memory.
Search for text patterns across all chunks.
List all chunks with metadata.
List all domains used in chunks.
List all sessions.
Output schemas not documented in code. Tools return string or inferred structured data, but return types are not formally declared in docstrings or schema. This forces LLMs to infer result structure from string responses and makes composition harder.
Parameter descriptions lack format and constraint details. E.g., 'pattern' in rlm_grep is described only as 'Text pattern or regex to search for' without specifying if it's PCRE, Python regex, or glob; 'chunk_id' lacks description of the expected format (e.g., '8-character hex' is mentioned for insight_id but not consistently applied). This invites invalid input from LLMs.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 60 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Preview the content of a chunk without full retrieval.
Retrieve insights from memory. Use this to find information discussed earlier, review decisions, check user preferences, or get context before answering questions.
Save an important insight to persistent memory. Use this to remember key decisions, facts, user preferences, or technical findings that should be preserved across the conversation.
Restore chunks from a retention backup.
Preview what chunks would be affected by retention policies.
Apply retention policies to archived chunks.
Search chunks using BM25 full-text search.
Get current status of the RLM memory system. Returns statistics about stored insights, chunks, and system health. Phase 4 addition: Shows chunk access metrics.
rlm_forget and rlm_retention_run are destructive operations but lack dry-run or confirmation patterns. No confirmation_before_execute or undo mechanism shown. This risks irreversible data loss if an agent makes a mistake.
Minimal error handling guidance. Code snippets show confirmation strings (e.g., '✓ {result['message']}') but do not show what happens on failure, invalid category, missing insight_id, I/O errors, etc. No recovery guidance or error classification (retryable vs. fatal) is visible.
Enum constraints in descriptions but not explicitly validated. category (decision, fact, preference, finding, todo, general) and importance (low, medium, high, critical) are documented as one-of lists, but validation code is not shown. LLMs cannot see JSON Schema enums and rely on description text; no actionable error messages on invalid values visible.
rlm_list_sessions and rlm_list_domains lack descriptions explaining what they return and when to call them. Per-tool descriptions are under 70 chars, making selection context unclear.
No pagination guidance visible in code for list tools (rlm_list_chunks, rlm_list_sessions). limit parameters exist, but no offset/cursor or next_cursor field shown in return, risking context window exhaustion for large result sets.
Tool composition risk: rlm_recall may return truncated results (visible in code: '⚠️ {result['total_matching']} match this filter, {result['count']} shown') but error/warning is embedded in a string response. No structured way for downstream tools to detect partial results or request full pagination.