Skip to main content
Glama

mnemosyne_memory_query

Read-only

Retrieve verbatim memories from your vault—notes, code, decisions, commit history—to quote or document. Get exact source text with ranking, not summaries.

Instructions

Search a vault and get the matching memories back word for word: notes, code, decisions, session summaries, commit history. Nothing is rewritten, so use this when you need the source text itself, to quote it or to write documentation from it. Ranking is vector similarity fused with a local BM25 channel, weighted by spine type. To FIND something rather than quote it, prefer mnemosyne_memory_ask, even when you only want its sources. It retrieves deeper and re-ranks, so it catches rare literal terms this tool misses: proper nouns, identifiers, product names. The score is not a confidence value. A hit and a miss come back with similar numbers, so judge the text, not the number beside it.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMax number of results (default: 10, max: 50)
queryYesThe search query. Be specific. Examples: "why we moved off Postgres", "the retry logic in the payment worker", "notes from the March planning session".
vaultNoVault TOKEN to search, case-insensitive. A token is the folder name uppercased, with spaces and hyphens as underscores. The path-shaped id from mnemosyne_vault_list also works. This deployment's default is "DEV". It is also scoped for: PERSONAL, SOCIAL. That list is configuration rather than a census, so call mnemosyne_vault_list for the vaults that exist on this machine. Anything outside the list is refused.DEV
max_content_charsNoPer-memory snippet size in characters (default 600). Each result is cut to this length, with a hint about its full size. Raise it past 2000 when you need whole files, and watch your context window.
spine_type_filterNoOptional whitelist of spine types. Use ["ARCHITECTURE"] for design docs, ["GIT"] for commit history, ["BUGFIX","DEBUG"] for incident knowledge, ["SOURCE_CODE"] for code only. Omit it to get every type, with the SOURCE_CODE scope weighting deciding the ranking.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv1.6.0-infinity
    • changedInput schema / properties / max_content_chars / description
      Previous value: -"Per-chronicle content snippet size in chars (default: 600). Each result is truncated to this length with a hint about total size. Raise to 2000+ when you genuinely need full file content, but be aware results stack up against your context window."New value: +"Per-memory snippet size in characters (default 600). Each result is cut to this length, with a hint about its full size. Raise it past 2000 when you need whole files, and watch your context window."
    • changedInput schema / properties / query / description
      Previous value: -"The search query. Be specific. Examples: \"Phase 51 auto-poll implementation\", \"SDK authentication bug\", \"why did we choose dual-vector dimensions\"."New value: +"The search query. Be specific. Examples: \"why we moved off Postgres\", \"the retry logic in the payment worker\", \"notes from the March planning session\"."
    • changedInput schema / properties / spine_type_filter / description
      Previous value: -"Optional whitelist of spineTypes: restricts results to those types only. Use [\"ARCHITECTURE\"] to surface design docs over code, [\"GIT\"] for commit history, [\"BUGFIX\",\"DEBUG\"] for incident knowledge, [\"SOURCE_CODE\"] to force code-only. Without this, all types are returned (the SOURCE_CODE scope weighting decides ranking)."New value: +"Optional whitelist of spine types. Use [\"ARCHITECTURE\"] for design docs, [\"GIT\"] for commit history, [\"BUGFIX\",\"DEBUG\"] for incident knowledge, [\"SOURCE_CODE\"] for code only. Omit it to get every type, with the SOURCE_CODE scope weighting deciding the ranking."
    • changedInput schema / properties / vault / description
      Previous value: -"Vault TOKEN to query (case-insensitive; the folder name uppercased, spaces and hyphens as underscores). The path-shaped `id` from mnemosyne_vault_list is also accepted and normalized. Mnemosyne OS exposes one vault per tracked folder. This deployment's default is \"DEV\". Tokens this MCP is SCOPED for (a config list, not a census, so some may not be mounted on this machine): PERSONAL, SOCIAL. Call mnemosyne_vault_list for the vaults that actually exist. Anything outside the scoped list is refused."New value: +"Vault TOKEN to search, case-insensitive. A token is the folder name uppercased, with spaces and hyphens as underscores. The path-shaped id from mnemosyne_vault_list also works. This deployment's default is \"DEV\". It is also scoped for: PERSONAL, SOCIAL. That list is configuration rather than a census, so call mnemosyne_vault_list for the vaults that exist on this machine. Anything outside the list is refused."
  2. Addedv1.5.1-infinity

TDQS

A4.7/5.0
Behavior5/5

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

With readOnlyHint true, the description still adds critical behavioral context: 'Nothing is rewritten,' the ranking uses vector similarity fused with a local BM25 channel, and the score is not a confidence value because hits and misses return similar numbers. This goes beyond the annotations and helps the agent correctly interpret results. No contradiction with annotations.

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?

Each sentence earns its place: purpose, when-to-use, ranking mechanics, alternative routing, and score interpretation. The most important usage guidance is front-loaded. Though it is a longer description, it is dense with actionable information and contains no filler.

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?

For a five-parameter tool with no output schema, this description is remarkably complete. It explains what results look like ('word for word'), that snippets are truncated with size hints, how ranking works, and how to interpret the score. Combined with the richly described input schema, an agent has enough to select and invoke the tool correctly.

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 100%, so the schema already documents all five parameters thoroughly, including examples for query and vault token semantics. The description itself does not add parameter-level details, but it doesn't need to; the baseline of 3 applies since the schema carries the load. The description's ranking and score caveats are behavioral, not parameter semantics.

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?

The description states a specific verb and resource: 'Search a vault and get the matching memories back word for word.' It names exactly what content is returned (notes, code, decisions, session summaries, commit history) and explicitly separates this tool from mnemosyne_memory_ask. This is unambiguous and distinguishes it from siblings without opening their schemas.

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?

The description gives explicit when-to-use guidance: use it when you need source text itself, to quote it, or to write documentation from it. It also gives an explicit alternative: prefer mnemosyne_memory_ask 'to FIND something rather than quote it,' explaining why because that tool re-ranks and catches rare literal terms. This is clear routing guidance.

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