Skip to main content
Glama

memory_recall

Retrieve relevant facts from persistent memory using natural-language queries combined with structured filters like category, entity, and date range. Results are ranked by recency, importance, and relevance.

Instructions

Semantic + filtered search over memory. Returns facts ranked by relevance (vector similarity blended with recency, importance, and reinforcement). Three main uses:

  1. Session-start briefing — broad query like 'session briefing: user preferences, active projects, recent decisions'.

  2. Per-prompt contextual recall — focused query derived from what the user just asked.

  3. Conflict/replacement check — recall similar facts when you suspect new information may supersede an older fact. Deduplication during memory_store is automatic. Combine the natural-language query with structured filters (category, domain, entity, date range, metadata) for tighter results. If you have a known entity name and want everything about it, prefer memory_entity. For 'what does X own/use?' style questions, prefer memory_relations. When multiple Qdrant destinations are configured, use search_scope to choose 'routed' (routing/default behavior), 'all', a destination name, a configured scope name, a comma-separated destination list, or an array of destination names. Call memory_search_scopes to inspect available scopes and descriptions. By default output is human-readable text. Use output_format=json for machine-parseable results with separate results and related arrays. Default limit is 10; maximum effective limit is 50.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
kindNoFilter by kind: fact, summary, distilled, relation. Optional. Telemetry is excluded by default.
repoNoFilter by repository or project surface.
limitNoMax primary results to return (default 10, maximum 50). Values above the maximum are clamped.
queryYesNatural-language description of what you're looking for. Embedded and matched semantically — full sentences work better than keyword lists.
sinceNoOnly facts created on or after this ISO 8601 date or datetime.
untilNoOnly facts created on or before this ISO 8601 date or datetime.
branchNoFilter by branch or working surface.
domainNoFilter by domain activity profile (same vocabulary as memory_store.domain). Optional.
entityNoRestrict to facts mentioning this entity (case-insensitive). For full entity context prefer memory_entity.
categoryNoFilter by category (same vocabulary as memory_store.category). Optional.
task_keyNoFilter by task or issue key.
episode_idNoFilter by coherent episode ID.
destinationNoOptional legacy single-destination override. Do not combine with search_scope. Prefer search_scope for routed/all/list search.
graph_depthNoEntity-graph traversal depth. 0 = vector search only (fast, default). 1 = also surface up to ceil(limit / 2) extra 1-hop entity-related facts (slower; use when the user asks 'what's connected to X?'). In JSON output these are returned separately as related.
search_scopeNoOptional read/search scope. Accepts 'routed', 'all', a destination name, a configured scope name, a comma-separated destination list, or an array of destination names. Omit to use config.default_search_scope.
workspace_idNo[Removed in v0.4.0] No-op.
output_formatNoResponse format. text = backward-compatible human-readable lines (default). json = parseable object with query, limit metadata, results, related, counts, and optional nudge.text
review_statusNoFilter by review lifecycle status (candidate / reviewed / approved / rejected).
memory_subtypeNoFilter by memory subtype (must be valid for the chosen kind). Optional.
origin_user_idNoFilter to facts whose creation origin.user.id matches this value. Optional.
workstream_keyNoFilter by durable workstream key.
metadata_filterNoExact-match filter on the metadata map stored with each fact. All key/value pairs must match (AND logic).
origin_agent_idNoFilter to facts whose creation origin.agent.id matches this value. Optional.
origin_interfaceNoFilter to facts created through this origin interface. Optional.
include_legacy_workspaceNo[Removed in v0.4.0] No-op.
Behavior4/5

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

Without annotations, the description takes full responsibility for behavioral disclosure. It explains relevance ranking (vector similarity blended with recency, importance, reinforcement), deduplication, output format options, limit clamping, graph_depth behavior, and search_scope mechanics. Slightly missing an explicit read-only declaration, but the nature of 'recall' and the operation parameters imply no mutation.

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-organized with a clear purpose statement, bulleted use cases, and distinct sections for scope and output. It is lengthy but every sentence serves a purpose. Some redundancy exists (e.g., repeated 'optional' notes), but overall efficient for the tool's complexity.

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?

Despite 25 parameters and no output schema, the description covers all essential aspects: usage scenarios, behavioral details, sibling differentiation, parameter hints, output format options, and scope configuration. It provides sufficient information for an AI agent to understand the tool's full capabilities and limitations.

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

Parameters4/5

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

Schema description coverage is 100%, setting baseline at 3. The description adds value by elaborating on key parameters: advises using full sentences for query, explains graph_depth's 1-hop behavior, details search_scope flexibility, and clarifies output_format defaults. While some parameters merely restate 'optional', the added context for complex fields boosts the score.

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 identifies the tool as performing semantic + filtered search over memory, with specific verb (recall) and resource (memory). It distinguishes from siblings memory_entity and memory_relations by describing their different use cases (full entity context vs. ownership/use queries), making selection unambiguous.

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?

Explicitly lists three main use cases (session-start briefing, per-prompt recall, conflict/replacement check) and provides clear when-not-to-use guidance by referencing sibling tools. Also directs user to memory_search_scopes for scope configuration, ensuring proper tool selection.

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/bikky-dev/bikky'

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