I ended the last post on a problem. A folder you own can still be a folder you can’t search. The vault solved what to keep and where it lives. It did nothing for finding.
By the time it held a year of thinking, finding had become its own job. Hundreds of notes, build logs, decisions, half the context of everything I’d made, all of it in there, all of it mine, and locating one specific thing meant remembering what I’d called a file eight months ago. Which I never did. I remember what something was about. I almost never remember what I named it.
This is the part of memory nobody builds. Everyone builds the store. The shelves, the folders, the database. Storing is the easy half and it gets all the attention. The hard half is retrieval. A library with no way to find a book is just a warehouse.
So I built a librarian.
I called her Mrs Elmes. If you know where the name of this whole place comes from, you’ll know why. In the novel the blog is named for, Mrs Elm is the librarian, the one who meets you between the shelves and helps you find the right book. Naming the thing that finds things in my library after that library’s librarian wasn’t subtle. It wasn’t meant to be.
She was the first real piece of MCP work I designed. And my first instinct was to make her clever. An agent. Something with opinions, that could read a query, decide what I probably meant, and surface what it reckoned I’d want.
That instinct was wrong, and working out why it was wrong taught me more than the build did.
You don’t want a librarian with opinions about what you should read. You want one who brings you exactly what you asked for and nothing else. No interpretation. No helpful guessing. No drift between what you requested and what arrives. For a system holding your own thinking, accuracy isn’t a feature, it’s the whole point, and the moment it starts deciding things for you it stops being memory and becomes noise with a confident voice. I’d already met that voice. I wrote a whole post about her.
So Mrs Elmes is not an agent. She’s an MCP server. A deliberately simple tool that does a few things precisely instead of many things approximately. The dumber design was the smarter one.
She searches by what a thing was about, not what it was called, because that’s how I actually remember. She reads a file back in full when I name it. And she writes, except she can’t, quite. When something needs to go into the vault she proposes it, shows me exactly what will change, and waits. Nothing is written until I say the word. The capability lives in the tool. The permission lives with me. That gate isn’t an inconvenience bolted on top. It’s the same principle the whole memory runs on, the one from two posts back. The vault stays trustworthy because nothing enters it without a decision.
She hasn’t stood still. She started as barely more than a connector and has changed almost every month since. Even this weekend she changed again. The write became a two-step handshake, propose then confirm, each one carrying an ID so there’s no ambiguity about what’s being agreed to. She learned to list as well as search. I know this because I’ve spent tonight using the new version, watching her propose, confirming each one by hand. The posts you’ve just read went into the vault through exactly that gate.
Mrs Elmes — the shape of the tool
An MCP server running on the management VM, sitting over the vault at its synced path, speaking to Claude Desktop over the MCP connection. No agent, no reasoning layer. It returns what it’s asked for.
Search runs on a SQLite FTS5 full-text index built across every Markdown file in the vault. Results come back ranked by BM25 relevance, and the query takes the full FTS5 grammar, quoted phrases, prefix wildcards, AND/OR/NOT. That grammar has teeth. A stray apostrophe or an unescaped hyphen throws a syntax error rather than guessing what you meant, which is exactly the behaviour you want from a librarian and the behaviour I relearned a couple of times tonight.
List is deliberately not search. It walks the live filesystem under a given path instead of reading the index, so a file written ten seconds ago shows up immediately, before FTS5 has reindexed. Search is for “I remember roughly what this was about.” List is for “show me what’s in this folder right now.”
Read returns a file’s full content by path. There’s a hard ceiling on response size, so very large notes have to be queried rather than dumped whole. Its own quiet argument for keeping notes focused.
Write and confirm are the gate, split in two. A write call doesn’t write. It reads the current file first, shows the full proposed change, and returns an eight-character ID. Nothing lands until a separate confirm is made against that exact ID, and the proposal expires if it’s left sitting. The vault format standard is enforced on the way in. The capability is the server’s. The decision is always mine.
Protected paths sit behind an extra gate, sudo-style. The vault holds more than build notes, and not all of it belongs in every session. Those paths need explicit authorisation before she’ll search or read them. The capability is always there. The access is granted in the moment, or not at all.
That’s the set. Keep only what’s worth keeping. Put it somewhere that’s yours. And build the thing that can find it again. Miss any one of the three and you don’t have a memory. You have a pile, a hostage, or a warehouse.
The store was never the hard part. The librarian was.
Buddy, any thoughts?
Meanwhile, Buddy runs his own retrieval service. Ask him where the ball is and he produces it instantly, every time, including the three you thought were lost. His filing system is a mystery. His recall is perfect.