Loading ToolBench
MCP server implementing the Recursive Large Model (RLM) architecture - providing AI agents with persistent memory and semantic file discovery
RLM Memory MCP Server presents 11 tools with generally complete schemas and descriptions. Strengths: all tools have explicit input schemas with type definitions, descriptions are substantive (average ~250 chars, well above the 20-char floor), parameter constraints (enums, minLength, maxLength) are consistently applied, and the server implements tool annotations (destructiveHint/readOnlyHint). Weaknesses: naming conventions are inconsistent (rlm_* prefix is non-standard verb-noun), several tools carry redundant/overlapping responsibilities (rlm_create_memory vs rlm_smart_memory), error handling guidance is absent, and output schemas are not documented. The descriptions emphasize the tool's mechanics but lack actionable recovery guidance for failure cases. Parameter descriptions are solid but occasionally assume LLM knowledge (e.g., 'keywords extracted from user prompt' assumes the agent knows how to extract them). No security checks visible for sensitive operations like file system indexing.
Legacy basic memory creation. **Prefer rlm_smart_memory**, which extracts richer metadata (component types, feature areas) and tracks per-file edit history. Records what was done for future recall and updates the file map. Args: - project_name (string): Name of the project - user_prompt (string): Original user request - changes_summary (string): Technical summary of changes - files_modified (string[]): List of modified file paths - keywords (string[]): Optional tags (auto-extracted if not provided) - file_descriptions (array): Optional file descriptions for the map Example: { "project_name": "jumpinotech", "user_prompt": "Fix login timeout", "changes_summary": "Increased session timeout from 30min to 2hrs", "files_modified": ["src/config/auth.ts"], "keywords": ["auth", "session", "timeout"] }
Semantic file discovery - replaces grep/find commands. Describe WHAT you want to do and get relevant file paths. Args: - project_name (string): Name of the project - user_prompt (string): Natural language description of what you're looking for - limit (number): Max files to return (default: 10) Examples: - "I need to fix the submit button color" - "Where is user authentication handled?" - "Add a new API endpoint"
Scan and index an existing codebase to build the file map. Use this when: - Starting work on an existing project for the first time - The AI agent asks to "index", "scan", or "map" the codebase - You need to understand a large codebase structure Args: - project_name (string): Name of the project - directory_path (string): Absolute path to scan (e.g., "D:\\\\projects\\\\my-app") - file_patterns (string[]): Optional glob patterns to include (default: common source files) - exclude_patterns (string[]): Optional glob patterns to exclude (default: node_modules, dist, etc.) - max_files (number): Max files to index (default: 100, max: 500) - read_content (boolean): Read file content for better descriptions (slower, default: false) Example: { "project_name": "my-app", "directory_path": "D:\\\\projects\\\\my-app", "max_files": 200, "read_content": true }
Naming convention violates verb-noun pattern. Tools use 'rlm_*' prefix rather than action verbs (create_, list_, get_, etc.). This makes intent unclear at a glance and conflicts with standard MCP tool naming. Example: 'rlm_recall_memory' should be 'search_memories' or 'recall_memories'; 'rlm_index_codebase' should be 'index_files' or 'scan_codebase'.
Overlapping tool responsibilities between rlm_create_memory and rlm_smart_memory. Both create memory entries; descriptions suggest smart_memory is 'preferred' but don't explain the functional difference clearly enough. This violates the single-responsibility principle and forces the LLM to disambiguate. Should consolidate into one canonical tool or explain the exact use case difference (basic vs. rich metadata) in both descriptions.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | D | 53 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 47 | - | v1 |
Initialize a new project for RLM memory tracking. Creates a project folder with memory storage. The project name becomes the folder name. Args: - project_name (string): Name of the project (e.g., "my-awesome-app") - working_directory (string): Optional - the actual working directory path for reference Returns: Project configuration with ID and storage location. Example: { "project_name": "jumpinotech", "working_directory": "D:\\\\projects\\\\jumpinotech" }
List all projects being tracked by RLM. Returns: Array of project summaries with names, memory counts, and last accessed times.
Manage sitemap entries when files change. Sync the file map with actual filesystem changes (renames, deletes, updates).
**PRIMARY TOOL** - Ask the MCP about relevant files for a user's request. This is the main tool for AI agent ↔ MCP bi-directional communication. Call this FIRST when starting any task to understand what files are relevant. Args: - project_name (string): Name of the project - user_request (string): Description of what the user wants (e.g., "The user wants to change the submit button color") - include_memories (boolean): Include relevant past memories (default: true) - include_suggestions (boolean): Include AI suggestions for the task (default: true) - max_files (number): Max relevant files to return (default: 10) Returns: - relevant_files: List of files with descriptions, recent changes, and why they're relevant - relevant_memories: Past work related to this request - ai_analysis: Explanation of how to approach the task - suggestions: Tips for the AI agent Example: { "project_name": "my-app", "user_request": "The user wants to fix the login form validation" }
Legacy keyword-based memory search. **Prefer rlm_query**, which searches files + memories + edit history and adds AI analysis. Use this only when you specifically want raw memory entries for known keywords. Args: - project_name (string): Name of the project - keywords (string[]): Keywords extracted from user's prompt (1-20 keywords) - limit (number): Max memories to return (default: 10) - response_format ('json' | 'markdown'): Output format Example keywords for "Fix the submit button": ["submit", "button", "form", "ui", "click"]
**MANDATORY - Call this at the END of every task!** Create smart memory entry with rich metadata extraction.
Get the status of an RLM project. Args: - project_name (string): Name of the project - response_format ('json' | 'markdown'): Output format (default: 'json') Returns: Project stats, recent memories, and file map summary.
Verify and confirm what was indexed. Provides detailed analysis of indexed files and detects potential gaps.
Output schemas not documented. Tool descriptions explain what they return in natural language (e.g., 'Returns: Project configuration with ID and storage location') but formal JSON Schema output definitions are not visible in the provided code. LLMs cannot reliably extract or chain results without explicit output schemas.
No error handling guidance. Descriptions lack recovery hints. Example: rlm_index_codebase might fail if directory_path is invalid, but the description does not guide the LLM toward next steps ('If indexing fails, try rlm_verify_index to diagnose'). Error responses should categorize failures as retryable, user-fixable, or fatal.
Missing parameter validation constraints in descriptions. Example: rlm_index_codebase accepts 'directory_path' but does not document format/restrictions (absolute vs. relative, character limits, path traversal checks). rlm_recall_memory 'keywords' param could benefit from guidance on extraction strategy.
No explicit permission/scope declarations. Tools like rlm_index_codebase and rlm_create_memory perform sensitive filesystem operations (reading, writing, indexing) but do not declare required scopes or permissions. An agent should know what access level each tool requires.
Deprecated pattern reliance: server uses Zod validation schemas (seen in src/schemas/index.js) which is appropriate, but no evidence of per-request _meta field carrying logLevel or protocol version. Modern MCP spec expects stateless request handling with metadata per-request, not global state.