Skip to main content

Get your repository into memory

You installed @mnemosyne_os/mcp from a directory listing, and your agent now holds tools it cannot use yet. This page says what already works and what the application is there for. Then what to do so your code is in front of your agent tomorrow morning.

What answers with nothing else installed​

Three tools read the transcript files your coding-agent harness already writes to disk:

  • mnemosyne_agent_list names the sessions running on this machine, in which repository and on which branch, and marks the one you are talking to.
  • mnemosyne_agent_collisions says whether another agent is working in the same git working tree. The index is shared by every process in one tree, so a commit from one picks up whatever the other has staged.
  • mnemosyne_agent_files lists the files a session wrote, by tool call and by shell command.

No application, no vault, no token, no network call. Ask your agent what else is running in this repository and you get an answer on the first try.

Everything else refuses until the application is running. The refusal says which of the two problems you have: it was never installed here, or it is installed and closed. Those are two different next steps, so they are two different sentences.

Why there is an application at all​

A fair question when you came here for a server. Three things have to live somewhere, and none of them fits in a relay.

Something has to hold the content. Text becomes retrievable once it is split, embedded and indexed, and that index is a database on your disk. The MCP server keeps no state of its own: it opens one socket and passes messages. Were it to hold your repository instead, you would have a second copy of your code inside a process you cannot look into. No list of what went in. No way to take one thing back out.

Something has to retrieve well. A plain similarity search returns the passage that resembles the question, which is often not the passage that answers it. The engine behind the socket runs a lexical channel and a vector channel, and fuses their rankings. That takes a real index rather than a wrapper around an embedding call.

Someone has to decide. Which folders are watched. Which vault they land in. Which vaults an agent may read, and which must never be blended with the rest. Which model answers. Those are decisions about your own material, and a headless server would have to make them for you inside a file you edit blind.

So yes, a desktop application. What it buys you: every chronicle that entered is visible, and removable one by one. They sit on the same canvas as the cards showing what your agents are doing.

Getting your material in​

Your files: source, architecture notes, decision records​

You declare a folder, the application watches it, and what lands there is ingested into the vault you chose. Nothing is read that you did not name.

This is the step people miss. Installing the application gives you empty vaults, and declaring the folder is what fills them. See Getting started and DocWatch.

Your commits​

mnemosyne_git_log reads the repository at the moment you call it. Nothing is ingested and nothing is stored. The history your agent sees is never stale and never doubled.

What your agents wrote down​

Their notes, their project rules, their session files: Connect your coding agent's memory.

What goes where​

Route by route, because a single sentence about privacy would be false for one of them.

  • The vaults are files on your own disk, under your user account. They are read by the application and by whatever you point at it.
  • The MCP server opens one socket, 127.0.0.1:7799, and stores nothing. It is MIT licensed, so you can read exactly what it sends.
  • The answering model is the one you picked. A local model keeps the question on the machine. A cloud provider you configured with your own key receives the question and the passages retrieved for it. That is the same exchange as any other API call you make.

Where to go next​