Skip to main content
Glama

Recall Memory

recall_memory
Read-onlyIdempotent

Retrieve relevant past memories from AutoMem using ID, tag enumeration, or ranked hybrid search. Supports semantic queries, tags, time filters, and multi-hop entity expansion.

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.

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

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

  • 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
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.
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.
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.
queryNoSemantic search query (natural language). Describe what you're looking for.
queriesNoMultiple queries for broader recall. Results are deduplicated server-side.
embeddingNoOptional embedding vector for direct similarity search
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.
time_queryNoNatural language time filter: "today", "yesterday", "last week", "last 30 days"
startNoISO timestamp lower bound (alternative to time_query)
endNoISO timestamp upper bound
tagsNoFilter by tags. Use project name as first tag for scoping.
tag_modeNo"any" matches memories with any tag (default), "all" requires all tags
tag_matchNo"exact" for exact tag match (default), "prefix" for starts-with matching
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.
expand_relationsNoFollow graph relationships from seed results to find related memories.
auto_decomposeNoAuto-extract entities and topics from query to generate supplementary searches.
expansion_limitNoMax total expanded memories (default: 25)
relation_limitNoMax relations to follow per seed memory (default: 5)
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.
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.
contextNoContext label (e.g., "coding-style", "architecture"). Boosts matching preferences.
languageNoProgramming language hint (e.g., "python", "typescript"). Prioritizes language-specific memories.
active_pathNoCurrent file path for language auto-detection (e.g., "src/auth.ts")
context_tagsNoPriority tags to boost in results (e.g., ["coding-style", "preferences"])
context_typesNoPriority memory types to boost (e.g., ["Style", "Preference"])
priority_idsNoSpecific memory IDs to ensure are included in results
per_query_limitNoPer-query result limit when using queries[] (default: 5)
sortNoResult ordering (use time_* for chronological recaps)
formatNoOutput format: text (default), items (per-memory), detailed (with metadata), json (raw)text
offsetNoResult offset for pagination

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
countYesNumber of memories returned
modeNoMode that produced the result.
has_moreNoEnumeration mode only: true if more pages exist past `offset + limit`.
limitNoEnumeration mode only: page size used for this response.
offsetNoEnumeration mode only: offset used for this response.
resultsYesArray of matching memories with scores
dedup_removedNoNumber of duplicate results removed (when using multiple queries)
Behavior1/5

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

The description states that Mode 1 'updates last_accessed', which is a write side effect, but annotations declare readOnlyHint=true. This contradicts the annotation, as readOnlyHint implies no state changes. The description transparently reveals behavior, but it contradicts the annotation, scoring 1 per instructions.

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?

The description is well-structured with sections for modes, usage guidelines, and examples. It is front-loaded with core purpose. However, it is somewhat lengthy, and some details are repeated in the schema, so not a perfect 5.

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?

Given the tool's complexity (30 parameters, three modes) and the presence of an output schema, the description covers all necessary aspects: modes, pagination, restrictions, examples, and when to use each mode. It is comprehensive.

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?

With 100% schema description coverage, the schema already explains each parameter in detail. The description adds minimal value beyond grouping parameters by mode and providing examples. Baseline 3 is appropriate.

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 the tool recalls memories from AutoMem in three distinct modes based on parameter selection. It specifies the verb 'recall' and resource 'memories', and distinguishes itself from sibling tools (store, delete, update, associate, health check) by focusing on retrieval.

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 provides explicit guidance on when to use each mode: ranked retrieval (Mode 3) for conversation start, decision-making, debugging, and complex questions; enumeration (Mode 2) for counting or auditing memories with a tag. It contrasts with alternatives like expand_entities for multi-hop reasoning.

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