Skip to main content
Glama
Vault Cortex Obsidian MCP Server

Vault Cortex Obsidian MCP Server

Memory Recall

vault_memory_recall
Read-onlyIdempotent

Recall dated memory entries on any topic across all memory files using hybrid keyword and semantic search, surfacing early entries even when their phrasing differs.

Instructions

Recall memory entries about a topic — entry-granular hybrid (keyword + semantic) retrieval across ALL About Me/ files and ALL time. Returns the relevant dated entries, up to limit, sorted oldest-first — semantic matching finds early entries even when their phrasing differs from the query. Tuned for recall over precision: expect some marginal entries. Content-word queries ("testing philosophy", "sustainable pacing") rank best. A meta-framed query ("opinions on testing") that scores below the relevance threshold degrades to any-term keyword matching instead of returning nothing.

Example: vault_memory_recall({ query: "working hours and pacing" }) Example: vault_memory_recall({ query: "testing philosophy", file: "Opinions" })

When to use: Answering "what does my memory say about X?" or "how has my view on Y evolved?" — topic-based recall across memory files. Prefer vault_get_memory to read a known file or section verbatim; prefer vault_search for notes outside the memory layer.

Behavior: A memory file change takes a few seconds to appear here.

Errors:

  • No matching entries returns entries: [] and total: 0, not an error

  • An unknown file returns empty results — call vault_list_memory_files to discover valid names

  • "[SqliteError]: …" — the index failed, not the call; the message says what to do

Returns: JSON { entries, total, truncated, search_mode, reranked }. Each entry is { file, section, date, text } — text is the raw entry markdown (wikilinks intact, continuation lines included); file and section feed directly into vault_get_memory or vault_delete_memory. The total counts every matched entry; truncated=true means limit dropped the least-relevant matches, whatever their dates, so raise limit or narrow the query for the complete set. With file, limit keeps the most relevant matches from that file. search_mode is "hybrid" when semantic matching contributed and "fts" when keyword matching alone did, the any-term fallback included; reranked is true when the reranker ran.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "query": "<query>"
    },
    "name": "vault_memory_recall"
  }
}

Input Schema

NameRequiredDescriptionDefault
fileNoRestrict to one memory file, name without .md (e.g. "Opinions"), in its exact letter case. Omit for cross-file recall — the default and usual choice.
limitNoCap on returned entries (default 50).
queryYesTopic to recall, in natural language.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.55.4
    • changedInput schema / properties / file / description
      Previous value: -"Optional: restrict to one memory file, name without .md (e.g. \"Opinions\"), in its exact letter case. Omit for cross-file recall — the default and usual choice."New value: +"Restrict to one memory file, name without .md (e.g. \"Opinions\"), in its exact letter case. Omit for cross-file recall — the default and usual choice."
  2. Changed1 schema field changedv0.55.1
    • changedInput schema / properties / query / description
      Previous value: -"Topic to recall — natural language works best (semantic matching bridges phrasing drift across months); content words about the topic rank better than meta framing (\"testing philosophy\" over \"opinions on testing\")"New value: +"Topic to recall, in natural language."
  3. Changed1 schema field changedv0.54.16
    • addedInput schema / additionalProperties
      Added value: +false
  4. Changed1 schema field changedv0.54.9
    • changedInput schema / properties / limit / description
      Previous value: -"Cap on returned entries (default 50). When more match, the least-relevant are dropped and truncated=true — never a date range."New value: +"Cap on returned entries (default 50)."
  5. Changed1 schema field changedv0.54.7
    • changedInput schema / properties / file / description
      Previous value: -"Optional: restrict to one memory file, name without .md (e.g. \"Opinions\"). Omit for cross-file recall — the default and usual choice."New value: +"Optional: restrict to one memory file, name without .md (e.g. \"Opinions\"), in its exact letter case. Omit for cross-file recall — the default and usual choice."
  6. Changed2 schema fields changedv0.50.0
    • addedInput schema / properties / limit
      Added value: +{
      +  "default": 50,
      +  "description": "Cap on returned entries (default 50). When more match, the least-relevant are dropped and truncated=true — never a date range.",
      +  "maximum": 9007199254740991,
      +  "minimum": 1,
      +  "type": "integer"
      +}
    • removedInput schema / properties / max_results
      Removed value: -{
      -  "description": "Cap on returned entries (default 50). When more match, the least-relevant are dropped and truncated=true — never a date range.",
      -  "type": "number"
      -}
  7. Addedv0.32.1
  8. Removedv0.32.0
  9. Addedv0.27.2

TDQS

A4.8/5.0
Behavior5/5

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

Goes well past the readOnly/idempotent annotations: discloses indexing lag ("a few seconds to appear"), the recall-over-precision bias with expected marginal entries, the relevance-threshold degradation to any-term keyword matching, and what each error condition means and how to recover (unknown file → vault_list_memory_files).

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?

Front-loaded with purpose and behavior, then cleanly sectioned into When to use / Behavior / Errors / Returns, with worked examples. It is long and some sentences (e.g. the search_mode/reranked explanation) could be trimmed, but nearly every sentence carries operational information.

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

Completeness5/5

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

No output schema exists, and the description fully compensates by documenting the return object, per-entry fields, and how file/section feed into vault_get_memory or vault_delete_memory, plus the meaning of truncated, search_mode, and reranked. Error cases and the empty-result-as-success case are covered, leaving nothing an agent needs for correct invocation.

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, but the description adds non-obvious semantics the schema does not: `file` restricts to one file while omitting it is the default cross-file mode, and `limit` interacts with `truncated` (least-relevant dropped regardless of date) and behaves differently when `file` is supplied. It also gives query-shape guidance (content-word queries rank best).

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

Purpose5/5

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

Opens with a specific verb+resource ("Recall memory entries about a topic") and immediately scopes it as entry-granular hybrid retrieval across all About Me/ files and all time. It distinguishes itself from the nearest siblings by naming vault_get_memory and vault_search explicitly.

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

Usage Guidelines5/5

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

A dedicated "When to use" block gives concrete triggering questions ("what does my memory say about X?", "how has my view on Y evolved?") and provides explicit alternatives: vault_get_memory for known files/sections, vault_search for notes outside the memory layer. When-not and alternatives are both present.

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