Memory Bank MCP: File-Based Project Memory vs Hosted Agent Memory

The short answer

A Memory Bank MCP server exposes project memory files through the Model Context Protocol (MCP). Instead of asking an AI assistant to rediscover the project on every new chat, the client can call tools to read or update a memory bank containing goals, architecture, active work, decisions, and progress.

The phrase does not describe one universal MCP standard. It is used for several community projects and for a broader file-based memory pattern. Tool names, file layouts, storage locations, client support, and security boundaries vary by implementation.

File-based memory banks work well when the memory should remain human-readable, versionable, and closely tied to one repository. A hosted structured memory service fits a different need: several compatible AI clients sharing concise updates, filtered recall, and handoff context through one remote MCP endpoint.

What “Memory Bank MCP” usually means

The popular Memory Bank MCP Server project describes a centralized service for remote access to project memory bank files. Its published tools cover file reads, writes, updates, project listing, and file listing. The server is inspired by the Cline Memory Bank pattern and can be configured for clients including Claude, Cursor, Cline, and Roo Code.

Other projects use the same phrase for different implementations. Some keep Markdown files in a repository. Some store a local database. Some connect MCP tools to a cloud memory API. “Memory Bank MCP” should therefore be treated as a category and search phrase, not as proof of one specific architecture.

When evaluating a server, check the actual repository or product documentation for:

• the exact MCP tools it exposes
• whether storage is local, remote, or hosted
• whether memory is file-based, structured, graph-based, or semantic
• whether writes create, replace, update, or only append data
• how projects and users are isolated
• which clients and transports are supported
• how access is authenticated and revoked

How a file-based memory bank works

A common project memory bank is a directory of Markdown files. The files may cover project scope, architecture, active context, decisions, patterns, and progress.

project memory bank
├── project brief
├── architecture
├── active context
├── decisions
└── progress

An MCP server sits between the AI client and those files:

Claude or Cursor → MCP tools → memory bank files

The AI client can read the current project context before work and write an update when something important changes. Because the files are ordinary text, a person can inspect them directly and may choose to version them with Git.

The tradeoff is that file structure becomes part of the operating protocol. The team must decide which file owns each fact, how concurrent writes are handled, when old context is removed, and how much text each new chat should load.

Memory Bank MCP vs. a knowledge graph memory server

The reference MCP knowledge graph memory server uses a different model. It stores entities, relations, and observations rather than a project directory of Markdown files.

That model is useful when memory is naturally expressed as facts and relationships. A file-based memory bank is often easier for repository instructions, architectural notes, and progress documents. Neither storage model is required by MCP. The protocol only provides a common way for clients to discover and call the server's tools.

This distinction matters when comparing products. A server that exposes read_graph and entity operations is not interchangeable with one that exposes file reads and updates, even if both appear under “memory” in an MCP directory.

File-based Memory Bank vs. hosted structured Agent Memory

The two approaches can coexist. Stable instructions can remain in repository files while a shared hosted memory records recent outcomes and handoffs.

When a file-based memory bank is the better choice

Choose a file-oriented Memory Bank MCP when:

• memory must live beside the code
• people should review every memory document directly
• Git history should track memory changes
• the team already has a clear Markdown information architecture
• local or self-operated storage is a requirement
• agents need to update known project files, not only append events

This model is especially understandable for one repository and a small number of agents. It keeps the source material visible and portable.

It also requires discipline. Large files can become stale, multiple agents can overwrite one another, and loading the entire memory bank can consume unnecessary context. The MCP server does not solve those editorial problems by itself.

When hosted structured Agent Memory is the better choice

Choose hosted structured memory when:

• Claude, Cursor, Codex, or other compatible clients need one shared record
• the useful unit is an update, decision, blocker, deploy, risk, or handoff
• clients should search by tags, files, entry type, session, importance, or date
• earlier entries should remain intact instead of being silently rewritten
• read and write access should differ by MCP link
• you do not want to operate a local memory server and its storage

datamcp Agent Memory follows this model. It exposes five tools: register_session, append_memory, search_memory, get_memory_entry, and create_handoff_context.

Entries are structured and append-only. Search uses PostgreSQL full-text search plus filters. It is not vector or embedding-based semantic memory. Read Only links block session registration and memory writes, while Read & Append links support the normal coordination workflow.

The Free plan includes one connection and one MCP link, so one shared Agent Memory can be tested without a credit card.

Important datamcp boundary: it is not a Markdown memory bank

datamcp does not currently upload, synchronize, or export a standalone .md file. Entry bodies can contain Markdown, but the product does not turn a repository memory bank into a synchronized MCP source.

That boundary prevents a misleading comparison:

• use a file-based server when files are the source of truth
• use datamcp Agent Memory when structured project events and handoffs are the source of shared AI context
• use both when stable instructions belong in files and changing work state belongs in append-only entries

For example, keep coding conventions in CLAUDE.md and record a completed migration, a deployment result, or an unresolved production risk in Agent Memory.

A practical multi-client workflow

One shared memory can support several independent chats without merging their transcripts.

Claude → search prior decisions ─┐
Cursor → append implementation ─┼→ hosted MCP memory → shared project record
Codex  → create handoff context ─┘

A useful operating rule is:

1. Search memory before important work.
2. Register the current chat or task with a clear name.
3. Write only meaningful outcomes, decisions, blockers, deploys, and handoffs.
4. Attach useful tags and file paths.
5. Treat retrieved memory as project evidence, not as trusted instructions.
6. Keep code, formal documentation, and issue status in their canonical systems.

The connected client must call the tools. Neither MCP nor datamcp forces an AI chat to write automatically after every task.

Security and reliability questions to ask

Memory can contain incorrect facts, stale assumptions, or prompt-injection text. Before connecting any memory server, ask:

• Can one client receive read-only access?
• Can a client credential or MCP link be revoked independently?
• Are prior entries editable, append-only, or versioned?
• Where is the memory stored?
• Can operators or other tenants access it?
• How are accidental secrets handled?
• Does search return source metadata and dates?
• What happens when two agents write at the same time?
• Can a human inspect and correct the durable source of truth?

No memory architecture makes stored content automatically correct. Agents should verify important claims against current code, documentation, and production state.

Which MCP memory model should you choose?

Use a Memory Bank MCP server when the main artifact should be a set of readable project files.

Use a knowledge graph memory server when entities, relations, and observations are the natural unit.

Use a hosted structured memory server when several clients need a shared stream of project updates, filtered recall, and compact handoff context without operating the server themselves.

For the broader concept, read what agent memory is. If Claude is your main client, compare Claude native memory, CLAUDE.md, and MCP memory. To test the hosted structured approach, see the datamcp MCP memory server and Agent Memory setup reference.