Skip to main content
Glama

search_memory

Search indexed memories by semantic relevance and return ranked results, with optional time-based filters. Use at task start, during debugging, or when past work is referenced.

Instructions

Search indexed memories by semantic relevance (vector search + reranking; BM25 keyword fusion runs only when retrieval.mode is "hybrid", and the default is vector-only) and return ranked results with optional temporal filtering. With the default mode there is no keyword channel, so exact identifiers such as commit hashes or variable names may not surface — use a raw-text search for those. The shown score is a fused ranking score (0-100%), NOT pure cosine similarity — read it as relative ranking within this result set, not as match confidence. Read-only, but may fire stored reminders as a side effect. Use proactively at the start of tasks, when debugging, writing, or when the user references past work.

Input Schema

NameRequiredDescriptionDefault
afterNoFilter memories stored after this date (ISO format YYYY-MM-DD, or relative like '最近30天', 'last 7 days')
graphNoEnable KG graph traversal (PPR) for relationship-aware search. Use when query involves entity relationships (e.g. 'what tools does Alice use', 'Bob的朋友').
limitNoMax results to return
queryYesSearch query — natural language or keywords
scopeNoExplicit scope; reuse Scope returned by resume_context. May be omitted when sessionId or configured environment supplies a scope, or allScopes=true explicitly requests cross-scope search. Omission alone does not mean global search.
beforeNoFilter memories stored before this date (ISO format YYYY-MM-DD, or relative)
renderNoResult rendering mode: verbatim (default, original order) or highlight (reorder by contextual relevance to query)verbatim
profileNoRetrieval profile
validAtNoQuery memories valid at a specific point in time (ISO date, e.g. '2025-06-15'). Returns only memories whose validity window covers this date.
categoryNoFilter by memory category: profile (identity/background), preferences (habits/style), entities (projects/tools/people), events (past happenings), cases (problem-solution pairs), patterns (reusable workflows)
topicTagNoFilter by topic tag (e.g. 'auth', 'deploy', 'testing'). Only returns memories tagged with this topic.
allScopesNoWhen true, explicitly allow cross-scope search
sessionIdNoOptional session identifier to infer session:<id> scope
reconstructNoReturn LLM-synthesized reconstruction alongside raw results. Requires RECALLNEST_CONSTRUCTIVE_RETRIEVAL=true.
detail_levelNoResult detail level: normal (default — the full text of each hit, in rank order. One entry is capped at 2400 chars. Full text is handed out until an 8k-token budget is used up; hits past that point get a query-aware snippet instead of being dropped, so a long list can run past 8k by one snippet per remaining hit, and each related-scope block has its own budget. Any shortened entry says how much of it is shown and gives the id for memory_drill_down), brief (ID+score+one-liner), full (table with 120-char snippets plus extra metadata), adaptive (full text only for hits scoring above the threshold, query-aware snippet for the rest, 8k-token budget)normal
includeExpiredNoWhen true, include expired memories in results (demoted 80%). Default: only active/non-expired.
includeArchivedNoWhen true, also return archived/superseded/consolidated memories (default: only active)
includeRelatedScopesNoWhen true, also query configured related scopes from scopeRelations and show them in a separate sidecar section. Requires an explicit or inferred scoped search; never changes the main result ranking.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv4.0.0
    • changedInput schema / properties / detail_level / description
      Previous value: -"Result detail level: brief (ID+score+one-liner), normal (default, table), full (include metadata), adaptive (per-result L0/L1/L2 fidelity by relevance within an 8k token budget — high-relevance gets full text, lower gets summary/one-line)"New value: +"Result detail level: normal (default — the full text of each hit, in rank order. One entry is capped at 2400 chars. Full text is handed out until an 8k-token budget is used up; hits past that point get a query-aware snippet instead of being dropped, so a long list can run past 8k by one snippet per remaining hit, and each related-scope block has its own budget. Any shortened entry says how much of it is shown and gives the id for memory_drill_down), brief (ID+score+one-liner), full (table with 120-char snippets plus extra metadata), adaptive (full text only for hits scoring above the threshold, query-aware snippet for the rest, 8k-token budget)"
    • changedInput schema / properties / scope / description
      Previous value: -"Optional explicit scope"New value: +"Explicit scope; reuse Scope returned by resume_context. May be omitted when sessionId or configured environment supplies a scope, or allScopes=true explicitly requests cross-scope search. Omission alone does not mean global search."
  2. Addedv2.6.0
  3. Removedv2.5.4
  4. Changed3 schema fields changedv2.5.4
    • changedInput schema / properties / detail_level / description
      Previous value: -"Result detail level: brief (ID+score+one-liner), normal (default, current behavior), full (include metadata)"New value: +"Result detail level: brief (ID+score+one-liner), normal (default, table), full (include metadata), adaptive (per-result L0/L1/L2 fidelity by relevance within an 8k token budget — high-relevance gets full text, lower gets summary/one-line)"
    • changedInput schema / properties / detail_level / enum
      Previous value: -[
      -  "brief",
      -  "normal",
      -  "full"
      -]New value: +[
      +  "brief",
      +  "normal",
      +  "full",
      +  "adaptive"
      +]
    • addedInput schema / properties / includeRelatedScopes
      Added value: +{
      +  "default": false,
      +  "description": "When true, also query configured related scopes from scopeRelations and show them in a separate sidecar section. Requires an explicit or inferred scoped search; never changes the main result ranking.",
      +  "type": "boolean"
      +}
  5. Changed4 schema fields changedv2.3.0
    • addedInput schema / properties / includeExpired
      Added value: +{
      +  "default": false,
      +  "description": "When true, include expired memories in results (demoted 80%). Default: only active/non-expired.",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / reconstruct
      Added value: +{
      +  "default": false,
      +  "description": "Return LLM-synthesized reconstruction alongside raw results. Requires RECALLNEST_CONSTRUCTIVE_RETRIEVAL=true.",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / topicTag
      Added value: +{
      +  "description": "Filter by topic tag (e.g. 'auth', 'deploy', 'testing'). Only returns memories tagged with this topic.",
      +  "maxLength": 60,
      +  "minLength": 1,
      +  "type": "string"
      +}
    • addedInput schema / properties / validAt
      Added value: +{
      +  "description": "Query memories valid at a specific point in time (ISO date, e.g. '2025-06-15'). Returns only memories whose validity window covers this date.",
      +  "type": "string"
      +}
  6. First observedv1.0.0

TDQS

A4.5/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden and delivers: it is read-only but 'may fire stored reminders as a side effect', the default mode is vector-only with no keyword channel, and the displayed score is a fused 0-100% ranking score, not cosine similarity. These are non-obvious behavioral traits an agent could not get from structured fields.

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?

It is a dense block of text, but front-loads the core operation and method before caveats, and every sentence earns its place (mode behavior, identifier caveat, score semantics, side effects, usage). Slightly heavy as a single unsegmented paragraph, but no filler.

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?

For an 18-parameter, no-output-schema tool with no annotations, the description covers the critical unknowns: retrieval mode, score interpretation, and side effects. It relies on the 100%-covered schema for parameter detail and could say more about result shape, but is otherwise complete enough to invoke 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 all 18 parameters are already documented in the schema. The description adds some conceptual framing (temporal filtering, hybrid mode) but no parameter syntax or format detail beyond what the schema provides, so the baseline 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?

States a specific verb (search), resource (indexed memories), and method (vector search + reranking, with BM25 fusion only under retrieval.mode="hybrid"). The description makes clear this is semantic retrieval distinct from raw-text search, so an agent can distinguish it from sibling tools without opening the 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?

Gives explicit when-to-use contexts ('proactively at the start of tasks, when debugging, writing, or when the user references past work') and a when-not with an alternative ('exact identifiers such as commit hashes or variable names may not surface — use a raw-text search for those'). Nothing is left to inference about when this tool is the right choice.

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