RMS Memory MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| rms_searchA | Search RMS Memory. Returns a decision envelope: {decision: inject|abstain, reason, injected_ids, results}. |
| rms_code_searchA | Search only the derived semantic code index. Results include language, file, symbol, kind, line range, and segment index. The code index is optional, so an unindexed project returns an empty result list. Pass |
| rms_readA | Read the full contents of a markdown document from the RMS Memory vault. Provide the relative path (e.g., 'rules/api.md'). Use this to retrieve the full context of a document found via rms_search. |
| rms_writeA | Save new architectural decisions, constraints, development rules, or project context to the RMS Memory vault. Use this tool PROACTIVELY at the end of a task if you learned a new user preference, solved a tricky bug, or made a new architectural decision. |
| rms_file_historyA | Query the derived code_path git file→commit history cache (no shell). Prefer this over |
| rms_graphA | Query and mutate the durable Markdown/code knowledge graph (MCP-first). Actions: status, ensure (reconcile vault links if empty or force=true), neighbors, path (BFS), snapshot, semantic (ephemeral embedding edges), create_edge / suppress_edge / edge_override (mutations require explicit |
| rms_doctorA | Run the seven-point vault health diagnostics (structure, IDs, links, LanceDB, wiki isolation, registry, freshness). Returns structured JSON. Set repair_frontmatter=true only with an explicit project (refuses sticky-bind repair). |
| rms_reindexA | Full rebuild of vault and/or code indexes. Destructive to derived tables — requires explicit |
| rms_syncB | Incremental vault index sync (same as CLI |
| rms_wiki_packB | Generate a wiki context pack from the vault and code index. Returns material for an agent to create human-readable wiki documentation from verified sources. |
| rms_projectsB | List registered RMS Memory project keys. This tool works even when the MCP client did not provide a workspace root. |
| rms_overviewA | Structured orientation summary for exactly one project: document counts by folder and status, recent notes, and active checkpoints. Call this at session start. Fail-closed: requires a bound workspace or an explicit |
| rms_pruneA | Find superseded vault notes older than a retention window and optionally archive them under artifacts/pruned/. Defaults to a dry run; set apply=true to archive candidates. Never deletes notes. |
| rms_checkpoint_saveA | Create or update a session checkpoint (artifacts/checkpoints/.md, status=active). Save before context compaction or a long pause so work can be resumed. Updating preserves id/created_at and keeps omitted fields. |
| rms_checkpoint_doneA | Close a checkpoint: marks it status=done (drops out of recall) and writes a durable session summary note under artifacts/sessions/. |
| rms_checkpoint_loadA | Load one checkpoint with its full body and bounded previews of linked notes. Use rms_checkpoint_query first to find names. |
| rms_checkpoint_queryA | List checkpoints for the current project, newest first, with full pending text. Filter with status=active|done|all (default all). |
| rms_system_instructionsA | Return the canonical RMS Memory usage protocol (search-first, persist, session continuity). Lets an agent self-bootstrap without injected rule files. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 18 tools
Most tools have clearly distinct purposes (search, code search, graph, read, write, checkpoints, etc.). However, rms_search and rms_code_search overlap somewhat since rms_search can already search the code corpus via corpus=code, and rms_sync vs rms_reindex could be confused without reading descriptions carefully.
All tools share the rms_ prefix and use snake_case, which is consistent. However, the verb patterns are mixed: some are action-oriented (sync, search, read, write, prune) while others are noun-oriented (checkpoint_done, checkpoint_save, checkpoint_load, checkpoint_query, file_history, wiki_pack, system_instructions). The checkpoint group is consistent internally, but overall the set mixes verb-first and noun-first naming.
18 tools is on the higher end but still reasonable for a memory server that covers sync, search, graph, checkpoints, diagnostics, and project management. Each tool serves a distinct function, though a few could potentially be consolidated (e.g., checkpoint tools are four separate tools but that's a coherent subdomain).
The server covers the core memory lifecycle well: write, search, read, sync, reindex, prune, checkpoints, graph queries, and diagnostics. Minor gaps include no explicit tool for deleting/removing notes (rms_prune only archives), and no direct tool for editing existing notes (rms_write saves new content but update semantics are unclear).