Skip to main content
Glama

memory_search

Search past sessions' learnings, decisions and blockers by topic, combining full-text and semantic search with filters for kind, project, path and date range.

Instructions

Search past sessions' learnings, decisions, blockers and other memory records by TOPIC (Postgres full-text search fused with semantic similarity) -- the tool for 'what did we decide/learn about X'. Filter by kind, scope, project, path, or since/days. A date phrase in the query ("last week", "yesterday", "Sept 20") is read as a time hint: it is taken out of the search text and records from that window rank higher, but older matches still come back (date_hint shows the reading); since/days are hard filters. Newer records win near-ties. since/days filter on the session's start time; each record's when is its session's end time (else start). Covers extracted, quote-verified records (extraction runs on sessions within about 30 days of upload; older extracted records stay searchable); a fact that was said but never extracted is only in the raw turns (search_conversations). When nothing is relevant enough, reason says why -- that is the answer, not an error. Records a newer record replaced are hidden unless include_superseded is true or the query names a past date; paraphrases of one fact are served as one record with seen_in (the number of sessions that said it); every record carries as_of, the day its session recorded it (true when recorded, not current state). Local installs return served: lines (records as JSON, raw session excerpts marked "raw excerpt") packed whole to max_tokens (default 3000). Else (hosted; raw_reason says why) ranked records cut at max_tokens (dropped_for_budget). A record's session_id is a code session: read the turns around it with get_code_session id=<session_id> turn=<turn_idx>, or session_summary session_id=<session_id>. Records carry links to their sources when known: sha (the commit the session was on), paths (files it names, up to 5), ref_url (the ref's forge page). Open them directly; they locate sources, they do not report current state. Results are dated records of what sessions did, not the current state of a PR or issue; check that live.

Input Schema

NameRequiredDescriptionDefault
daysNoOnly records from sessions in the last N days, a whole number 1-365 (a hard filter). Ignored when since is given.
kindNoOne or more of: outcome, decision, learning, blocker, preference
pathNoOnly records whose paths[] includes this file
limitNoMax records to return, a whole number 1-20 (default 10)
queryYesWhat to search for
scopeNoOnly records of this scope: "project" (about one repo, the default a record gets) or "global" (a rule or fact bigger than one repo). Omit for both.
sinceNoOnly records from sessions on or after this time (a hard filter). ISO date "2026-09-24" (00:00 UTC) or ISO datetime "2026-09-24T09:30:00Z". Wins over days.
projectNoRepo remote URL, absolute path, or short repo name (e.g. "acme/payments" or "owner/repo", as the preamble names the current repo) to scope the search to one project
max_tokensNoToken budget for the result, 200-20000 (default 3000). Served lines (records and raw excerpts) are packed whole, in order, estimated as characters / 4, and stop at the first line that does not fit. Without raw excerpts the ranked records fill it instead, and at least one is returned.
recall_tokenNoThe recall_token line from this session's Membral preamble, if you have one. Only logged to link this call to that preamble; it never changes the results.
include_supersededNoAlso return records a newer record replaced, each marked superseded_by {id, on}. Default false: replaced records are hidden. A past date phrase in the query ("as of Sept 20") also serves what was current then.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.5/5.0
Behavior5/5

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

No annotations exist, so the description carries the full burden, and it delivers: ranking rules (newer wins ties), date-hint soft ranking vs since/days hard filtering, superseded-record hiding and how to unhide, paraphrase merging with seen_in, as_of staleness, extraction coverage window (~30 days of upload), and two different result-shaping modes (served vs records with raw_reason/dropped_for_budget). It also states that an empty result with a 'reason' is a valid answer, not an error.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded in sentence one, but the body is a dense run-on with repeated content: since/days filtering is explained twice and the 'records are not current state' caveat is stated twice ('they do not report current state' and 'not the current state of a PR or issue'). The information is valuable but could be tightened without loss.

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?

For an 11-parameter tool with no output schema and no annotations, the description covers return shapes, key fields (date_hint, seen_in, as_of, dropped_for_budget, served), failure semantics, and source-link fields (sha, paths, ref_url). An agent has what it needs to call and interpret results.

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 coverage is 100%, so baseline is 3; the description goes beyond it by clarifying that since/days filter on session start time while each record's `when` is session end time, and by explaining that include_superseded is implicitly true when the query names a past date. Remaining params (kind values, limit, project, recall_token) are left to the schema.

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?

First sentence states a specific verb and resource ('Search past sessions' learnings, decisions, blockers...') plus the search mode (full-text fused with semantic) and the agent-facing intent ('what did we decide/learn about X'). It explicitly marks its boundary against search_conversations for unextracted facts, so an agent can choose without opening schemas.

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?

Gives clear conditions: use this for topics, use search_conversations for raw turns, and follow up with get_code_session/session_summary when you need surrounding context. It does not differentiate itself from memory_recall or memory_resolve, so the sibling routing is incomplete, but the affirmative usage context is strong.

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