Skip to main content
Glama
owrede

vault-memory

by owrede
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

recall

Read-onlyIdempotent

Retrieve memory documents from labeled MemorySinks with provenance filters and recency ranking, returning citation packets while hiding superseded entries by default.

Instructions

Retrieve memory documents from one or more labeled MemorySinks, filtered by provenance (min_confidence, types, max_age_days) and ranked by recency (observed_at DESC). Returns citation packets (doc_id, source_handle, title, heading_path, mtime, hash, display_url, properties) — the same 8-field shape Phase 3 assembly tools use. Superseded documents are hidden by default.

Input Schema

NameRequiredDescriptionDefault
sinkNoMemory sink name OR full obsidian-fs://… handle. Defaults to all configured sinks.
as_ofNo
limitNoMaximum results AFTER filter+sort; default 20
queryYesNatural-language query; routes through hybrid (semantic + BM25) search
typesNoRestrict to docs whose `type` property is in this set
vaultsNoRestrict to these vault names; defaults to all configured
max_age_daysNoExclude docs whose `observed_at` is older than this many days
min_confidenceNoExclude docs whose confidence ordinal is lower than this (direct=3, inferred=2, uncertain=1)
include_supersededNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv2.5.0
    • addedInput schema / properties / as_of
      Added value: +{
+  "type": "string"
+}
    • addedInput schema / properties / include_superseded
      Added value: +{
+  "default": false,
+  "type": "boolean"
+}
  2. First observedv2.0.0-rc.5

TDQS

A3.6/5.0
Behavior4/5

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

Annotations already declare safe read-only, idempotent, non-destructive behavior. The description adds useful behavioral context beyond annotations: it names the exact citation-packet fields returned, states that results are ranked by observed_at DESC, and notes that superseded documents are hidden by default.

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

Conciseness5/5

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

The description is tightly structured and front-loaded: the retrieval purpose comes first, followed by the return shape and default behavior. Every sentence adds useful information, and the parenthetical parameter grouping and field list are efficient rather than wasteful.

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 9-parameter retrieval tool with no output schema, the description does important work by documenting the return packet shape and superseded-document default. It remains incomplete around as_of semantics and explicit sibling routing, but the core invocation and return context are adequately covered.

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

Parameters3/5

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

Schema description coverage is 78%, so the schema does most of the parameter documentation. The description reinforces the provenance-filtering parameters min_confidence, types, and max_age_days, but it does not add meaningful semantics for sink, vaults, as_of, or include_superseded beyond what the schema already provides.

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?

The description gives a specific verb and resource: retrieve memory documents from labeled MemorySinks. It also clarifies the retrieval mode through provenance filtering and recency ranking, but it does not explicitly distinguish this tool from sibling search tools such as search_hybrid or search_semantic.

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

Usage Guidelines2/5

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

The description explains what recall does, including filters and default hiding of superseded documents, but it gives no explicit when-to-use guidance or guidance on when another sibling tool should be preferred. It lacks the kind of routing advice that would help an agent choose between recall, search_hybrid, or search_semantic.

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