Keep Your AI on Track Through Weeks of Prep

Prep can run for weeks, and keeping it in one AI conversation gets expensive fast. So I built prep-mcp, a small MCP server in Go that lets Claude read and safely write a folder of markdown notes. Any conversation can end, and the next one picks up where it left off.

This post covers why I built it, what it is, how a conversation uses it, and what two and a half weeks of daily use showed.

Since May I've been preparing for senior backend interviews: DSA and LeetCode, system design, DDIA, AI systems, plus my resume and LinkedIn profile. Claude has been my study partner every day, and every related conversation lived in one Claude project. After five months, three problems kept coming back:

So I had an idea: move the memory out of Claude, into notes I own, and give Claude an MCP server to read and write them. Then I decide what each conversation stores and what the next one reads. Memory becomes something I can read, diff and revert, instead of something I can't see into.

The hard part is the write side: an AI writing to files I also edit by hand, without either of us losing work. That is where most of the design went.

prep-mcp is a Go binary that Claude Desktop and Claude Code start over stdio. It gives the assistant 11 tools over one folder of markdown notes, the vault. I edit the same vault in Obsidian, and every AI write lands as a git commit.

The server knows nothing about interviews. Two files at the vault root give it its shape:

My vault is set up for job interviews. It has seven types: applications, prep sessions, improvements (one weakness each, with an exit criterion), stories, references, learning notes and weekly plans. My CLAUDE.md, about 7 KB, says how to run and score each kind of drill and how to log it. Change those two files and the same server tracks an exam, a certification or a language. The README's "Shape it to your vault" shows both files from the example vault.

One conversation, as the assistant runs it:

Start. get_context replaces the handover prompt I used to paste. One call returns what the config's context block names: the working rules, this week's plan and log, every open item with its next action, the last few prep sessions and the tags used most in the last 30 days.

Work. The other four read tools answer questions as they come up. list_docs does most of it: tags (AND, OR, prefix), frontmatter conditions and dates combine in one call, and group_by returns counts instead of documents. "Which applications are waiting on me?" and "which weaknesses came up most this month?" are the same tool with different arguments. list_tags shows what keeps coming back and what has gone quiet. search_text finds a phrase anywhere. read_doc returns a file with its content hash, which a later full rewrite must quote.

Log. Each write tool changes only what it names: create a file, append under a heading, patch frontmatter, replace one exact piece of text, or rewrite a whole file. A conversation usually ends with one batch: its prep session note plus a line in the week's log, as one commit.

No database, no index. Every call scans the folder: about 58 ms for 2,000 generated documents, and about 5 ms at my vault's size (an estimate from the per-document rate). A stored index would be a second copy to keep in sync with files I also edit by hand.

My morning conversation starts with get_context, and Claude says in one line what today's plan calls for. We work through it, whether that's a drill, a design problem or a chapter of reading. At the end, Claude logs a prep session tagged with the weaknesses it saw, plus one line in the week's log. On Friday, one list_docs call counts which weaknesses came up most that week, and that shapes next week's plan. Applications live in the same vault, each with its next action and date, so following up is a question, not a memory test.

Letting the AI write is the hard part. A server that writes can overwrite my edits, break a file's frontmatter, or follow instructions hidden in a document. Each decision below has a cost.

I used prep-mcp from Claude Desktop and built it with Claude Code, so the AI was both my user and my developer. Friction in a Desktop conversation became a ticket, and a Claude Code conversation fixed it. Most changes follow the same loop:

Open limits and ideas are tracked in the repo's issues. Three examples:

The repo is public at github.com/Arkoes07/prep-mcp. The README covers install for Claude Code and Claude Desktop, and a fictional example vault to try it on.