Skip to main content
Glama

recall

Semantically search past AI agent sessions to retrieve verbatim passages of decisions, attempts, findings, and measurements; use before re-deriving or claiming something was never built or discussed.

Instructions

Semantic search over the user's past AI agent sessions: describe what you are after, get back the verbatim passages — what was decided, tried, measured or investigated. Call it when they refer to earlier work, or when you are about to re-derive something a session may already have settled. Call it too before claiming that something was never built, was dropped, or was never discussed: the code cannot show that, only the sessions can. Ranked top-k, so it gives you a foothold on a topic, not every session touching it. Ranking weighs relevance, not age: for the latest word on a topic, or one stretch of time, bound it with since/until. Each hit is a passage you will read: k is the token cost, candidates the reach, and a pool larger than k is reranked, at seconds of latency that grow with the pool, so the reach can grow without the reading.

Input Schema

NameRequiredDescriptionDefault
kNoHits returned (default 8). Each is a verbatim passage of a few hundred tokens, so `k` is what a call costs to read.
repoNoRestrict to turns whose checkout resolved to this repo, as `owner/name`
roleNoRestrict to a role, as the turns carry it (an agent's turns say user | assistant | tool | system)
queryYesNatural-language description of what to recall from past sessions. A query matches best in the language they are written in, which `status` reports.
sinceNoRestrict to turns on or after this date, `YYYY-MM-DD`
untilNoRestrict to turns on or before this date, `YYYY-MM-DD`
memoryNoMemory to read for this call, as it stands — `<org>/<repo>`, an `hf://…` URI, a local path, or `local`. Omitted, the server's memory, with this host's turns not yet pushed to it when the host is bound to it.
harnessNoRestrict to a harness facet, as the turns carry it (`claude` also matches the older `claude_code`)
neighborsNoAdjacent chunks attached to each hit for context; 0 returns the hits alone.
block_typeNoRestrict to a block type: text | thinking | tool_use | tool_result
candidatesNoSize of the fused pool the hits are cut from (default 30): how far the search looks. Larger than `k`, the pool is reranked by the cross-encoder before the cut, which costs seconds and grows with the pool, so `k` can stay small while the search looks deep. A pool of `k` rows or fewer is read whole, in the fused order.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.10.0

TDQS

A4.2/5.0
Behavior5/5

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

With no annotations at all, the description still discloses the traits that matter: ranking is relevance-weighted not recency-weighted, results are top-k and therefore not exhaustive, a reranked pool costs 'seconds of latency that grow with the pool', and `k` is the read cost in tokens. It also tells the agent what a hit physically is (a passage it will read) rather than leaving the return shape opaque despite there being no output schema.

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?

Purpose and usage are front-loaded, and every sentence carries information about either when to call or how the tool behaves. The final sentence is the weakest — 'so the reach can grow without the reading' restates the schema's own k/candidates wording in a denser form, adding length without new meaning.

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 11-parameter, no-annotations, no-output-schema tool this covers the critical ground: what it searches, what comes back, when to reach for it, and the latency/cost tradeoff. Filter parameters like `repo`, `role`, `harness`, `block_type`, `neighbors` and `memory` are left entirely to the schema, which is acceptable at 100% coverage but means the description alone would not let an agent reason about narrowing a search.

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 the baseline is 3, and here the description genuinely adds a mental model beyond field definitions: `k` as what the call costs to read versus `candidates` as how far the search looks, plus the rule that a pool larger than `k` triggers cross-encoder reranking. It also explains why `since`/`until` exist (ranking ignores age). Some of this echoes schema text almost verbatim, which caps it below 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening clause gives a specific verb and resource: 'Semantic search over the user's past AI agent sessions', and it adds what comes back ('verbatim passages — what was decided, tried, measured or investigated'). It is unmistakably different from get/scan/sessions/sketch/status, but it never names a sibling to route the agent explicitly, which is what separates a 5 from a 4.

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?

Three concrete triggers are given: when the user refers to earlier work, when about to re-derive something a session may have settled, and before claiming something was never built/dropped/discussed. The scope limitation ('a foothold on a topic, not every session touching it') also tells the agent not to expect exhaustive coverage. What's missing is an explicit exclusion or a named alternative for cases the tool is wrong for.

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

Deploy Server

Other Tools