Skip to main content
Glama
max-ramas

RMS Memory MCP

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault

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

CapabilityDetails
tools
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
rms_searchA

Search RMS Memory. Returns a decision envelope: {decision: inject|abstain, reason, injected_ids, results}. corpus=vault (default) searches human Markdown memory; code searches derived semantic code; all ranks each corpus independently and combines them with Reciprocal Rank Fusion, never raw vector distances. Pass projects: [key, …] for read-only cross-project federation (when both project and projects are set, projects wins so injected rules stay compatible); vault/all across multiple projects requires every listed key to have cross_project_vault=true (hard error otherwise — no silent degrade). Weak matches abstain when min_score is set; content is bounded by max_chars.

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 projects: [key, …] for read-only cross-project code federation (when both project and projects are set, projects wins); does not change the active bind.

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 git log for when a source file changed. Lazy catch-up on query; use action=reindex after force-push/rebase (requires explicit project). Default response omits commit messages. Catch-up/reindex enforce commit-count budgets.

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 project), export_dot. Prefer this for dependency traversal instead of guessing from search alone.

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 project. Prefer rms_sync for incremental catch-up.

rms_syncB

Incremental vault index sync (same as CLI rms-memory sync). Prefer an explicit project when the IDE is multi-root.

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 project key; never aggregates across projects.

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

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A3.7/5.0

Scored across 18 tools

Disambiguation4/5

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.

Naming Consistency4/5

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.

Tool Count4/5

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).

Completeness4/5

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).

Maintenance

ActivityMaintained
ResponsivenessResponsive