Skip to main content
Glama
330899935

hive-memory

by 330899935
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Recall memory

recall
Read-onlyIdempotent

Search confirmed memory by natural-language query to find what was previously decided, recorded, or agreed. Returns closest stored entries; empty results mean no match, not no memory.

Instructions

Search the human's confirmed memory by natural-language query and return the closest stored entries. Use this to find what was previously decided, recorded, or agreed. Do not use it at session start when you have no query yet - use get_context instead. Do not use it to review entries still awaiting approval - use manage with action list_pending. Annotations already declare this read-only, so this text covers what they cannot: results come from the confirmed store only, private vaults are omitted for agents not permitted to read them, and an empty list means no match rather than no memory.

Input Schema

NameRequiredDescriptionDefault
limitNoMaximum number of memories to return. Omit for the server default.
queryYesNatural-language search text, e.g. 'what did we decide about the pricing page'. Ranked by how much of it the entry's words and character bigrams cover, plus a small recency nudge and a bonus when the whole query appears verbatim. This engine has no embeddings, so an entry that shares no wording with the query will not be found - add plain keywords alongside the sentence.
vaultsNoNarrow the search to these vault names. Omit to search every vault this agent may read. Naming a vault the agent may not read is not an error - it returns nothing from that vault.
compactNoReturn trimmed records (id, title, snippet) instead of full bodies. Saves tokens when you only need to know whether something exists.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.2.0
    • changedInput schema / properties / query / description
      Previous value: -"Natural-language search text, e.g. 'what did we decide about the pricing page'. Matched semantically, not by substring."New value: +"Natural-language search text, e.g. 'what did we decide about the pricing page'. Ranked by how much of it the entry's words and character bigrams cover, plus a small recency nudge and a bonus when the whole query appears verbatim. This engine has no embeddings, so an entry that shares no wording with the query will not be found - add plain keywords alongside the sentence."
    • removedInput schema / properties / query_vector
      Removed value: -{
-  "description": "Precomputed embedding. When supplied, recall ranks by vector similarity and ignores 'query' text matching.",
-  "items": {
-    "type": "number"
-  },
-  "type": "array"
-}
  2. First observedv0.1.7

TDQS

A4.5/5.0
Behavior5/5

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

Rather than restating readOnlyHint, it deliberately adds what annotations cannot: results come only from the confirmed store, unreadable private vaults are silently omitted, and an empty list means no match rather than no memory. The empty-result-vs-empty-store distinction is exactly the kind of behavioral fact that prevents misdiagnosis.

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?

Sentences are front-loaded: purpose first, then the two exclusions, then behavioral caveats. The self-referential clause about what the annotations already declare is slightly meta but functions as a signpost for why the following sentences exist.

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?

With no output schema, the description carries the burden of describing results, and it does so at a high level (closest entries, confirmed store only, empty list semantics), while compact-vs-full shape is in the schema. Minor gap: how ties or scores are surfaced to the caller is left implicit.

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 coverage is 100%, so query, limit, vaults and compact are already fully documented, including the keyword/bigram ranking behavior. The description adds only an indirect hint about vault permission behavior, which the schema itself already states, so the baseline of 3 applies.

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 definition pairs a specific verb (search) with a specific resource (the human's confirmed memory) and states what it returns (the closest stored entries). It explicitly distinguishes itself from siblings get_context and manage, so an agent can route without opening a schema.

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?

It names two concrete exclusions with the alternative to use instead: at session start with no query, use get_context; to review pending entries, use manage with action list_pending. Both when-to-use and when-not-to-use are covered explicitly.

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