Memory Bank MCP: Build Persistent Agent Memory You Can Audit

A Memory Bank MCP setup gives an AI agent durable knowledge outside its context window. The useful version is not merely “save every chat.” It is a small, governed knowledge system: the agent can retrieve the right project facts, update them deliberately, and leave a trail a human can inspect.

For engineering knowledge, your agent’s memory should be files you can read, edit, diff, and self-host—not only embeddings hidden behind an API. Meshnote exposes a markdown wiki through Model Context Protocol (MCP), so Claude Code, Cursor, and other compatible clients can work with the same memory.

What “memory bank” means in MCP

A traditional coding-agent memory bank is a directory of markdown files such as product-context.md, active-context.md, progress.md, and decision-log.md. An MCP server places a standard tool boundary in front of those files. The client discovers tools, sends structured calls, and receives results without needing custom filesystem logic.

This differs from a generic memory endpoint. A memory bank usually stores curated project state; a conversational memory layer often extracts facts automatically from messages. The former is strong for decisions and runbooks. The latter is strong for preferences and high-volume personalization. If you need the protocol background first, read the practical MCP memory server guide.

The category is already crowded: MCPServers.org listed 157 memory servers when researched on August 6, 2026. One concrete project, Movibe’s Memory Bank MCP, exposes 15 tools and uses five development modes. Quantity does not tell you which system is safe to trust. Storage semantics and recovery behavior do.

A maintainable memory-bank architecture

Claude Code / Cursor / another MCP client
                 |
          MCP tools + auth
                 |
     project selection and schema
                 |
  markdown pages + sources + page history
                 |
      backup / Git / human review

Keep three concerns separate. Transport determines how clients connect: local servers commonly use stdio; shared services use Streamable HTTP. Retrieval determines what enters context: exact page reads, full-text search, vectors, or graph traversal. durability determines whether you can inspect, correct, export, and restore the canonical knowledge.

MCP standardizes the client-to-server interface; it does not guarantee good memory. A server can still overwrite the wrong scope, return stale facts, or lose provenance. Treat the server as an application with a data model, not as a magic extension of the model.

Working setup: Claude Code with a shared markdown bank

The following uses Meshnote’s hosted Streamable HTTP endpoint. Create a project and an API key in your account, install Claude Code, and run this in Bash or zsh. Keep the key out of shell history and repositories; an environment variable is shown so the command itself remains reusable.

export MESHNOTE_API_KEY='mnk_replace_with_your_key'

claude mcp add --transport http meshnote https://meshnote.io/mcp \
  --scope user \
  --header "Authorization: Bearer $MESHNOTE_API_KEY"

claude mcp list

claude mcp list should report the server as connected. The command follows Anthropic’s documented HTTP and bearer-header syntax. In Claude Code, ask the agent to call list_projects, then get_schema for the chosen project before writing. That schema is the memory contract: it tells the agent how the wiki is organized instead of inviting it to invent a new layout every session.

Use this initial instruction:

Use the Meshnote project "payments-platform" as durable memory.
Read its schema and index first. Before implementation, search for
relevant decisions and runbooks. Write only stable facts that will
help a later session. Put temporary task state in the log, not in a
canonical page. Include the source or evidence for consequential facts.

If you prefer a local, single-repository bank, Movibe’s documented stdio command is npx @movibe/memory-bank-mcp --path /absolute/path/to/project. That is simpler and keeps files beside the project. A remote bank is better when multiple machines or agents need one controlled copy. For another end-to-end client example, see Claude memory over MCP.

The six-case acceptance test most setup pages omit

Do not declare success because a tool appears in a menu. Run this test with disposable facts. It tests operational memory rather than a demo-quality recall:

Persistence: write “staging uses port 4318 for OTLP/HTTP,” end the session, start a new one, and retrieve it without repeating the fact.
Scope isolation: create the same page name in two projects with different values. A query in project A must never return project B’s value.
Conflict: replace the port with 4317 and label the old value superseded. Search must surface the current fact, not confidently merge both.
Provenance: attach the runbook, issue, or source URL. A reviewer must be able to answer “why does the agent believe this?”
Deletion: remove a seeded secret-like string, then search exact text. A tombstone that remains retrievable is not deletion.
Recovery: overwrite a page incorrectly, list its history, restore the prior version, and verify the restored body.

This checklist is the original gap in the ranking setup pages: those pages catalog servers, tools, modes, and installation, but do not show how to test conflicts, tenant boundaries, provenance, deletion, and restore as one release gate.

Memory Bank MCP versus other memory approaches

Approach	Best at	Real trade-off
Markdown memory bank / Meshnote	Decisions, runbooks, shared project knowledge, review	Readable and portable; requires curation and is less automatic than fact extraction
Mem0	Extracting compact user or agent memories and semantic retrieval	Good personalization layer; canonical wording and file-style review are not its primary model
Zep / Graphiti	Temporal relationships and facts that change over time	Powerful graph queries; more operational and modeling complexity
Letta	Stateful agents with memory blocks and archival memory	Memory is deeply integrated with the agent runtime; that coupling may be useful or limiting
Native ChatGPT or Claude memory	Low-effort personal continuity	Convenient, but less portable and less suitable as a team-owned project record

Benchmarks such as LoCoMo and LongMemEval are useful for testing long-conversation retrieval, and 2025–2026 vendor reports have made them prominent. They do not measure whether an engineer can review a diff, trace a decision to evidence, or recover yesterday’s page. Evaluate both recall quality and operational control. The Mem0 versus Zep comparison includes a deeper architecture decision framework.

Rules that keep memory useful

Store conclusions, constraints, and evidence—not raw transcripts by default.
Separate temporary activity logs from canonical pages.
Prefer one owner page per concept; link instead of duplicating facts.
Record dates for facts that can expire and mark superseded decisions explicitly.
Require project scope on every tool call and test cross-project isolation.
Back up the source files and exercise restore before production.

A Memory Bank MCP server succeeds when a new agent can resume work without forcing humans to surrender control of the record. If readable files, shared access, and agent-agnostic MCP are your priorities, start syncing — $8/mo. Teams that want to own the deployment can choose self-hosted for teams from $10/seat/month.

For a broader market view, the best MCP servers for memory shortlist compares this file-oriented pattern with Mem0, Graphiti, and the reference knowledge-graph server.