Skip to main content
Glama

Recall Memory

recall_memory
Read-onlyIdempotent

Retrieve past memories from AutoMem using semantic queries, tags, or memory IDs. Use for context recall, decision support, and debugging with ranked or exhaustive modes.

Instructions

Recall memories from AutoMem in one of three modes. The mode is selected by which params you pass.

Mode 1 — ID fetch: pass memory_id to retrieve a single memory by ID. All other params are ignored. Routes to GET /memory/{id} and updates last_accessed.

Mode 2 — Tag enumeration: pass tags + exhaustive: true for paginated exact-match listing (NOT ranked retrieval). Use this for cleanup/audit workflows where ranked retrieval silently undercounts large tag sets. Pair with limit (≤200) and offset. Returns has_more/limit/offset page metadata. Tag matching is exact, case-insensitive, any-of mode — tag_match: "prefix" and tag_mode: "all" are rejected in this mode.

Mode 3 — Ranked retrieval (default): hybrid search across vector, keyword, tags, recency, and optional graph expansion. The primary tool for finding relevant context. By default, ranked recall requests current active memories only; set current_only: false for audits.

When to use ranked (mode 3):

  • At conversation start: recall context about the current project/topic

  • Before making decisions: check for past decisions on similar topics

  • When debugging: search for similar past errors and their solutions

  • For complex questions: use expand_entities for multi-hop reasoning

When to use enumeration (mode 2): when you need to know how many memories carry a tag, or to walk all of them for cleanup/migration. Ranked recall ignores low-importance hits — enumeration does not.

Examples:

  • recall_memory({ query: "database architecture decisions", tags: ["my-project"], limit: 5 })

  • recall_memory({ memory_id: "abc123" }) // Mode 1

  • recall_memory({ tags: ["benchmark-test"], exhaustive: true, limit: 50 }) // Mode 2 (add offset for later pages)

  • recall_memory({ query: "auth", exclude_tags: ["deprecated"] }) // Mode 3 with exclusion

  • recall_memory({ query: "What is Sarah's sister's job?", expand_entities: true }) // Mode 3 multi-hop

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
endNoISO timestamp upper bound
sortNoResult ordering (use time_* for chronological recaps)
tagsNoFilter by tags. Use project name as first tag for scoping.
limitNoMax memories to return. Schema allows 1–200; in enumeration mode (`exhaustive: true`) the server honors up to 200, while ranked mode is typically clamped server-side to ~50. Default 5.
queryNoSemantic search query (natural language). Describe what you're looking for.
startNoISO timestamp lower bound (alternative to time_query)
formatNoOutput format: text (default), items (one block per memory), detailed (adds type/confidence/metadata keys/relation stubs), json (raw per-memory fields incl. full content/metadata/relations; whole-response token budget still applies). text/items/detailed are summary-first: each memory shows its stored 1-2 sentence summary when available, else a content preview — fetch a full record via memory_id.text
offsetNoResult offset for pagination
contextNoContext label (e.g., "coding-style", "architecture"). Boosts matching preferences.
queriesNoMultiple queries for broader recall. Results are deduplicated server-side.
languageNoProgramming language hint (e.g., "python", "typescript"). Prioritizes language-specific memories.
tag_modeNo"any" matches memories with any tag (default), "all" requires all tags
embeddingNoOptional embedding vector for direct similarity search
memory_idNoMODE: ID fetch. When set, fetches the single memory by ID and IGNORES all other params. Routes to GET /memory/{id}; updates last_accessed.
min_scoreNoRanked-mode only. Minimum final score threshold before results are returned.
tag_matchNo"exact" for exact tag match (default), "prefix" for starts-with matching
exhaustiveNoMODE: tag enumeration. When true, requires non-empty `tags`. Routes to GET /memory/by-tag for paginated exact-match listing — NOT ranked retrieval. Use for cleanup/audit workflows where ranked recall undercounts. `limit` is clamped to 200. `tag_match: "prefix"` and `tag_mode: "all"` are rejected in this mode.
state_modeNoRanked-mode only. `current` returns active memories; `history` allows superseded/invalidated memories for audit timelines. Prefer this over current_only for new clients.
time_queryNoNatural language time filter: "today", "yesterday", "last week", "last 30 days"
active_pathNoCurrent file path for language auto-detection (e.g., "src/auth.ts")
state_debugNoRanked-mode only. Include state-filter suppression/replacement IDs and reasons when current_only is true.
context_tagsNoPriority tags to boost in results (e.g., ["coding-style", "preferences"])
current_onlyNoRanked-mode only. When true, server suppresses archived, not-yet-valid, expired, invalidated, or superseded memories from active context.
exclude_tagsNoRanked-mode only. Tags to exclude from results (any match excludes). Independent of `tag_match` — supports both exact and prefix matching internally on the server.
priority_idsNoSpecific memory IDs to ensure are included in results
recency_biasNoRanked-mode only. Controls service recency boosting: auto lets the service infer, on forces boosting, off disables it.
context_typesNoPriority memory types to boost (e.g., ["Style", "Preference"])
adaptive_floorNoRanked-mode only. Enable the service's adaptive score floor when filtering weak matches.
auto_decomposeNoAuto-extract entities and topics from query to generate supplementary searches.
relation_limitNoMax relations to follow per seed memory (default: 5)
scope_fallbackNoRanked-mode only. Allow fallback outside the requested tag scope when scoped recall has weak evidence; diagnostics report tag_scope and outside_tag_scope.
expand_entitiesNoEnable multi-hop reasoning via entity expansion. Finds memories about people/places mentioned in seed results. Use for "What is X's sister's job?" type questions.
expansion_limitNoMax total expanded memories (default: 25)
per_query_limitNoPer-query result limit when using queries[] (default: 5)
expand_relationsNoFollow graph relationships from seed results to find related memories.
expand_min_strengthNoMinimum relation strength to follow during graph expansion. Only traverses edges above this threshold. Recommended: 0.3 for exploratory, 0.6+ for high-confidence connections only. Does not affect entity expansion.
expand_respect_tagsNoRanked-mode only. When true, graph/entity expansion stays within the original tag scope; when false, expansion may include related context outside the tags.
expand_min_importanceNoMinimum importance score for expanded results. Filters out low-relevance memories during graph/entity expansion. Recommended: 0.3-0.5 for broad context, 0.6-0.8 for focused results. Seed results are never filtered, only expanded ones.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNoMode that produced the result.
sortNoSort mode applied by the service.
countYesNumber of memories returned
limitNoEnumeration mode only: page size used for this response.
queryNoQuery text executed by ranked recall.
offsetNoEnumeration mode only: offset used for this response.
queriesNoQuery variants executed by the service.
resultsYesArray of matching memories with scores
entitiesNoEntity identity diagnostics injected by the service.
has_moreNoEnumeration mode only: true if more pages exist past `offset + limit`.
tag_scopeNoTag-scope diagnostics including whether scoped evidence was strong enough.
state_modeNoState mode applied by ranked recall.
truncationNoPresent when trailing results were dropped to fit the response budget: { applied, omitted_results, reason }.
exclude_tagsNoTags excluded from ranked recall.
recency_biasNoRecency bias mode applied by the service.
score_filterNoScore filtering diagnostics such as min_score, adaptive_floor, and filtered_count.
state_filterNoCurrent-state filtering diagnostics. Includes aggregate counts by default and detailed IDs/reasons only when state_debug=true.
dedup_removedNoNumber of duplicate results removed (when using multiple queries)
query_time_msNoService recall latency in milliseconds.
vector_searchNoVector-search diagnostics from the service.
scope_fallbackNoTrue when recall allowed outside-scope fallback results.
jit_enriched_countNoNumber of memories enriched inline during recall.
Behavior5/5

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

Annotations already declare readOnly, idempotent, not destructive. The description adds substantial behavioral context beyond annotations: mode-specific routing (GET /memory/{id}, GET /memory/by-tag), parameter interactions (memory_id ignores others), pagination metadata, tag matching rejection policy in enumeration mode, and server-side clamping limits. This fully informs the agent of behaviors.

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 lengthy but well-structured with clear headings, bullet points, and labeled examples. Every sentence adds value; no filler. The three-mode structure is front-loaded, and examples are concise. Given the tool's complexity (38 parameters), this level of detail is warranted and efficient.

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?

With 38 parameters, zero required, full schema coverage, and an output schema, the description is remarkably complete. It covers all three modes, edge cases (parameter rejection, server clamping), pagination, and provides 5 diverse examples. No missing information is apparent for an agent to use this tool correctly.

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

Parameters5/5

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

Schema coverage is 100%, but the description adds significant semantic value: it groups parameters by mode, explains constraints (e.g., enumeration mode rejects tag_match='prefix' and tag_mode='all'), provides examples combining parameters, and clarifies server-side behaviors (e.g., rank limit clamped to ~50). This goes beyond the schema's individual descriptions.

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 clearly states it recalls memories from AutoMem in three distinct modes, with specific verbs ('recall', 'fetch', 'enumerate') and resource ('memories'). It distinguishes itself from sibling tools by being read-only, contrasting with store/delete/update. The three-mode structure provides precise intent.

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

Usage Guidelines4/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 for each mode: ranked for context and decisions, enumeration for cleanup/audit, ID fetch for single retrieval. It provides scenario examples. However, it does not explicitly state when not to use this tool versus alternatives (e.g., store_memory for recording), so it slightly misses the mark for a 5.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/verygoodplugins/mcp-automem'

If you have feedback or need assistance with the MCP directory API, please join our Discord server