Skip to main content
Glama
Zavelinski

recall

by Zavelinski
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Local

recall

A zero-dependency MCP server for cross-session memory recall in Claude Code. It exposes lexical search / list / get over your Claude memory files so a new session can find what past sessions decided and learned, without re-explaining.

No native deps, no SDK: pure Node stdlib implementing the MCP stdio JSON-RPC protocol by hand. It installs and runs anywhere Node 18+ exists.

Why

Context is fragile across sessions; power users build their own (Chronicle, Recall-with-Redis) to recall files, decisions, and chats. Memory consolidation work (RecMem, agentmemory) shows the value of distilling recurring knowledge rather than re-loading everything. recall is the minimal, dependency-free first step: make the memory you already write searchable from any session.

Related MCP server: claudecode-infinite-memory

Tools

  • recall_search(query, limit=5): ranked lexical search over memory files, returns name, score, snippet, file.

  • recall_list(): all memory entries (name, description, file).

  • recall_get(name): full content of one entry by frontmatter name or filename.

Read-only by design in v0.1. It never writes or deletes.

Install (Claude Code)

Add to your MCP config (~/.claude/settings.json, or wherever you manage MCP servers):

"mcpServers": {
  "recall": {
    "command": "node",
    "args": ["C:\\Users\\<you>\\recall\\server.js"],
    "env": { "RECALL_MEMORY_DIR": "" }
  }
}

  • RECALL_MEMORY_DIR (optional): point at a specific memory folder. If unset, recall scans every ~/.claude/projects/<slug>/memory/ directory.

  • As a plugin, .claude-plugin/plugin.json already declares the server via ${CLAUDE_PLUGIN_ROOT}/server.js.

Restart Claude Code; the recall_* tools appear.

Verify it yourself (no network needed)

printf '%s\n%s\n' \
'{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{}}}' \
'{"jsonrpc":"2.0","id":2,"method":"tools/list"}' | node server.js

You should get an initialize result with serverInfo and a tools/list with three tools.

Limits / roadmap

  • v0.1 is lexical (term-frequency). It does not do semantic/embedding search yet.

  • v0.2 (planned): optional embeddings + hybrid retrieval (e.g. sqlite-vec + BM25/FTS5) behind a flag, plus confidence/lifecycle tags. Those add native deps; v0.1 stays dependency-free on purpose.

License

MIT

Part of the claude-code-skills collection: a one-line Claude Code plugin marketplace of focused skills, plugins, and MCP servers.

/plugin marketplace add Zavelinski/claude-code-skills

Available Tools

3 tools
recall_getA

Get the full content of one memory entry by its name (frontmatter name or filename).

ParametersJSON Schema
NameRequiredDescriptionDefault
nameYesEntry name.

TDQS

A3.5/5.0
Behavior2/5

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

No annotations provided, so description carries full burden. Only states 'Get the full content' with no info on error behavior, performance, or side effects. For a simple read operation, the lack of any extra behavioral context is a gap.

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?

Single sentence, no extraneous words. Front-loaded with key action and resource. Highly efficient.

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 a simple one-parameter tool with no output schema, the description is mostly complete. It could mention return format or behavior when entry not found, but overall adequate.

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% with a basic description for the 'name' parameter. The description adds 'frontmatter name or filename', clarifying what the name represents beyond the schema. This adds value.

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?

Clearly states it gets the full content of a memory entry by name. Verb 'Get' and resource 'full content of one memory entry' are specific. Does not explicitly distinguish from siblings but the purpose is clear.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Specifies the identifier method ('frontmatter name or filename'), providing usage context. However, lacks explicit when-to-use or when-not-to-use guidance, and does not contrast with sibling tools recall_list and recall_search.

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

recall_listA

List all memory entries (name + description + file path).

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.5/5.0
Behavior2/5

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

With no annotations, the description must fully disclose behavior. It only says 'list all memory entries' – no mention of pagination, limits, ordering, or whether it returns all fields (name, description, file path) without filtering.

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?

Single sentence, no wasted words. Front-loaded with core action and output fields.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Adequate for a zero-parameter list tool, but lacks output schema and any behavioral details beyond basic listing. Could mention what 'all' means (e.g., within a workspace) or whether results are paginated.

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?

No parameters exist in the schema, so the description does not need to elaborate. Baseline 4 applies per rules for 0 parameters.

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 it lists all memory entries with specific fields (name, description, file path). It implicitly distinguishes from siblings 'recall_get' and 'recall_search', which likely handle single retrieval or search.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives. No indication of when to use recall_list vs recall_get or recall_search.

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.

  1. 3 tool updatesv0.1.0
    • First observedrecall_get
    • First observedrecall_list
    • First observedrecall_search
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.8/5.0
Disambiguation5/5

Each tool serves a clearly distinct purpose: recall_get retrieves a single entry by name, recall_list enumerates all entries, and recall_search performs lexical search. No functional overlap exists.

Naming Consistency5/5

All tools follow a consistent 'recall_verb' pattern with clear, imperative verbs (get, list, search). The naming is predictable and easy to understand.

Tool Count4/5

With only 3 tools, the surface is minimal but appropriate for a read-only memory retrieval server. It covers the essential retrieval operations without unnecessary bloat.

Completeness4/5

The server provides complete coverage for reading memories (get by name, list all, search). Missing write operations (create, update, delete) are likely intentional, making the set complete for its stated purpose.

Maintenance

ActivityStale
ResponsivenessNo issues

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

Related MCP Servers

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/Zavelinski/recall'

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