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., "@MemoCall what was I working on last session?"
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.
An MCP server that lets Claude Code recall the context of your past conversations — from any project — on demand.
Claude Code can resume a session, but getting another conversation's context into the one you're in is a chore — copy-pasting exports or digging through raw transcript files by hand — and resume only sees the current directory anyway. MemoCall turns it into a single ask: "what was I working on?" or "load the session where we set up X", and it pulls that transcript in as clean, compact Markdown — even from a totally different project.
It's read-only. Claude Code already records every session to ~/.claude/projects/<project>/<id>.jsonl; this server just reads those files, strips the noise, collapses tool calls, and hands back a readable transcript. It never writes, hooks, or touches a live session.
Five tools, available in every session once installed. Claude picks the right one from the request:
Tool | What it does |
| Your recent conversations across all projects, grouped by directory. "What was I working on?" |
| Find a past conversation by keyword (matches titles + first messages + paths). |
| Load one conversation as compact Markdown — by |
| A cheap map of one conversation: the numbered list of your prompts. Great for huge sessions. |
| Return only the turns within one conversation that match a keyword. |
You don't call these directly — you talk normally and Claude reaches for them:
You: what sessions have i worked on recently?
You: load the one where we set up the license invitation system
You: which session did we debug the keychain SIGKILL thing in?Related MCP server: Cortex
Raw transcripts are a verbose event log (one big file hit 11 MB). memocall reduces each turn to the essentials, Conductor-style:
**You:** right now i need to set up a system to invite prospects...
↳ 12 tool calls (Bash ×5, Read ×4, Edit ×3)
**Claude:** I've set up the invitation flow. Key decisions: ...Tool-call outputs are elided (the big token win, and a privacy win — see below). Abandoned/edited message branches are dropped so you get the conversation as it actually played out. A token budget keeps even an 11 MB session well under Claude Code's MCP output cap via middle-out truncation.
A single response can't hold a 1,000-turn session, so for big ones you don't dump — you navigate:
session_outline → a numbered map of every prompt (tiny, fits any session).
search_in_session → jump straight to the turns about a topic, or load_session with turns: "300-340" to pull an exact window (turn numbers come from the outline).
So you never lose access to the middle of a huge conversation — load_session alone would middle-out-truncate it, but the outline + range/search tools let Claude reach any part on demand.
Requires the Claude Code CLI (and Node 18+). One line — npx fetches and runs the published package:
claude mcp add --scope user memocall -- npx -y memocall--scope user makes it available in every session, in every directory. Restart Claude Code (or open a new session) and ask it to list your sessions. Verify with claude mcp list — you should see memocall: … ✔ Connected.
git clone https://github.com/baodq06/memocall.git
cd memocall && npm install && npm run build
claude mcp add --scope user memocall -- node "$(pwd)/dist/index.js"Local only. No network, no auth, no telemetry. It reads files under ~/.claude/projects/ and nothing else.
Compact mode elides tool outputs, which is where secrets (tokens, keys, env) usually live — so the default output is much safer than the raw transcript.
format: "full" includes brief tool inputs and may surface sensitive strings. Use it deliberately.
Transcripts can contain secrets regardless; treat loaded context as you would the original conversation.
Recall is best-effort: Claude Code deletes transcripts after cleanupPeriodDays (default 30).
Forked sessions may only contain post-fork turns.
The transcript format is undocumented and can change between Claude Code versions; all format knowledge is isolated in src/jsonl.ts so it's a one-file patch if it does.
npm run build # compile TypeScript -> dist/
npm test # unit suite (node:test) on synthetic fixtures
npm run smoke # optional: checks all YOUR real sessions stay under the output cap
node dist/parser.js <file.jsonl> [--full|--outline] [--turns 10-20] [--search "kw"] [--max N] [--think] # test the parser
node test-client.mjs # drive the server over stdio like Claude Code does
npm run inspect # open the MCP Inspector UILayout:
src/jsonl.ts — all knowledge of the transcript format (helpers, ordering, classification).
src/parser.ts — JSONL → compact Markdown (the core transform).
src/locator.ts — session enumeration + cached metadata index.
src/index.ts — the MCP server wiring the three tools.
MIT
List your recent Claude Code conversations across ALL projects, grouped by project directory. Use this to answer 'what sessions have I worked on recently?' or to find a past session before loading it. Returns each session's title, date, turn count, and id.
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | No | Optional: only show sessions whose project path contains this substring. | |
| limit | No | Max sessions to list (default 40). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. It states it returns title, date, turn count, and id, implying a read-only operation, but doesn't mention rate limits or data freshness. Adequate but not thorough.
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, front-loaded with purpose, no superfluous information. Every sentence adds value.
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?
For a simple list operation with only 2 optional parameters and no output schema, the description covers return fields, grouping behavior, and usage context. Slightly more could be said about ordering or data source, but it's sufficient.
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 100% so description does not need to add much. The description mentions grouping by project directory, but both parameters are already described in schema (cwd filter and limit). No added semantics 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?
The description clearly states the tool lists recent Claude Code conversations across all projects, grouped by project directory. It distinguishes from siblings like load_session, search_in_session, etc., which are different operations.
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?
Explicit examples of when to use: answering 'what sessions have I worked on recently?' or finding a past session before loading it. No explicit exclusions, 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.
Load the context of a past Claude Code conversation as compact Markdown (human turns, collapsed tool-call summaries, and assistant replies — tool outputs are elided). Provide either a session id (from list_sessions/search_sessions) or a free-text query to find it. Use this to pull a previous conversation's context into the current session. For a very large session, either pass turns to load a specific window (turn numbers come from session_outline), or prefer session_outline / search_in_session.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Session id (uuid) from list_sessions/search_sessions. | |
| query | No | Free-text to locate the session if you don't have an id. | |
| format | No | compact (default): elide tool details. full: include brief tool inputs. | |
| turns | No | Load only a turn range, 1-based inclusive: "300-340", "300-", "-50", or "300". Turn numbers come from session_outline. | |
| maxTokens | No | Approx token budget for the returned transcript (default 16000, capped ~18000). | |
| includeThinking | No | Include a short trace of assistant thinking (default false). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description details the output content (elided tool outputs, collapsed summaries) and parameters (turns range, maxTokens limit, includeThinking). It is transparent about what the tool does and does not include, though it could mention error handling or side effects.
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 well-structured, front-loading the main action and then providing parameter guidance. It is concise with no redundant sentences, though slightly longer than necessary.
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 6 parameters, no output schema, and multiple siblings, the description covers key aspects: parameter usage, alternative tools for large sessions, and output format. It is complete enough for an agent to use correctly, though it lacks return value details beyond the initial statement.
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?
100% schema coverage, and the description adds significant value: explains id source (list_sessions/search_sessions), turns syntax (e.g., '300-340'), default format (compact), default maxTokens (16000), and the meaning of includeThinking. This goes well beyond the 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?
The description clearly states it loads a past conversation as compact Markdown, specifying what is included (human turns, collapsed tool-call summaries, assistant replies) and what is elided (tool outputs). It distinctly differentiates from siblings like list_sessions and session_outline.
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?
Explicitly says when to use: 'Use this to pull a previous conversation's context into the current session.' Provides when-not-to-use guidance for large sessions, suggesting session_outline or search_in_session instead, and references alternatives like list_sessions/search_sessions for ids.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find specific turns WITHIN one past Claude Code conversation by keyword — returns only the matching turns (with their turn numbers). Use when the user asks what was decided or discussed about a topic inside a known or large session (e.g. 'what did we decide about retries in that session'). Pick the session by id or session (free-text); query is the keyword to find inside it.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Keyword(s) to find inside the session. | |
| id | No | Session id from list_sessions/search_sessions. | |
| session | No | Free-text to locate the session if you don't have an id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description must cover behavior. It states returns matching turns with turn numbers, but omits details like case sensitivity or search scope. Adequate but not exhaustive.
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 concise sentences front-load purpose and then provide usage guidance. No redundancy or wasted words.
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?
For a search tool with no output schema or annotations, description covers purpose, usage, and parameter semantics reasonably well. Could elaborate on output format but is sufficient.
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 100%. Description adds value by explaining how to use parameters (e.g., session by id or free-text, query keyword). This enhances understanding 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?
The description clearly states the tool finds specific turns within one past conversation by keyword, returning matching turns with turn numbers. It differentiates from sibling tools like list_sessions and load_session by focusing on internal search.
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?
Explicit guidance is given: use when the user asks about a topic inside a known or large session, with an example. It does not explicitly list when not to use or alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search your past Claude Code conversations (across all projects) by keyword — matches session titles, first messages, and project paths. Use when the user refers to a past conversation by topic (e.g. 'the session where we set up the license system'). Returns matching sessions with their ids.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Keyword(s) to search for in titles / first messages / project paths. | |
| limit | No | Max results (default 20). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that it searches across all projects, matches specific fields, and returns matching sessions with IDs. However, it doesn't mention pagination, rate limits, or whether results are ordered, which are common behavioral traits. Adequate but not comprehensive.
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, front-loaded with key information, no superfluous words. Every sentence earns its place: first explains what the tool does, second provides usage guidance and return value.
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 2 parameters, no output schema, and no annotations, the description is reasonably complete. It specifies what fields are searched, that it searches across all projects, and that it returns IDs. It could mention default limit or sorting, but overall sufficient for an agent to invoke correctly.
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 100% (both query and limit are described in the schema). The description reinforces the query parameter by mentioning 'by keyword' but adds no new semantic detail beyond the schema. Baseline 3 is appropriate.
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 tool searches past Claude Code conversations by keyword, matching session titles, first messages, and project paths. It specifies the resource (conversations) and action (search), and distinguishes from siblings like list_sessions (which likely lists all) and search_in_session (which searches within a session).
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 explicitly states when to use: 'when the user refers to a past conversation by topic.' It provides an example. While it doesn't mention when not to use or alternatives explicitly, the sibling tools imply differentiation, so it's clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a quick MAP of a past Claude Code conversation: the numbered list of the user's prompts, one line each. Very cheap even for huge sessions. Use this to see what a session covered, or to find which turn numbers to then load with load_session's turns. Identify the session by id or free-text query.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Session id from list_sessions/search_sessions. | |
| query | No | Free-text to locate the session if you don't have an id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'Very cheap even for huge sessions' indicating efficiency and non-destructiveness. It describes output as a 'numbered list of user prompts.' It could add details like output format exactness, but it's fairly transparent about behavior.
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 three sentences, front-loaded with the core purpose and key features. Each sentence adds essential information: output, efficiency/use case, and identification method with sibling reference. No unnecessary words.
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 no output schema, the description explains the return value: 'numbered list of the user's prompts, one line each.' It covers identification and use cases. It could mention error scenarios or limitations, but for a simple tool it is sufficiently complete.
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 100%, so baseline is 3. The description adds value by explaining how parameters relate to usage: 'Identify the session by id or free-text query' and linking to load_session. This provides context beyond the schema descriptions.
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 tool's action: 'Get a quick MAP of a past Claude Code conversation: the numbered list of the user's prompts, one line each.' It uses specific verb and resource and distinguishes from siblings by noting it provides outlines and turn numbers for use with load_session.
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 indicates when to use: 'to see what a session covered, or to find which turn numbers to then load with load_session's turns.' It also explains identification by id or query. It does not explicitly state when not to use, but the context implies alternatives like load_session for full content.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0list_sessionsload_sessionsearch_in_sessionsearch_sessionssession_outlineEach tool targets a distinct operation: listing sessions, loading a session, searching within a session, searching across sessions, and outlining a session. There is no overlap in functionality.
Four tools follow the verb_noun pattern (list_sessions, load_session, search_in_session, search_sessions), while session_outline uses noun_verb. This minor deviation slightly breaks full consistency.
Five tools is appropriate for managing Claude Code sessions, covering the essential workflows without excess or deficiency.
The set covers listing, loading, searching, and outlining sessions. A tool for deleting or archiving sessions might be expected but is not critical, resulting in a minor gap.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Augments MCP Server - A comprehensive framework documentation provider for Claude Code
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
An MCP server that gives your AI access to the source code and docs of all public github repos
Cloud-hosted MCP server for durable AI memory
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/baodq06/memocall'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
