How to give your AI coding assistant a searchable memory with MCP

AI coding assistants do not keep much in their head between sessions. Most have some built-in memory, a rules file or a project memory, but it is a small slice that loads every time and fills up fast. So when the assistant plans a feature it has not touched in weeks, the lesson you taught it back then is usually not in front of it, and it makes the same wrong call again.

The fix is a searchable knowledge base it can check on demand, connected over MCP, the Model Context Protocol. MCP is an open standard, so the same store works with whatever assistant you use. Instead of cramming everything into the always-loaded files, you keep your lessons in a store behind an MCP server, and when the assistant is planning or building, it searches that store and pulls back just the relevant notes.

I am a solo developer. I ship iOS apps and games on my own with an AI assistant in the loop all day. I happen to use Claude Code, so the concrete commands below are from there, but the store itself is not tied to it. The single biggest upgrade to that workflow was not a cleverer prompt. It was giving the assistant a big store it could search before it plans or builds.

What this actually is

It is a store of notes the assistant can search and add to on its own, exposed over MCP as a set of tools. Mine has three:

• save a note (a decision, a fix, a mistake to avoid)
• search the notes by meaning and get back the relevant ones
• list the most recent notes

Because MCP is a shared standard, any MCP-compatible assistant can use the same server. The important part is when it uses them. It does not load the whole store at the start of a session. Instead, when it is planning something or about to build, it searches the store for anything relevant and pulls back just those notes. When it learns a new lesson, it saves it. The knowledge lives on disk, so it is there the next time it matters, days or weeks later.

Why a searchable store beats the built-in memory

Most assistants ship some built-in memory, and it is genuinely useful, but it is bounded. Claude Code, for example, loads CLAUDE.md files in full on every session and keeps its own auto memory, but only the top slice loads up front, and a large always-loaded file both costs tokens and can reduce how well the model follows it. Whatever tool you use, the built-in memory is an always-loaded slice with a ceiling. (I broke that down in what your assistant keeps between sessions.)

A searchable knowledge base flips that around. The notes sit on disk costing nothing until they are needed. When the assistant is planning or building, only the handful that match get pulled in. You can store hundreds of lessons and it still only ever sees the five or ten that matter right now, right when it is about to act on them. It complements the built-in memory rather than fighting it for space.

The pieces

Here is what my setup is actually made of:

• An MCP server. Mine is a small Swift binary, registered with my assistant as an MCP server. In Claude Code that registration lives in ~/.claude.json; other clients have their own MCP config, but the server is the same.
• A folder of notes stored locally on the machine. Nothing leaves the laptop.
• Embeddings for search. Each note is turned into a vector (an embedding) so search can match by meaning, not just by keyword.
• The three tools: save_to_brain, search_brain, list_recent.

You do not have to write your own. There are good open-source memory MCP servers that store notes as plain markdown or as a knowledge graph. I built my own because I wanted it fully local and private, but the concepts below are the same either way.

How it works, step by step

Saving a note. The assistant calls save_to_brain with the text. The server embeds it and writes it to the local store. If no tags are passed, the server auto-generates three to five tags so the note is easier to find later. Before saving, it checks for near-duplicates using plain vector similarity, so it does not pile up ten copies of the same fact.

Searching. The assistant calls search_brain with a question. The server embeds the question, finds the closest matching notes (top ten in my setup), and returns them as a short, cited summary. The assistant gets back the actual relevant facts plus the source notes, not a wall of raw text.

That cited-summary step is the part I would not give up. It means the assistant gets genuine recall, the actual relevant facts, rather than me hoping the right thing was in the prompt.

How to set one up

At a high level:

1. Pick a memory MCP server (an existing open-source one, or roll your own).
2. Register it with your assistant as an MCP server. In Claude Code that is claude mcp add or editing ~/.claude.json; other clients have their own MCP settings.
3. Tell the assistant, in whatever rules or memory file it reads, to search its memory before it plans or builds anything substantial, and to save any new lesson worth keeping.

The full step-by-step how-to is a dedicated post coming next in this series. If you want to build the server itself rather than use one off the shelf, there is a separate build post coming too.

Copy this prompt to have your assistant build it

You do not have to write the server by hand. Paste the prompt below into your own AI coding assistant and it will scaffold a knowledge base like this one, then walk you through wiring it up. It is written to be tool-agnostic, so it works whether you use Claude Code, Cursor, or anything else that speaks MCP. The neat part is that the assistant you are giving the memory to is also the one that builds it.

You are going to help me give you a long-term memory: a small local knowledge
base you can search and save notes to over MCP (the Model Context Protocol).

Before writing any code, ask me which operating system I am on and which AI
coding assistant I use, then confirm the plan with me.

Build a local MCP server that exposes exactly three tools:
- save_note(text, tags?): store a note on disk. If I do not pass tags,
  generate three to five. Before saving, skip near-duplicates using vector
  similarity in code (no extra model call).
- search_notes(query): embed the query and return the most relevant notes by
  meaning, as a short summary plus the source notes it came from.
- list_recent(n): list my most recent notes.

Constraints:
- Store notes locally as plain files (markdown or JSON) in a folder I control.
  Nothing leaves my machine.
- Use a local or low-cost embedding model for the semantic search, and explain
  the trade-off you picked.
- Give me the exact commands to register this server with my assistant over MCP.
- Add backup: one command that exports every note into a single file I can copy
  into a cloud-synced folder, and one command to restore from that file.

Finally, write the rule I should add to your memory or rules file so that you
search this knowledge base before planning or building anything substantial,
and save new lessons (especially mistakes and decisions) at the end of a
session.

Adjust the details once it asks about your stack. If you would rather not build your own, the same prompt works if you tell it to wire up an existing open-source memory MCP server instead.

What to put in it

This is where the value lives, and it is worth its own post. The short version: do not curate. Store everything from your sessions and let the dedup and search filter it. Of all of it, the notes that pay off most are the things the assistant got wrong, the decisions you made and why, and the project facts that are not obvious from the code. Full breakdown in storing what the AI got wrong.

Back it up, because the notes are the valuable part

Give this store a few weeks and it becomes the most valuable thing on your machine, and the least replaceable. Your code is in git. These notes are not, unless you put them somewhere. Losing them means losing every lesson you have collected, and there is no re-downloading that.

My rule is simple. One command exports the whole store into a single file, and that file lives in a cloud-synced folder. I keep mine in a Google Drive folder, so every export is copied off the machine automatically, and a second command restores from that file onto a new machine or after a mistake.

Two habits make this safe instead of scary:

• Export before anything destructive. Before any operation that could wipe or rewrite the store, take a fresh export first. A backup you make after the accident is not a backup.
• Test the restore. A backup you have never restored from is a guess, not a safety net. Run the restore once, on purpose, so you know it actually works.

If you build your own server, add the export and restore commands on day one, not after you have lost something. If you use an off-the-shelf server that stores plain markdown files, point that folder at your cloud sync and you are already covered.

What I learned building it

One lesson stands out. My first version called an extra model to judge whether a new note was a duplicate of an existing one. It worked, but every save quietly spun that up, which was slow and noisy. I replaced it with plain vector similarity math done in code, no model involved. Saving notes went from "wait, why is something running" to instant.

The lesson generalizes: only reach for a model where you actually need judgment. For "are these two notes basically the same," simple vector math is faster, cheaper, and good enough. Use the expensive tool only where it earns its place.