Skip to main content
Glama
andrewhomeyer

recall

by andrewhomeyer
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
TypeScript
Local

recall

Give your AI assistant a memory it keeps between conversations.

Normally, when you close a chat with an AI assistant, it forgets everything. Next time, you start from scratch. recall fixes that. It's a small add-on that gives your assistant a notebook it can write to and read back later, so the things you tell it once, it remembers for good.

It's built to be simple enough for people who are brand new to this. Using it day to day takes no coding at all. The one-time setup is a few copy-paste commands, walked through below.

What it's good for

  • Stop repeating yourself. Tell your assistant your preferences, your projects, or facts about your work once. It remembers them next time.

  • Keep notes your assistant can actually use. Decisions, reminders, how-you-like-things-done. Your assistant can look them up on its own when they're relevant.

  • Your memory, your files. Memories are saved as plain text files on your own computer that you can open and read anytime. They stay local by default (see the short privacy note below for the full picture).

Here's the kind of thing it makes possible:

You: Remember that I prefer short, plain-language answers and that my business is called Birchwood Bakery.

Assistant: Saved. (writes a memory)

...a week later, in a brand-new conversation...

You: Draft a welcome note for a new client.

Assistant: (quietly looks up what it knows about you, then writes a short, plain-language note signed Birchwood Bakery)

Related MCP server: Vector Memory MCP Server

What you need first

Two free tools, installed once:

  1. Node.js (this is what runs recall). Go to https://nodejs.org, download the version marked "LTS", open it, and click through the installer.

  2. Git (this is used to download recall in the next step). Most Macs already have it. To check, type git --version in Terminal; if it prints a version number, you're set. If not, it will offer to install it, or you can get it from https://git-scm.com.

Prefer not to touch Git at all? Once recall is on GitHub, you can click the green Code button on its page, choose Download ZIP, unzip it into your home folder, and skip the git clone line in the next step.

You only ever do this once.

Install it (the simple way)

Copy and paste these lines one at a time into your Terminal (on Mac: press Cmd+Space, type "Terminal", press Enter):

# 1. Download recall into a folder in your home directory
git clone https://github.com/andrewhomeyer/recall-mcp.git ~/recall-mcp

# 2. Go into that folder
cd ~/recall-mcp

# 3. Set it up and build it (one command)
npm install && npm run build

When the last command finishes, recall is ready. You won't need to do this again.

Connect it to your AI assistant

recall works with any app that supports MCP (Model Context Protocol, the open standard for plugging tools into AI assistants). The setup is the same everywhere: you point the app at node ~/recall-mcp/dist/index.js. By default every app you connect shares the same memory, so what you tell one, the others know too.

Claude Desktop

  1. Open Claude Desktop.

  2. In the menu bar, open Settings → Developer → Edit Config. This opens a file called claude_desktop_config.json.

  3. Paste the recall block below inside it (if there's already text there, ask your assistant to help you merge it in):

{
  "mcpServers": {
    "recall": {
      "command": "node",
      "args": ["REPLACE_WITH_YOUR_HOME/recall-mcp/dist/index.js"]
    }
  }
}

  1. Replace REPLACE_WITH_YOUR_HOME with your home folder path. To find it, type echo $HOME in Terminal and paste what it prints. (For example: /Users/yourname.)

  2. Fully quit and reopen Claude Desktop.

Claude Code

One line in Terminal:

claude mcp add recall -- node ~/recall-mcp/dist/index.js

Cursor

Open (or create) the file ~/.cursor/mcp.json and paste the same recall block shown for Claude Desktop above. Restart Cursor.

Cline, Windsurf, Zed, and any other MCP app

They all use the identical pattern. Wherever the app lists its "MCP servers," add one named recall with:

  • command: node

  • argument: the full path to your recall-mcp/dist/index.js

If an app supports MCP, recall works with it. You built it once; every app shares it.

You'll know it worked when you can ask your assistant to remember something, start a brand-new conversation, and it still knows.

How to use it

You don't push buttons or learn commands. You just talk to your assistant normally:

  • To save something: "Remember that..." or "Make a note that..."

  • To recall something: "What do you know about...?" or "Look up my notes on..."

  • To review: "List everything you've remembered."

  • To forget something: "Delete the note about..."

Your assistant decides when to use its memory on its own, the same way a good assistant would glance at their notebook before answering.

Your memory grows with you

The more you use recall, the more useful it gets. Whenever something is worth keeping, just tell your assistant to remember it. A simple habit that works well: once a week, take a minute to tell it the handful of new things worth holding onto. New preferences, a decision you made, a fact about a project. Over a few months it builds into a genuine picture of you and your work, and you stop having to re-explain the basics.

You can also tend it by hand. Because every memory is a plain text file, you can open the folder, fix a detail, delete something that is no longer true, or add a note yourself. There is no database and no account. It is just text. (If a hand-edited file gets garbled, recall simply skips that one file and keeps working.)

Take it from one assistant to another

Your memory is a folder of files, so it travels the way any folder does. This is one of the biggest differences from built-in memory:

  • Use it in two apps at once. By default, every app you connect points at the same folder, so a memory you save in Claude Desktop is instantly available in Cursor, Claude Code, or anything else you have set up.

  • Move to a new computer. Copy the folder across, install recall on the new machine, and everything is there.

  • Switch tools entirely. If you stop using one assistant and start using another, your memory stays with you. It was never locked inside the old one.

Where your memories live (and how to back them up)

By default, your memories live in a hidden folder called .recall in your home directory. Each memory is a plain text file with a short label, a one-line summary, a category, and the note itself. You can open them in any text editor. Nothing is hidden or locked away, and you can keep them there without ever thinking about it.

If you want them backed up automatically or synced across your devices, put the folder inside a service you already use, like Dropbox, iCloud Drive, or Google Drive, and tell recall where it is. For example, to keep your memory in Dropbox, add one line to your setup:

{
  "mcpServers": {
    "recall": {
      "command": "node",
      "args": ["REPLACE_WITH_YOUR_HOME/recall-mcp/dist/index.js"],
      "env": {
        "RECALL_MEMORY_DIR": "REPLACE_WITH_YOUR_HOME/Dropbox/recall-memory"
      }
    }
  }
}

Now your memory is backed up by Dropbox and follows you to every device signed into it. (Developers: point RECALL_MEMORY_DIR at a git repository instead, and you get a full version history of every change your assistant makes.)

A quick note on privacy

recall stores your memories on your own computer by default. Two honest things to keep in mind:

  • Recalling a memory shares it with your assistant. When your assistant looks up a memory, that text becomes part of your conversation, so it is sent to your assistant's provider just like anything else you say to it.

  • Syncing puts the files with your sync service. If you choose to sync the folder (Dropbox, iCloud, Google Drive), those files are stored by that service.

So treat memories like notes, not a vault. Don't store passwords, API keys, or other secrets in them.

"Doesn't my AI already have memory?"

Some AI apps do include a built-in memory. recall is different in three ways that tend to matter once you rely on it:

  • You own it. Your memories are plain files on your own computer. You can read, back up, copy, move, or delete them yourself, anytime.

  • It's portable. The same memory works across every app you connect it to. Built-in memory is usually locked to the one product it came with. Switch apps and it doesn't come with you.

  • It's durable. Because it's just files you control, it survives app updates, account resets, and changing tools. Nothing can quietly forget or wipe it behind the scenes.

The honest trade-off: if you only ever use one AI app and never care to see or move your memories, that app's built-in memory may be all you need. recall is for when you want your memory to be yours, and to outlast any single app.

Under the hood (for developers)

recall is an MCP server written in TypeScript on the official SDK. It runs locally over stdio as a subprocess of the client.

Design

A memory is one atomic fact stored as a single Markdown file with YAML frontmatter:

---
name: client-tone
description: How the owner likes client-facing copy written
type: feedback
---

Short, plain-language, no jargon. Signed "Birchwood Bakery". See [[brand-voice]].

  • Typed. Every memory is one of user, feedback, project, or reference.

  • Recalled by relevance. A query is scored against each memory; a hit in the name outweighs the description, which outweighs the body (weights 10 / 3 / 1, credited once per field). Non-matches score 0 and are dropped.

  • Linked. [[wikilink]] references in a body build a lightweight graph between memories.

  • Indexed. A human-readable MEMORY.md index is rebuilt on every write and delete.

  • Resilient. A single malformed memory file is skipped (with a stderr warning) rather than breaking listing, search, or the index.

Tools

Tool

Purpose

Read-only

recall_write

Create a memory; refuses to overwrite unless overwrite: true

no

recall_get

Fetch one memory by name, with its full body

yes

recall_search

Recall memories relevant to a query, ranked

yes

recall_list

List memories (index view), paginated

yes

recall_links

Find inbound/outbound [[links]] for a memory

yes

recall_delete

Permanently delete a memory

no

Read tools accept response_format: "markdown" | "json".

Security

Memory names are constrained to a kebab-case slug at the schema boundary, and the file store independently re-validates and verifies every resolved path stays inside the memory directory. Path traversal is rejected at two layers. recall_write will not overwrite an existing memory unless overwrite: true is passed, so a durable memory is never clobbered by accident. See docs/THREAT_MODEL.md for the full model.

Develop and test

npm install
npm run build        # compile TypeScript to dist/
npm test             # unit + integration + end-to-end stdio tests
node scripts/smoke.mjs   # drive the built server with a real MCP client

Configuration:

Variable

Default

Purpose

RECALL_MEMORY_DIR

~/.recall/memories

Where memory files are stored

Credits

Built by Andrew Homeyer, co-developed with Claude (Anthropic's Claude Code).

License

MIT.

Available Tools

6 tools
recall_deleteDelete MemoryA
DestructiveIdempotent

Permanently delete a memory by name.

Args:

  • name: the kebab-case slug of the memory to delete

Returns whether a memory was deleted. Deleting a non-existent memory is a safe no-op (returns deleted: false). This action cannot be undone.

ParametersJSON Schema
NameRequiredDescriptionDefault
nameYesStable kebab-case slug identifying the memory (also its filename)

TDQS

A4.5/5.0
Behavior5/5

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

Adds context beyond annotations: confirms permanence, irreversible action, and safe no-op for non-existent memories. Annotations already indicate destructive and idempotent, but description reinforces and explains edge cases.

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?

Four succinct sentences, front-loaded with purpose, args and return clearly separated. Every sentence adds value with no redundancy.

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?

Description explains return value (boolean with 'deleted' key), covers edge case of non-existent memory, and notes irreversibility. No output schema, but description compensates fully.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline 3. Description provides 'kebab-case slug' which aligns with schema pattern, but adds no significant new meaning beyond the schema property description.

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?

Clearly states 'Permanently delete a memory by name', uses specific verb+resource, and distinguishes from sibling tools (get, list, search, write).

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?

Indicates that deletion is permanent and cannot be undone, and explains the no-op behavior for non-existent memories. Does not explicitly exclude alternative tools, 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.

recall_getGet MemoryA
Read-onlyIdempotent

Fetch a single memory by name, including its full body.

Args:

  • name: the kebab-case slug of the memory

  • response_format: 'markdown' (default) or 'json'

Returns the memory, or a not-found message if no memory has that name.

ParametersJSON Schema
NameRequiredDescriptionDefault
nameYesStable kebab-case slug identifying the memory (also its filename)
response_formatNo'markdown' for human-readable, 'json' for structured datamarkdown

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, ensuring the agent knows it's a safe, non-destructive operation. The description adds that it returns the memory or a not-found message, complementing the annotations without contradiction.

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?

The description is concise and front-loaded. Two clear sentences followed by an argument list with no redundant information. Every sentence adds value.

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 a simple read tool with no output schema, the description fully explains what it returns (memory or not-found), covers both parameters, and annotations provide behavioral safety. No gaps.

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 adds useful context: 'kebab-case slug' for name and explains response_format options ('markdown' default or 'json'), enhancing understanding beyond 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?

Description clearly states 'Fetch a single memory by name, including its full body.' It specifies the verb (fetch) and resource (memory by name), and the context of arguments and return distinguishes it from sibling tools like recall_list and recall_search.

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?

The description implies usage for fetching a specific memory by name. While it does not explicitly state when not to use or name alternatives, the sibling tools (delete, links, list, search, write) cover other operations, making the purpose sufficiently clear.

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

recall_listList MemoriesA
Read-onlyIdempotent

List stored memories (index view, no bodies), optionally filtered by type.

Args:

  • type: optional filter to a single memory type

  • limit: max results (default 20)

  • offset: number of results to skip, for pagination (default 0)

  • response_format: 'markdown' (default) or 'json'

Returns memory summaries plus pagination metadata.

ParametersJSON Schema
NameRequiredDescriptionDefault
typeNoOptional: restrict to a single memory type
limitNoMaximum number of results to return
offsetNoResults to skip for pagination
response_formatNo'markdown' for human-readable, 'json' for structured datamarkdown

TDQS

A4.5/5.0
Behavior4/5

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

Adds context beyond annotations: returns summaries (no bodies) plus pagination metadata, and lists parameters' effect. Annotations declare readOnly=true, idempotent=true, destructive=false, consistent.

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?

One-line purpose plus bulleted parameters, no fluff, front-loaded with key info.

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?

No output schema but describes returns; covers all 4 parameters with defaults and options; adequate for a non-destructive listing tool.

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 100% so baseline 3; description adds usage notes (defaults for limit/offset, response_format options) beyond schema descriptions.

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?

Clearly states 'List stored memories (index view, no bodies)' with verb and resource, and distinguishes from siblings like recall_get (full body) and recall_search.

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?

Implies usage for listing/filtering memories; could explicitly contrast with recall_get or recall_search but provides clear parameter guidance.

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

recall_writeWrite MemoryA

Create a new memory, or replace an existing one only when you explicitly allow it.

Persists one atomic fact as a Markdown file. This is safe by default: if a memory with the same name already exists, the write is refused and a conflict is returned, so a durable memory is never overwritten by accident. Pass overwrite: true to replace it on purpose. [[wikilink]] references in the body are detected automatically and exposed via recall_links.

Args:

  • name: kebab-case slug, also the filename (e.g. "renewal-window")

  • description: one-line summary; this is the primary signal recall ranks against

  • type: one of 'user', 'feedback', 'project', 'reference'

  • body: the fact itself, in Markdown; may reference other memories with [[name]]

  • overwrite: set true to replace an existing memory of the same name (default false)

Returns the stored memory and whether it was 'created' or 'updated', or a 'conflict' if a memory with that name already exists and overwrite is false.

ParametersJSON Schema
NameRequiredDescriptionDefault
bodyYesThe fact itself, in Markdown. May link other memories with [[name]]
nameYesStable kebab-case slug identifying the memory (also its filename)
typeYesClassification: 'user', 'feedback', 'project', or 'reference'
overwriteNoReplace an existing memory of the same name (default false)
descriptionYesOne-line summary used to decide relevance during recall

TDQS

A4.7/5.0
Behavior5/5

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

Discloses safety behavior: refuses overwrite by default, returns conflict. Requires explicit overwrite=true to replace. No contradiction with annotations (readOnlyHint=false, destructiveHint=false is appropriate).

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?

Concise and well-structured: one-line purpose, then detailed explanation, then bulleted args list. Every sentence adds necessary information without fluff.

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?

Covers parameters, return values (created/updated/conflict), and edge cases (overwrite behavior). Sufficient for an 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.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but description adds value: specifies kebab-case slug, recall ranking importance of description, wikilink detection, and default behavior for overwrite.

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 'Create a new memory, or replace an existing one' with a specific verb and resource. It distinguishes from sibling tools which are read/delete/list/search operations.

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?

The description explains when to use it (create vs replace) and the safety default (no overwrite). While it doesn't explicitly contrast with siblings, the context implies usage for writing only.

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. 6 tool updatesv0.1.0
    • First observedrecall_delete
    • First observedrecall_get
    • First observedrecall_links
    • First observedrecall_list
    • First observedrecall_search
    • First observedrecall_write
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.7/5.0
Disambiguation5/5

Each tool has a distinct purpose: delete, get, links, list, search, write. There is no overlap or ambiguity, and descriptions clearly differentiate between them.

Naming Consistency5/5

All tools follow a consistent 'recall_<verb>' pattern using lowercase with underscores, making naming predictable and easy to understand.

Tool Count5/5

With 6 tools, the server provides a well-scoped set for managing memories (CRUD plus search and linking), neither too many nor too few.

Completeness5/5

The tool set covers all essential operations: creating, reading, updating (via overwrite), deleting, listing, searching, and browsing links. No obvious gaps for its stated purpose.

Maintenance

ActivityInactive
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/andrewhomeyer/recall-mcp'

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