Skip to main content
Glama
Sign In
RMS Memory MCP

RMS Memory MCP

by max-ramas
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

rms_search

Search local memory vaults and derived code semantically, returning inject/abstain decisions with ranked chunks for context injection; supports cross-project queries and token-bounded snippets.

Instructions

Search RMS Memory. Returns {decision: inject|abstain, reason, injected_ids, results}; trust an abstain. corpus: vault (default, Markdown notes), code (derived semantic code), all (rank-fused). projects: [keys] = read-only cross-project search (wins over project; vault/all needs cross_project_vault=true on every key, else an error). Content is bounded by max_chars; use snippet_chars + rms_read to save tokens

Input Schema

NameRequiredDescriptionDefault
limitNoMaximum number of chunks to return. Default is 10.
queryYesThe semantic query string to search for.
corpusNoCorpus to search. Defaults to vault.
projectNoRegistered project key, used when the MCP client did not provide a workspace root. Ignored when `projects` is also set.
projectsNoExplicit list of registered project keys for read-only federated search (max 8 after dedupe). Does not change the active bind. When set together with `project`, this list wins. Vault/all with len>1 requires cross_project_vault=true on every listed key.
max_charsNoMaximum total characters of injected content across results (default 2000). Truncates/drops weaker hits to stay within budget.
min_scoreNoOptional minimum relevance in 0..1 (distance and RRF normalized). If the best hit is weaker, rms_search abstains with an empty results list (fail-closed).
snippet_charsNoCut each result's content to this many characters (token-saving first pass); then rms_read the winners with `heading` or `outline`.
min_confidenceNoOptional minimum confidence threshold (0.0–1.0). Records with NULL confidence are always included. CAUTION: do NOT use high values (e.g. 0.9+) unless you need strict filtering. If zero results, retry without this parameter.
pattern_statusNoMinimum status for hits from patterns/ notes. Default verified-in-runtime: unproven patterns are hidden. `implemented` also returns implemented ones; `proposed`/`all` returns everything (hits carry their pattern_status). Other notes are never filtered.
include_contentNoWhether to include full chunk text in results.
include_file_historyNoWhen true, attach the last 3 commits from the derived code_path git-history cache to each code hit (lazy catch-up). Not allowed together with projects: […] federation. Default false.
include_graph_neighborsNoWhen true, attach durable graph neighbors for each hit path. Not allowed together with projects: […] federation. Default false.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.4.3
    • addedInput schema / properties / pattern_status
      Added value: +{
+  "description": "Minimum status for hits from patterns/ notes. Default verified-in-runtime: unproven patterns are hidden. `implemented` also returns implemented ones; `proposed`/`all` returns everything (hits carry their pattern_status). Other notes are never filtered.",
+  "enum": [
+    "verified-in-runtime",
+    "implemented",
+    "proposed",
+    "all"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / snippet_chars
      Added value: +{
+  "description": "Cut each result's content to this many characters (token-saving first pass); then rms_read the winners with `heading` or `outline`.",
+  "maximum": 4000,
+  "minimum": 40,
+  "type": "integer"
+}
  2. Changed1 schema field changedv1.2.0
    • addedInput schema / properties / include_graph_neighbors
      Added value: +{
+  "description": "When true, attach durable graph neighbors for each hit path. Not allowed together with projects: […] federation. Default false.",
+  "type": "boolean"
+}
  3. Changed1 schema field changedv1.1.2
    • addedInput schema / properties / include_file_history
      Added value: +{
+  "description": "When true, attach the last 3 commits from the derived code_path git-history cache to each code hit (lazy catch-up). Not allowed together with projects: […] federation. Default false.",
+  "type": "boolean"
+}
  4. First observedv0.1.0

TDQS

A4/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations supplied, the description carries the full burden and does so well: it declares the return shape {decision: inject|abstain, reason, injected_ids, results}, the fail-closed abstain on weak hits, that weak hits are dropped to respect max_chars, that unproven patterns are hidden by default via pattern_status, and the mutual exclusions (include_file_history/include_graph_neighbors not allowed with projects federation). These are exactly the behaviors an agent cannot get from structured fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense but front-loaded with the highest-value facts (return contract, then corpus, then federation constraint, then token optimization). No sentence is filler, though the telegraphic style ("trust an abstain", "all (rank-fused)") trades readability for brevity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 13-parameter tool with no output schema, the description covers the return contract, abstain semantics, default filters, and federation restrictions. The one dangling reference is cross_project_vault, which is named as a requirement but never located for the agent (presumably set elsewhere), leaving a small gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3; the description exceeds it by explaining precedence ("projects ... wins over project"), the cross_project_vault prerequisite that errors otherwise, and the snippet_chars -> rms_read two-pass token strategy. It also references cross_project_vault, which is not in this tool's schema at all, so that disclosure is genuinely additive.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ("Search RMS Memory") and immediately enumerates the corpus scopes (vault, code, all), which tells an agent what surface is being searched. It does not, however, distinguish itself from the sibling rms_code_search even though `corpus: code` clearly overlaps with it, leaving one ambiguity unresolved.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage guidance is implied rather than stated: "trust an abstain" and "use snippet_chars + rms_read to save tokens" give workflow direction, and the projects/cross_project_vault rule explains a prerequisite. There is no explicit when-to-use-this-vs-sibling statement (notably vs rms_code_search), so the agent must infer the selection boundary.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools