session-recall
The session-recall server provides tools to semantically search, navigate, and grep through past Claude Code and Codex conversations, offering shared memory across AI engines.
recall_search(query)— Semantically search past sessions by meaning (not just keywords). Returns ranked anchors with relevance scores and timestamps. Optionally scope to the current repo (scope_cwd), filter by source (claude/codex), or constrain to a date range.expand_around(session_id, uuid)— Retrieve raw turns surrounding a specific anchor, including tool calls, tool outputs, and reasoning/thinking blocks. Configurable number of turns before/after the anchor.step(session_id, uuid, direction)— Walk forward or backward through turns in a session from a given position, acting as a cheap cursor for navigating transcript context.grep(pattern)— Substring scan over all raw indexed transcripts, including under-the-hood turns (tool outputs, thinking) not in the search index. Can be scoped to a session or repo; requires no embedding API key.recent_sessions()— List the most recently active sessions in reverse chronological order, showing session ID, project, turn count, last activity, and opening prompt. Supportsscope_cwdand date filters.
Additional capabilities include automatic incremental indexing of transcripts, date-based filtering with timezone support, and pluggable embedding providers (including local options like Ollama).
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@session-recallRecall what we discussed about error handling last week."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Shared semantic memory for Claude Code, Codex, and Cursor. Find an old decision by meaning. Open the raw evidence. Continue the work.
English · Русский · Español · 中文
Your coding agents remember the current chat. Your work lives across months of chats — resumed sessions, parallel subscriptions, worktrees, different agents.
Session Recall turns that history into one local-first index and serves it back through five focused MCP tools. A fresh session can recover what Codex worked out yesterday and what Claude Code rejected three months ago — with links back to the actual turns, tool output, and reasoning. Not a summary file someone maintains by hand: the original conversation stays the source of truth.
you: we were fixing the auth token conflict between the two services — where did we land?
agent: (recall_search → expand_around) Both services shared one OAuth account, and the provider rotates refresh tokens per account, so each refresh invalidated the other's copy. You rejected the shared-credentials-directory patch as too coupled, and settled on a keeper service owning the session. The spec was never written — that was the next step.
What you get
Capability | What it changes | |
One memory | Claude Code, Codex, and Cursor feed the same index | Switch agents without resetting the project story |
Semantic retrieval | Search by meaning, not only exact words | Recover decisions you can describe but cannot quote |
Deep navigation | Open raw turns: tool calls, outputs, reasoning | Verify the answer instead of trusting a summary |
Honest degradation | A semantic outage is reported explicitly | A literal-only fallback never poses as semantic search |
Local by default | Bundled ONNX embeddings and local SQLite | Start without a key, a server, or an account |
Scoped recall | Filter by repo, source, or local calendar dates | Keep unrelated projects out of the answer |
Team answers | Ask a colleague's local memory, owner-approved | Share hard-won context without exposing raw sessions |
Related MCP server: claude-kb
Where it pays off
Session onboarding. A fresh session starts already in context — whether you juggle several subscriptions, hop between agents, or return to a task you "discussed at some point".
Bugs and regressions. Before fixing anything, the agent asks the history: was this bug seen before? how was it fixed? why did we believe it was fixed? A recurrence stops looking like a fresh bug — and the fix turns from a patch into a dig into the component.
Procedures. Explain a workflow once — how to read a trace, how to break down token spend per task — and any later session replays it without being walked through again.
Cause and effect. Say "let's change this decision", and the agent looks up the moment it was made: "we picked X for compatibility with Y — before changing anything, make sure Y survives."
Five tools, one workflow
The interface stays deliberately small:
MCP tool | Use it when |
| You remember the idea, not the wording |
| You found an anchor and need the surrounding evidence |
| You need the adjacent raw turn without another search |
| You know an exact error, symbol, path, or identifier |
| You want the freshest work — and the index freshness |
flowchart LR
Q["describe the old problem"] --> S["recall_search"]
X["exact error / symbol / path"] --> G["grep"]
S --> A["anchor: session + turn"]
G --> A
A --> E["expand_around"]
E <--> T["step next / prev"]
E --> V["grounded answer + raw evidence"]
R["what is current?"] --> RS["recent_sessions"]Every discovery tool accepts an optional source (claude | codex | cursor), a
scope_cwd to narrow results to the current repo (worktrees collapse to the repo root), and
local calendar dates (on_date, or start_date / end_date, plus an IANA timezone).
Ranked anchors carry provenance and a human-readable timestamp. grep scans all indexed
transcripts on demand — including under-the-hood turns (tool output, thinking) that never
became search chunks. On-demand only: no proactive context injection into every prompt.
{
"query": "why did refresh tokens conflict?",
"scope_cwd": "/work/keeper",
"source": "codex",
"start_date": "2026-05-01",
"end_date": "2026-06-30",
"timezone": "Europe/Moscow"
}recall_search answers {"anchors": [...], "degraded": null | "reason"}. When degraded
is set, the embedding provider was unreachable and only literal matching ran — the agent can
say so instead of mistaking a lexical miss for an empty history.
Quick start
Two pieces: a Python CLI (which also ships the MCP server) and a plugin that wires it into your agent. Budget about two minutes plus the first index run.
1. Install the CLI and build the index
pipx install git+https://github.com/AbsoluteMode/session-recall
session-recall setup # one question (interaction language), then the first indexNo key required: with nothing configured, indexing runs on a bundled CPU model, downloaded
once and picked by your interaction language. The first run walks your whole history —
minutes for months of transcripts, seconds after that. Scripted installs:
session-recall setup --lang en --yes.
$ session-recall index
indexed 2175 chunks from changed transcripts
your history: 1053 sessions spanning 168 days, 40,037 searchable fragments
Claude Code 372 · Codex 680 · Cursor 1
busiest: sidekey, trend_detection, glitchHosted Voyage embeddings rank noticeably better than the bundled model; to use them, export
VOYAGE_API_KEY before indexing — see Embedding providers.
2. Connect your agents
pipx puts session-recall and session-recall-mcp on ~/.local/bin — exactly where the
plugin manifests look for them.
/plugin marketplace add AbsoluteMode/session-recall
/plugin install session-recallThen start a new session — MCP servers, skills, and the SessionStart hook load at session
start, not on install. Prefer to let the agent finish the job? Say set up session-recall
(or run /session-recall:setup): it asks the onboarding questions in chat, runs the
commands itself, and ends with a health check and a real search over your history.
The repository ships a native .codex-plugin/plugin.json —
ready to drop into a local repo or your personal marketplace; see the
local plugin installation guide.
Codex also asks you to review newly installed hooks once via /hooks.
Requires Cursor 2.5+ (plugins were introduced there). Add the repository as a marketplace:
cursor-agent plugin marketplace add https://github.com/AbsoluteMode/session-recall.gitThen type /add-plugin session-recall in Cursor Agent and approve the local stdio MCP
server once, so the tools can start. For plugin development, launch
cursor-agent --plugin-dir /absolute/path/to/session-recall instead of installing a
cached copy.
Cursor is auto-detected at its normal macOS/Linux data path and does not need to be
running. Portable or custom profile? Point at the database directly with
SESSION_RECALL_CURSOR_DB=/path/to/User/globalStorage/state.vscdb.
3. Check it works
session-recall search "something you actually discussed last week"Hits with a score mean semantic search is live. In the agent, claude mcp list should
show session-recall ✔ Connected, and asking about past work should trigger
recall_search. Nothing else to configure: each plugin ships its host's startup hook and
re-indexes in the background, so the shared index keeps up with all three histories on its
own.
How it works
flowchart TB
subgraph Sources["local history sources"]
CC["Claude Code JSONL"]
CX["Codex JSONL"]
CU["Cursor SQLite"]
end
CC --> I["incremental indexer"]
CX --> I
CU -->|"consistent WAL snapshot"| I
I --> V["conversation surface → embeddings"]
I --> R["raw trace, kept local"]
V --> DB["SQLite · sqlite-vec KNN · FTS5"]
R --> DB
DB --> MCP["five on-demand MCP tools"]
MCP --> A["Claude Code · Codex · Cursor · any MCP client"]Only the conversation "surface" is embedded — user prompts and assistant text replies. Tool
calls, results, reasoning, and other trace data are never sent to an embedding provider but
stay reachable on demand via expand_around, step, and grep. Claude sidechains and
spawned-subagent sessions are intentionally skipped: under-the-hood tooling, not the
conversation.
Cursor is read from its SQLite store with the online backup API, so a live WAL database is captured consistently without blocking the editor. Its bubbles are normalized into durable, content-addressed JSONL snapshots under the data directory — deep navigation keeps working after Cursor closes, upgrades, or is uninstalled.
Indexing is incremental and cheap on live transcripts: they are append-only, so unchanged chunks are matched by content hash and their vectors reused — only new turns hit the embedding provider. Moving a Codex rollout into the archive also reuses its vectors. Each file indexes in its own transaction; a failing file is logged and retried next run, never aborting the rest.
CLI cheat sheet
# Refresh every history, or one source
session-recall index
session-recall index --source cursor
# Semantic search — unified by default, scopable to a repo
session-recall search "why did we choose the keeper service?"
session-recall search "deployment work" --source codex --scope /work/keeper
# Local calendar dates, any IANA timezone (defaults to this computer's)
session-recall recent --date 2026-07-14
session-recall search "deployment work" \
--start-date 2026-07-14 --end-date 2026-07-16 \
--timezone Asia/Yekaterinburg
# Exact raw scan — no embedding call, caps at 100 matches by default
session-recall grep "invalid_grant" --limit 100
# Housekeeping
session-recall prune # drop rows for transcripts deleted from disk
session-recall health # the whole chain, verdict GREEN/AMBER/REDsearch, recent, grep, and prune all take --source claude|codex|cursor; omit it for
the unified history. Date filters are inclusive and either boundary may be omitted.
Embedding providers
Nothing is locked to one vendor. SESSION_RECALL_EMBED=<preset> sets endpoint, model,
dimension, and reranker together, because those four are not independent choices:
Preset | Runs | Model | Dim | Reranker |
| bundled, free |
| 384 | — |
| bundled, free |
| 512 | — |
| bundled, free |
| 384 | — |
| local, free |
| 768 | — |
| local, free |
| 768 | — |
| hosted, needs a key |
| 1024 |
|
| hosted, needs a key |
| 1024 | — |
With no preset set, Session Recall picks Voyage when VOYAGE_API_KEY is present, then
probes for a local server already listening, and otherwise runs the bundled ONNX model —
out of the box always works. The bundled flavor follows the interaction language you chose
at onboarding (SESSION_RECALL_LANG=en|zh|…: a small English or Chinese specialist,
multilingual otherwise). First use downloads the model once into the data dir (70–240 MB),
CPU inference from then on. Ranking is noticeably coarser than hosted Voyage — a starting
point, not the ceiling. Local presets ship no reranker, so ranking is KNN + FTS only.
Free and local, start to finish:
ollama pull nomic-embed-text
export SESSION_RECALL_EMBED=ollama
session-recall indexYour own endpoint — any server speaking /v1/embeddings (llama.cpp, vLLM, a company
gateway). Individual variables always beat the preset, so mix freely:
export SESSION_RECALL_EMBED_PROVIDER=openai-compatible
export SESSION_RECALL_EMBED_BASE_URL=https://embeddings.internal/v1
export SESSION_RECALL_EMBED_MODEL=your-model
export SESSION_RECALL_EMBED_DIM=1024A different embedder needs its own index. Vector tables are fixed-width, so changing
the model or dimension means rebuilding: delete ~/.local/share/session-recall/index.db
and re-run index. Session Recall fingerprints the embedding space of every indexed file
and refuses to mix spaces — semantic search shuts off with an explicit message instead of
returning misleading rankings.
nomic-embed-text is the local default because it is Apache-2.0 and installs in one
command. Stronger small models exist — jina-embeddings-v5-text-nano scores far higher for
its size — but they are CC BY-NC, which anyone indexing work history would be violating
without ever being told. If your use is genuinely non-commercial, point the variables above
at one. If you work in more than English, qwen3-embedding:0.6b (Apache-2.0) handles
multilingual history far better than nomic.
Keeping the index fresh
If you installed a plugin, this is already handled: the bundled SessionStart hook runs
session-recall index in the background on every session start, and incremental indexing
keeps it cheap.
In ~/.claude/settings.json:
"hooks": {
"SessionStart": [
{ "hooks": [ {
"type": "command",
"command": "sr=/abs/path/.venv/bin/session-recall; pgrep -f \"$sr index\" >/dev/null 2>&1 || (VOYAGE_API_KEY=... \"$sr\" index >/tmp/sr-index.log 2>&1 &)"
} ] }
]
}The pgrep guard prevents overlapping runs; ( … & ) detaches so session start doesn't
wait. Keep the host-level hook synchronous — the shell already backgrounds the indexer, and
Codex ignores Claude's async extension. A launchd/cron timer works too.
Team mode — ask a colleague's history
The same recall, across machines: pair with a colleague once, and your agent can ask their agent about their past work.
you → a colleague's agent: when you hit the local-launch problem with X — how did you solve it?
their agent (after the colleague approves the answer): pin the config to …, then …, and the problem does not come back.
What used to be a Slack thread and a half-remembered explanation becomes one question and one grounded answer. You never see the colleague's raw history — only the answer they approved.
Privacy here is mechanics, not policy:
questions and answers travel as end-to-end encrypted envelopes; the relay stores blind blobs it cannot read;
answers are built by an isolated read-only worker, scoped to the projects that contact was explicitly granted (
share allow);every candidate answer passes a secret scanner and then explicit owner approval (Telegram bot, or
share approvelocally) before it leaves the machine;a contact can be paused any time (
share pause), a peer revoked (share revoke).
Searching a peer's index needs no embedding setup on your side: the query travels as text, and the owner's worker embeds it with their own provider against their own index.
A fresh install has no transport and never talks to a server you didn't choose. The relay is blind — everything it carries is sealed and signed on the clients — so which one to use is coordination between peers, not a matter of trust.
Shared folder — zero infrastructure. Two accounts on one machine, or any folder both peers sync (Syncthing, Dropbox, an NFS mount):
export SESSION_RECALL_SHARE_TRANSPORT_DIR=~/Sync/sr-share # both peers, same folderYour relay on the LAN. One machine runs it, everyone points at it. Envelopes are end-to-end encrypted regardless, but this is plain HTTP — keep it to a network you trust:
session-recall share relay --port 8787 --host 0.0.0.0 # on the relay machine
export SESSION_RECALL_RELAY_URL=http://192.168.1.20:8787 # on every peerYour relay on the internet. The relay binds localhost on purpose and expects a TLS terminator in front (Caddy is the two-line option):
session-recall share relay --port 8787 # binds 127.0.0.1relay.example.com {
reverse_proxy 127.0.0.1:8787
}Then on every peer: export SESSION_RECALL_RELAY_URL=https://relay.example.com. The relay
stores only sealed blobs, and a mailbox is emptied on fetch. SESSION_RECALL_RELAY_URL=none
keeps an install network-silent on purpose. Put the export in your shell profile so agents
and timers see it too.
Pairing is a one-time ceremony with a short SAS check, then asking is one command:
session-recall share init # once per device, both sides
session-recall share invite # you: prints a one-time code
session-recall share join <code> # colleague: accepts it
session-recall share complete # you: finish the handshake
session-recall share trust <name> # both: confirm the SAS matched, name the peer
session-recall share allow <name> <project>
session-recall share notify # owner side: worker + approval loop
session-recall share ask <name> "how did you fix the local X launch?"
session-recall share fetch # collect the answersMeta docs — the project's memory, written down
Raw recall answers what was said. Meta docs answers what agents actually ask mid-task: was this bug fixed before? how do I perform this action? why was it decided this way? A daily job hands each session's dialogue — user messages and final answers, never the tool noise — to a distiller agent that maintains Markdown entries in a Git repository you choose:
<project>/bugs/— bugs that were actually fixed: how each was recognized, diagnosed, fixed, and proven fixed;<project>/actions/— procedures, step by step, written so an agent asked again can follow the entry alone;<project>/decisions/— contested choices: what was decided, why that way, what was rejected;USER/— a global map of where your information lives and how to find it (lookup commands and storage locations — never the stored values themselves).
session-recall metadocs init ~/meta-docs --from-today # memory starts now
session-recall metadocs run # one pass now
session-recall metadocs enable # daily job: launchd (macOS) / systemd user timer (Linux)
session-recall metadocs status
session-recall metadocs index-history --days 30 # opt-in: distill the past, onceThe distiller's whole world is four MCP verbs — search / create / edit / delete — and the
load-bearing rules are server mechanics, not prompt requests: create is refused until the
agent has searched (dedup is mandatory), entries are scanned for secrets before a byte
reaches disk, and delete demands a reason. Runs are incremental, and each changed project
gets its own local commit — review is a diff, undo is a revert, and sharing the memory with
a team is just pushing the repo somewhere private. Nothing is pushed unless you opt into
--push; the engine and model come from config only
(init --engine claude-cli|codex --model …) — nothing is picked silently.
Privacy is a hard invariant
This is a public repository. Only code goes in it. Runtime data lives under
~/.local/share/session-recall/, outside the repo tree — it physically cannot be committed.
Stays on your machine | Leaves only when you choose it |
Original Claude Code and Codex transcripts | Conversation surface text → your configured hosted embedder |
Cursor's SQLite store and its normalized snapshots | An explicitly approved team-mode answer |
Tool calls, outputs, reasoning — the whole raw trace | Nothing, on the bundled/local embedding path |
The SQLite index and stored vectors |
API keys are environment variables only;
.gitignoreblocks.env.Tests use synthetic fixtures, never a real slice of a session.
The bundled provider keeps the entire indexing path on-device. If you choose a hosted provider, pick one you trust with your transcript surface text.
Troubleshooting
Start here — it checks the whole chain and exits non-zero when something is actually broken, so it also works from a timer:
$ session-recall health
[ok ] Freshness 2 minutes behind
[warn] Embedder responded in 5828 ms
→ slow provider will make indexing crawl
[ok ] Vector space builtin/BAAI/bge-small-en-v1.5/384
[ok ] Corpus 1054 sessions (claude 373, codex 680, cursor 1)
[ok ] Sources claude, codex, cursor present
verdict: AMBER (voyage/voyage-4-large, index at ~/.local/share/session-recall/index.db)Freshness compares the newest transcript on disk against the newest turn in the index, so an indexer that runs on every session and fails every time still shows as behind — exactly the failure that is otherwise invisible.
Symptom | Cause / next step |
| The embedding provider is unreachable — only literal matching ran. Results are real, but a miss proves nothing. |
| The index was built in a different embedding space. Run |
Indexer logs | Not your key: a WAF is blocking your IP (common on VPN and datacenter exits). The same 403 appears with no key at all. Route egress elsewhere or switch provider. |
| A SOCKS proxy is set in the environment but |
| The indexer has not succeeded recently. Run |
Cursor lives in a custom profile | Set |
Development
git clone https://github.com/AbsoluteMode/session-recall.git
cd session-recall
python -m venv .venv
.venv/bin/pip install -e ".[dev]"
.venv/bin/pytest -qTo register the MCP server by hand instead of using the plugin:
claude mcp add session-recall --scope user -- /absolute/path/.venv/bin/session-recall-mcpEngineering rationale and invariants live in docs/decisions/. Start with:
Roadmap
Hosted/team index — one shared index for a team instead of per-machine copies. The honest open question: whoever searches must embed the query, so a shared vector space implies a shared embedding path.
Per-contact approval bypass — skip per-answer approval for peers you fully trust; today every answer is approved explicitly.
More histories — other agents' transcripts beyond Claude Code, Codex, and Cursor.
Contributing
Issues, documentation improvements, host adapters, and translations are welcome. Keep fixtures synthetic and never commit real transcripts, indexes, embeddings, or credentials.
Available Tools
5 toolsexpand_aroundC
Return the raw turns around an anchor (tool calls, outputs, thinking).
| Name | Required | Description | Default |
|---|---|---|---|
| uuid | Yes | ||
| after | No | ||
| before | No | ||
| session_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must fully disclose behavior. It only states the action and result type, but omits side effects, safety profile, permissions, or what qualifies as a 'turn'. The term 'raw' is vague.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but overly terse. It could include essential parameter relationships without becoming lengthy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, required uuid and session_id) and lack of annotations, the description is insufficient. The output schema may partially compensate, but the description should explain the anchor concept more clearly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain any parameters (uuid, session_id, after, before). With 0% schema description coverage, the agent receives no semantic help beyond parameter names and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the tool returns raw turns around an anchor, listing the content types (tool calls, outputs, thinking). It distinguishes the tool's purpose from siblings like grep or recall_search, though it could explicitly contrast them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., grep for searching turns, step for navigation). The description lacks contextual hints for triggering conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
grepB
On-demand substring scan over raw session transcripts.
scope_cwd: pass your current working directory to restrict the scan to the current project/repo; omit for a global scan.
| Name | Required | Description | Default |
|---|---|---|---|
| pattern | Yes | ||
| scope_cwd | No | ||
| session_id | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so description must fully disclose behavior. It indicates a non-destructive read operation but lacks details on permissions, rate limits, performance, or what happens on missing indices. The mention of 'raw session transcripts' gives data source context but is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with purpose and usage guidance front-loaded. No wasted words, but could be slightly more structured (e.g., separate lines for parameters).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 3 parameters, no annotations, and an output schema (not shown), the description covers the main goal and one parameter's usage. Missing details on pattern format and session_id, as well as behavioral aspects. Sufficient for a simple scan but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It explains scope_cwd (how to restrict scanning) but does not describe pattern (required) or session_id. Pattern being a substring vs regex is ambiguous, and session_id's purpose is unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool performs an on-demand substring scan over raw session transcripts, which is specific and distinct from sibling tools like recall_search (likely semantic) and expand_around. However, it does not explicitly differentiate from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides guidance on when to use scope_cwd (restrict to project vs global scan), but no explicit guidance on when to use this tool versus alternatives, nor when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
recall_searchA
Semantically search past Claude Code sessions. Returns ranked anchors.
scope_cwd: pass your current working directory to restrict results to the current project/repo (worktrees collapse to the repo root). Omit it for a global, cross-project search.
| Name | Required | Description | Default |
|---|---|---|---|
| k | No | ||
| query | Yes | ||
| scope_cwd | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries behavioral burden. It discloses semantic search and ranking, but does not mention read-only nature, side effects, permissions, or rate limits. 'Anchors' are not defined, leaving some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences: one for purpose and one for parameter explanation. No redundant words. However, it lacks parameter details which would improve structure without adding much length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 3 parameters and an output schema, the description covers purpose and one parameter well. However, missing explanations for 'query' and 'k' make it incomplete. The output schema existence partially mitigates need for return value details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must add meaning. Only scope_cwd is explained in detail; query and k parameters have no semantic description. k likely controls number of results but is not stated. This leaves significant gaps for agent usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb 'semantically search' and resource 'past Claude Code sessions', with clear output 'ranked anchors'. It distinguishes from siblings like grep (text search) and recent_sessions (list) by focusing on semantic search across sessions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use scope_cwd (restrict to project) versus omit (global), but lacks explicit guidance on when to use recall_search over siblings like grep or step. No when-not-to-use or alternative suggestions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
recent_sessionsA
List the most recently active past sessions, freshest first — use to see the current state of work and how fresh the index is (the top entry's last_activity_human is the effective freshness). Also surfaces the sessions of a thread split across resume-created session_ids so you can reassemble the arc.
scope_cwd: pass your current working directory to restrict to the current project/repo (worktrees collapse to the repo root); omit for all projects. Each entry: session_id, project, turns, last_activity (epoch), last_activity_human, label (the session's first user prompt).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| scope_cwd | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description fully discloses behavior: lists sessions sorted by freshness, includes fields, and explains scope_cwd parameter effect. No contradictions or hidden traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured: starts with main purpose, then provides usage details. Slightly verbose but each sentence adds value. Could be condensed slightly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists, and description already explains return fields (session_id, project, turns, last_activity, etc.). Complete for a list tool with good parameter explanations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but description adds meaning: explains default limit (10) and scope_cwd usage (restrict to current directory). Provides semantic context beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it lists most recently active sessions, freshest first. Verb 'list' and resource 'recent sessions' are specific. Distinguishes from siblings by describing its unique purpose: surfacing session arcs across thread splits.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Describes when to use: to see current state of work, freshness, and reassemble thread arcs. Does not explicitly mention when not to use or alternatives, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
stepC
Walk to an adjacent turn ('next' or 'prev').
| Name | Required | Description | Default |
|---|---|---|---|
| uuid | Yes | ||
| count | No | ||
| direction | Yes | ||
| session_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description is the sole source of behavioral info. It only mentions the basic action without discussing side effects, permissions, rate limits, or the effect of the 'count' parameter. The tool's behavior beyond a single step is opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence), which is concise but does not front-load critical parameter info. It could be equally concise yet more informative by adding parameter hints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters (3 required) and an output schema, the description is insufficient. It does not explain how sessions, UUIDs, or counts relate to walking, nor what the tool returns. This makes it hard for an AI agent to use correctly without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate, but it only mentions 'direction' ('next' or 'prev'). It does not explain 'uuid', 'session_id', or 'count' (with default 1). Users are left guessing the meaning and purpose of these parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Walk' and the resource 'adjacent turn', with acceptable direction values 'next' or 'prev'. It is specific enough to distinguish from sibling tools like expand_around, grep, recall_search, recent_sessions, which are not navigation-focused.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, or any prerequisites. The description lacks context on when stepping makes sense or when other tools might be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
5 tool updates
v0.2.0- First observed
expand_around - First observed
grep - First observed
recall_search - First observed
recent_sessions - First observed
step
TDQS
Each tool has a clearly distinct purpose: expand_around navigates near an anchor, grep does substring search, recall_search performs semantic search, recent_sessions lists sessions, and step moves between turns. No overlap that would cause confusion.
Most names follow a verb_noun pattern (expand_around, recall_search, recent_sessions), but grep and step are single-word names that break the pattern. Still, they are clear and not mixed conventions like camelCase.
5 tools is well-scoped for a session recall server. It provides search, listing, and navigation without being overwhelming or too sparse.
The tool surface covers core needs (search, list, navigate) but lacks a direct way to fetch a specific session's full transcript by ID. This is a minor gap that agents can work around using recent_sessions and expand_around.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Project memory, semantic code search, and grounded agent context.
Shared memory for coding agents. Stop re-explaining your codebase every session.
Persistent memory for AI agents. Search, store, and recall across sessions.
- AmberOAuthcom.ambermem
Long-term memory for AI assistants. Hybrid retrieval, query expansion, auto-topics.
Related MCP Servers
- AlicenseAqualityDmaintenanceSemantic search across Claude Code conversations. Hybrid vector + keyword search, fully local, background indexing.6758MIT
- AlicenseNot gradedqualityCmaintenanceEnables searching and retrieving Claude Code conversation history via hybrid semantic and keyword search, allowing the agent to access its own past interactions.4MIT
- AlicenseNot gradedqualityDmaintenanceLocal memory search for Codex and Claude Code conversations. It keeps history on your machine, builds a local graph index, and returns compact evidence from past sessions.5MIT
- FlicenseNot gradedqualityBmaintenanceLocal semantic search over Claude Code sessions and shell command history, exposed to Claude Code as an MCP tool. Everything is indexed into one vector space and runs entirely on your machine.2-
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/AbsoluteMode/session-recall'
If you have feedback or need assistance with the MCP directory API, please join our Discord server