Skip to main content
Glama

Search Memories

search
Read-onlyIdempotent

Retrieve relevant project memories by query or filters, with optional task-aware retrieval planning that returns observations for context.

Instructions

Read-only. Search or list curated memories: query is optional for standard search, while project/type/branch and visibility flags filter results. Optional task_intent/role/risk/token_budget/include_superseded compiles a GH-934 RetrievalPlan, applies its search/rerank/fallback policy, and returns retrieval_plan audit metadata. Returns a compact JSON object with results, source='memory', pagination, and next_step for get_observations(ids, source); limit defaults to 20 and offset to 0. Use current_state when an exact stable state_key is known, timeline for chronological observation context, and search_raw for literal chat recall. explain and multi_hop each require a non-blank query, and explain cannot be combined with multi_hop=true. Invalid combinations or curated-search database failures return a tool error; an automatic raw-archive fallback failure preserves the curated results and adds raw_hits_error to the successful response.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
riskNoRisk class for task-aware retrieval planning: low, medium, or high (default medium). High risk disables raw fallback and only requests router-approved rerank.
roleNoAgent role for task-aware retrieval planning: coder, reviewer, planner, or researcher (default coder). Only used when task-aware routing is requested.
typeNoObservation type filter
limitNoMax results to return (default 20)
queryNoSearch query (semantic search)
branchNoGit branch filter (e.g. 'main', 'feat/auth'). Only returns memories from this branch. Old data without branch info is always included.
offsetNoResult offset for pagination
explainNoInclude retrieval scoring and visibility explanation for standard search (default false). Not supported with multi_hop=true.
projectNoProject name filter
multi_hopNoEnable multi-hop search (default false). When true, performs entity graph expansion: finds entities in first-hop results, then searches for memories mentioning those entities. Use for questions that span multiple topics/people, e.g. 'What do Melanie\'s kids like?' or 'What events has Caroline participated in?'
task_intentNoOptional task-aware retrieval intent. Accepted values: resume_work/resume-work, explain_decision/explain-decision, debug_failure/debug-failure, apply_preference/apply-preference, review_change/review-change, explore_history/explore-history. When set, MCP search compiles a GH-934 RetrievalPlan and applies its execution policy.
token_budgetNoTotal token budget recorded in the task-aware RetrievalPlan (default 4000). Must be greater than zero.
include_staleNoInclude stale or archived memories (default false)
include_supersededNoAllow superseded history in the task-aware RetrievalPlan. This does not replace include_stale; use include_stale=true when the search result set should include inactive rows.
include_suppressedNoInclude policy-suppressed memories (default false)

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeYes
explainYes
resultsYes
has_moreNo
raw_hitsNo
multi_hopNo
next_stepYes
paginationYes
next_offsetNo
raw_hits_noteNo
raw_hits_errorNo
retrieval_planNo
Behavior5/5

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

Even with readOnlyHint and idempotentHint annotations, the description adds rich behavioral detail: task-aware RetrievalPlan compilation, fallback behavior, error handling, pagination defaults, and return format metadata. It discloses how invalid combinations or database failures behave.

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 long due to the tool's complexity, but every sentence provides distinct value: purpose, advanced modes, return format, alternatives, constraints, and error handling. No fluff or redundancy.

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 15 optional parameters, output schema, and sibling tools, the description covers return format, pagination, error conditions, fallback semantics, and alternatives. It is sufficient for an agent to know when and how to use the 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 covers all 15 parameters at 100%, but the description adds cross-parameter context not in the schema: limit/offset defaults, query optionality, task_intent high-level behavior, and the constraint that explain and multi_hop require a non-blank query. It also references get_observations for follow-up.

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 'Read-only. Search or list curated memories' with a specific verb and resource. It distinguishes from siblings by explicitly naming current_state, timeline, and search_raw as alternatives for different use cases.

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?

Provides explicit guidance: 'Use current_state when an exact stable state_key is known, timeline for chronological observation context, and search_raw for literal chat recall.' Also specifies constraints like explain/multi_hop requiring a non-blank query and explain not combinable with multi_hop=true.

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/majiayu000/remem'

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