MCP Memory Server: A Memory a Person Can Correct

What does an agent know tomorrow, and where does it keep it?

What will the next agent know about the decision made this afternoon? Where is that written down? And if it is wrong, who gets to fix it?

Those three questions show up as soon as a second agent starts on a project the first one already touched. The first agent spent an hour finding out that a database migration has to run before the tests. It wrote nothing down. The second agent spends its own hour finding out the same thing. The third does it again.

An MCP memory server is the usual answer, and the usual picture is a store with a clever search on top. AuricIDE takes a plainer route. Its memory is a folder of markdown notes inside the project, and an agent reaches that folder through four MCP tools. The claim of this article is that a plain folder gives a team something a hidden store cannot: a memory a person can open and correct.

Is memory just a database with a smart search?

The obvious answer is yes. Memory means storing facts and finding them again by meaning, so the store gets an index and a ranking.

That answer solves retrieval and skips the harder problem. A note an agent wrote late in a long session may be wrong, half finished or out of date by the next morning. In a store nobody can read, the mistake stays invisible until another agent trusts it and builds on it. The useful property of project memory is not how well it finds things. It is whether a person can see what is in there and change it.

A markdown file passes that test with no extra tooling.

Open it. Fix one line. Save. Delete the file and the memory is gone. It is that direct.

What does the agent actually call?

Four tools do the work, and none of them is complicated. The server behind them is the same one that gives agents access to tickets and goals, and building such a server is a separate job from using the notes.

search_notes takes a piece of text and looks for it, ignoring case, in every markdown file in the project. It returns the file, the line number and the matching line, up to 100 hits. read_note opens one note by its project-relative path and is limited to the project folder. write_finding saves what an agent learned as a new note under findings/. get_backlinks lists every note that links to a given note name.

A finding carries its origin. The note starts with a title. Next comes a comment block with the date, the agent that wrote it and the goal it belonged to. Then the text follows, and at the end sits a short list of related notes as [[wiki links]]. Those links are what make the folder something an agent can walk through. An agent that finds one note on migrations can ask which other notes point at it and follow the topic instead of guessing the next search word.

A short finding might read like this. The title says "Run the migration before the tests". The comment block names the agent and the goal. The text explains that the test database is empty until the migration has run, and the related list points to the note on test setup. Anyone on the team can read that in ten seconds and tell whether it is still true.

Writing does not replace an existing note. If two agents pick the same title, the second note gets a number in its file name.

How does a note get from one agent to the next?

Take the migration again. The first agent finishes its work and saves a finding called "Run the migration before the tests". It links the note to the one about test setup and records the goal it worked on. The next morning a second agent starts on the same goal. Its prompt tells it to look through the notes first, so it searches for "migration", gets a hit, reads the note and sees the date and the author at the top. One link takes it back to the test setup note. It starts coding without repeating the investigation.

A second, shorter-lived kind of memory sits on the ticket. A ticket can carry context items, either a text snippet or a reference to a file. When an agent picks up that ticket, the snippets go into its prompt as written, and each referenced file is read and included. Notes hold what the whole project has learned. Context items hold what this one ticket needs.

What does this design cost?

Search is a plain text match. A note that says "database upgrade" does not turn up for a query on "migration", because the search knows nothing about synonyms. The agent has to try a second word. That is all. Results stop at 100 hits, so a query for a common word returns a sample and not everything.

A finding is only as good as what the agent chose to write down. Nothing records a decision by itself. That is the catch. A small one. An agent has to call the tool, and a note that was never written cannot be found. Nothing forces an agent to search first either; that comes from the prompt or the skill that starts it.

Where the notes sit is a decision as well. The project database lives in a hidden folder that git ignores, so the work record stays on the machine. The notes are different. They sit in the project like any other markdown, which means findings/ can be committed and read in a diff, shared with a teammate, or added to the ignore file. A clone only brings the notes that were committed. AuricIDE leaves that choice to the team.

The trade is clear enough. AuricIDE picked a weak search that anyone can understand over a smart search that nobody can inspect.

Some notes will be missed on the first query. The design accepts that.

What holds up in any tool?

Whatever tool stores an agent's memory, one question decides whether it can be trusted: who can correct it? A memory that only the agent can read is a record of what the agent believed, and nobody else on the team has a way to check that belief against the project. A memory a person can open is a record the team can fix.

The first kind goes wrong slowly. Nobody notices. The first sign is an agent acting with full confidence on a fact that stopped being true last week.