MCP memory server vs plain markdown files for agent memory

A memory server built on the Model Context Protocol (MCP) and a folder of plain markdown files answer the same question in two different places. The server holds your agent’s memory inside a process with its own store and its own query interface. Plain files hold it in a folder you can open, search, edit, and back up with tools you already have. For one developer working across a few agents, plain files are the safer default, because the memory outlives whatever wrote it.

The verdict flips when you need retrieval you would not build yourself. That means graph traversal across entities and their relationships, ranked recall over tens of thousands of items, or one store that several agents reach over a network rather than a disk. If none of that describes your setup, the server is an extra moving part between your agent and text it could have read directly.

What an MCP memory server actually does

MCP is an open standard for connecting AI agents to outside tools and data. A memory server is one of those connections: your agent calls tools the server exposes rather than touching files, and the server decides how the information is stored.

The official reference implementation, published as @modelcontextprotocol/server-memory, keeps a knowledge graph. Entities are the nodes, relations are the directed links between them, and observations are the facts attached to each entity. It persists that graph to a local newline-delimited JSON file, one entity or relation per line. Other implementations keep a similar remember-and-recall interface and swap the storage for a vector database or a graph database.

What plain markdown files do instead

In the plain-file approach, one memory is one file. A decision, a fact, or an open follow-up gets a note with a title, a few lines of body, and fields at the top for kind, project, date, and status. Recall is a search across those files.

The agent writes a note and you read exactly what it wrote, in the editor you already use. When the agent has remembered something wrong, you fix it by editing a sentence and saving.

The comparison in one table

Question	MCP memory server	Plain markdown files
Where the memory lives	The server’s own store, often a JSON file or a database	Ordinary .md files in a folder
Reading it without the agent	Depends on the format, and often needs a viewer or a script	Any text editor
Retrieval quality	Built in: graph queries, ranked search, vector search	Whatever your search tools provide
Setup cost	Install the server, configure it per agent, keep it reachable	Point your tools at a folder
Diffs and history	The reference server’s line-delimited store diffs cleanly, but in machine-shaped JSON. Database-backed servers give no diff at all	git diff shows the prose change line by line
Moving between machines	Host it centrally or copy its store	Any file sync moves it
If the project is abandoned	A migration job	The notes are still notes
Several agents at once	One store behind one interface	One folder, so writes need care

Where the memory server is the better tool

Relationship queries are the clearest case. If what you are storing is a graph of people, services, and dependencies, a knowledge graph server answers how two things connect in a way that searching a folder does not.

Network reach is the second case, because files assume a filesystem. When your agents run in containers, in continuous integration, or on machines you do not control, a hosted memory server is reachable where a local folder is not.

Consistency across clients is the third. The server ranks and filters once, and every MCP-capable agent inherits that behavior. The related question of embeddings versus text is covered in vector database vs markdown agent memory.

Where plain files win

You can read them. Checking what an agent believes about your project means opening a folder, not exporting a store, which is the basis of auditing what your AI agent remembers.

You can correct them. Wrong memory is the expensive failure, because an agent will recall a superseded decision with total confidence. Editing one sentence fixes it.

You can version them and move them. Running git log over a memory folder tells you when a belief entered the record. When you switch agents, or the server you picked stops being maintained, nothing needs migrating.

How each side fails

Most memory servers, the official one included, communicate over standard input and output, and the client launches them on demand. A configuration the client never loaded, or a server that dies on startup, then looks identical to an empty memory. Nothing reports it, and the agent behaves as though the project has no history.

Plain files fail in two ways of their own. Two agents writing one file at the same moment can clobber each other, and search over a large folder is only as good as your search tool. Both are fixable, and both are yours to fix.

Doing this with plain files and a command line tool

Jotura sits on the plain-file side. It is a local-first markdown notes app, so your notes are ordinary .md files in an ordinary folder. It ships a first-party command line tool called jotura, not an MCP server. Agents call it the way they call git, so anything that can run a shell command can drive it.

Three commands write and recall memory as notes in your vault:

jotura memory log --kind decision \
  --title "Use Postgres for the sync queue" \
  --project "sync-service" \
  --body "SQLite could not take concurrent writers from three workers."

jotura memory recall "sync queue database"

jotura context "add retry backoff to the sync queue"

A memory is a decision, a fact, or a followup. Recall ranks by relevance, freshness, and importance. The context command returns the memories relevant to a task, plus your open follow-ups and a flag when your agent config has drifted.

The memory log command prints the path it wrote, so an agent never guesses. The example above lands at Memory/Decisions/2026-08-30 use-postgres-for-the-sync-queue.md, dated the day you ran it.

The tool checks a hash before every write, which is how several agents share one folder:

jotura read "Memory/Decisions/2026-08-30 use-postgres-for-the-sync-queue.md" --json
jotura edit "Memory/Decisions/2026-08-30 use-postgres-for-the-sync-queue.md" \
  --replace "Postgres" --with "Neon Postgres" --if-hash <hash-from-read>

The read returns the file’s current hash. If the file changed in between, the edit exits with code 2 rather than clobbering it. A --replace must match exactly once or the command refuses, and body edits never touch the fields at the top of the file. Quote the path, because the filename contains a space.

Agent instructions live in an Agents/ folder in the same vault, and jotura agents sync applies them to each tool’s expected location. The command reference covers that. One line installs the app, the tool, and the agent skills:

curl -fsSL jotura.io/install.sh | bash

On Windows, run irm jotura.io/install.ps1 | iex instead.

Three limits matter. Jotura is closed source, though what it writes is ordinary markdown in a folder you own, so the durability argument survives. If you need the tool itself to be auditable, this is not that tool.

Semantic search runs on your machine after you enable it in desktop Settings, which downloads a local embedding model once. The desktop app builds that index, so the command line tool only queries it. And there is no MCP server here, so a workflow built on MCP tooling will not drop this in.

You do not have to choose one forever

These approaches are not exclusive. Nothing in the protocol requires a server’s store to be opaque, and one backed by a folder of markdown files gives you ranked retrieval over notes you can still open. Check whether the server you are considering works that way before you assume you must pick a side.

The rule worth holding is about the source of truth, not the protocol. Whatever your agents remember should sit somewhere you can read, correct, and carry away. A folder of files clears that bar by default. A memory server clears it when its store is legible and exportable.

Common questions

Is a memory server faster than searching files? Ranking quality is the real difference, not milliseconds. Full text search over a folder stays quick at solo-project scale: Jotura’s keyword search covers 10,000 notes in about 8 milliseconds in release builds.

Can Claude Code, Codex, and Gemini share one plain-file memory? Yes. They read the same folder while keeping their own instruction files, which is the setup described in shared memory across AI coding agents.

Does Jotura provide an MCP server? No. It provides a command line tool, and agents invoke it as a shell command.