Best MCP Memory Servers for Shared Team Agent Memory

An engineer wires up an MCP memory server on Monday. By Friday their agent recalls the retry policy, the reason the team dropped a queue library, and which service owns the outbox table. None of it reaches the engineer sitting next to them. The server worked exactly as built. The store it wrote to lives in a file on one laptop.

Memory servers get compared on what they extract and how they retrieve. For a team, the question that decides fit comes earlier: where the store lives, which people and agents can reach it, and what has to happen before one agent's write becomes the answer everyone gets. This roundup sorts the options by that question first.

The reference memory server writes to a file on one laptop

The reference implementations in the Model Context Protocol servers repository include one called Memory, described there as a "Knowledge graph-based persistent memory system." The Memory server is the obvious starting point, and it is where the sharing problem shows up first.

The Memory server runs over stdio. The client starts it with a command like npx -y @modelcontextprotocol/server-memory, and the MCP specification is explicit about what that means: "In the stdio transport, the client launches the MCP server as a subprocess." Storage follows from there. The server's README documents a single environment variable, MEMORY_FILE_PATH, as the "Path to the memory storage JSONL file (default: memory.jsonl in the server directory)."

So every developer who installs it gets their own process writing to their own file. A teammate can copy the identical configuration block and still retrieve nothing, because no service sits between the two machines. The repository is direct about the intent. Its servers "are intended as reference implementations to demonstrate MCP features and SDK usage" and "are meant to serve as educational examples for developers building their own MCP servers, not as production-ready solutions."

Five questions separate team memory from personal memory

Work through these for any server on your shortlist. The protocol answers none of them, because MCP standardizes how a client and server talk, not where the server runs or who owns its data.

• Where the store lives. A local file, a database you operate, or a hosted service. Only the last two can serve more than one machine without you building the sync.
• Whether the store is partitioned per user or per organization. Several people pointing at one endpoint is not the same as several people reading each other's memories.
• What triggers a write, and who sees it before it lands. An explicit tool call, or automatic extraction, and whether a person can reject the result.
• How memory is scoped. Boundaries by organization, team, project, or repository, so an agent in one codebase does not surface another team's decisions.
• What happens on contradiction. Last write wins, versioned history, supersession, or a review queue. The choice decides whether shared memory self-corrects or compounds an error.

The transport answer shapes several of the others. stdio is a subprocess on the developer's machine, and the specification's authorization rules follow that shape. Implementations "using an STDIO transport SHOULD NOT follow this specification, and instead retrieve credentials from the environment," while implementations "using an HTTP-based transport SHOULD conform," which for MCP means a subset of OAuth 2.1 with bearer tokens in the Authorization header. A remote HTTP endpoint makes shared memory possible without delivering it, because the service behind that endpoint still has to keep one team's records away from another's.

Where each of these servers keeps the store

Basic Memory keeps the store in files you can read

Basic Memory is MCP-native and stores knowledge as Markdown on disk, with notes living under a local directory by default. The appeal is inspectability. You can open the store in an editor, put it under version control, and see what your agent believes without querying anything.

The local install keeps notes on your disk, and the README lists cross-device sync for it as manual, through Git or Syncthing. Sharing comes from Basic Memory Teams, a hosted workspace where "anything a teammate writes is immediately available to everyone else and to their AI assistants." The sharing question resolves to which version you run rather than to the tool as a whole. Teams that pick the local version and share it through a synced folder are rebuilding conflict resolution by hand, in a directory of Markdown files.

Graphiti records when a fact stopped being true

Graphiti is a framework for temporal context graphs, and its repository ships an MCP server alongside the library. Its distinguishing property is time. "[E]ach fact in a context graph has a validity window: when it became true, and when (if ever) it was superseded." When information changes, Graphiti invalidates the old fact instead of deleting it.

Validity windows address the failure teams hit in practice. The damaging entry in a shared store is rarely a fabricated fact. More often it is a fact that was correct in March and is wrong for everybody now. A store that can express supersession gives you somewhere to put the correction and a way to ask what the graph believed at an earlier date.

The tradeoff is operational. Graphiti's MCP server runs against FalkorDB, its default, or Neo4j, and you choose, run, and upgrade that database yourself. Sharing it across a team means someone owns the database and its access rules. The MCP server separates data by a group_id namespace, set with --group-id and defaulting to main, so decide how teams map to group IDs before several clients point at one server. Teams that would rather not run the graph can look at Zep, whose managed context infrastructure has Graphiti at its core.

Cognee turns your own sources into a graph you host

Cognee converts documents, code, and conversations into a self-hosted knowledge graph, and it publishes an MCP server for connecting agents to the result. The usual arrangement combines a graph store, a vector store, and a relational database. Cognee can also run the whole memory layer on a single Postgres instance, though the README labels Postgres as a graph store a demo feature and offers the production-ready version as a licensed product. Cognee Cloud is the managed option for teams that would rather not run it.

Cognee fits when the knowledge you want agents to share is sitting in material you own. It publishes source connectors alongside the MCP server, Slack among them, so capture is not all hand-rolled. What stays yours is the assembly and the operations. You choose what gets ingested, configure the pipeline, and run the graph and vector stores underneath.

Supermemory organizes hosted memory into spaces

Supermemory runs a hosted MCP endpoint that signs in with OAuth and organizes memory into spaces. A space "keeps a team's documents, memories, and profile context focused," teammates work within the spaces they are allowed to read or write, and the MCP tools address each space by its container tag. The MCP server is open source. A self-hosted binary also exists, but Supermemory positions it for individual developers and lists its team access as "Single org on one machine." Multi-member organizations, roles, and scoped API keys come with Supermemory Enterprise.

Spaces give you a real boundary, and the isolation you end up with is still the isolation you design. The MCP server's guided-save flow helps on the write side, since the assistant can prefill a draft but "nothing is saved until you submit it." Before treating Supermemory as team memory, settle who creates spaces and grants access, which space each client writes to by default, and what stops a misconfigured client from saving into the wrong one.

Mem0 hosts the server so you never run one

Mem0 runs a hosted MCP endpoint at mcp.mem0.ai, and its documentation is blunt about the deployment shape. "Nothing runs on your machine: the server is hosted by Mem0, and your client connects to it over HTTPS." You authorize through a browser sign-in, or send an API key as a bearer token in headless environments. The tool surface is wider than most entries here, with eleven tools spanning adding, searching, updating, and deleting memories alongside entity and event management.

Scoping is the question to press. Tool parameters address a user, agent, app, or run entity, and Mem0 Platform groups memories into organizations and projects, resolved from your API key, with access limited to members. The MCP page does not say which project a browser sign-in lands in, so confirm that a teammate's client reads the same project as yours before treating Mem0 as shared team memory.

Dosu shares knowledge from the work the team is doing anyway

Dosu approaches team memory from the other direction. It starts from the tools a team works in every day rather than from agent writes alone, builds knowledge from those Sources, and serves it to coding agents over MCP. Agents can add notes of their own with write_knowledge, and those notes reach teammates too. The Sources you can connect today are GitHub, Slack, Notion, and Web, with Slack and Notion on the Teams plan. Web is read live at query time rather than stored.

The Dosu MCP Server is a hosted endpoint over HTTP, managed from the MCP servers page in the app, where each server is scoped to the Sources you select. OAuth is the recommended authentication where a client supports it, with an API key header as the fallback. Retrieval runs through read_knowledge and capture through write_knowledge, and the server also exposes tools for working through pending Review items and for checking the connection. Dosu documents Claude Code, Cursor, and VS Code Copilot among supported clients.

Sharing and isolation run through Libraries. Sources connect at the organization level and attach to one or more Libraries, each Library has its own members, and a server reaches only the Sources selected for it, so two teams can get different answers from the same connected repository set. What an agent saves with write_knowledge is an append-only note, and no one reviews it before teammates can read it. When the working repository is connected to the Library, the note is scoped to that repository and branch, and other members of the Library can read it back through read_knowledge with the author attached when they read on that branch. When the branch's pull request merges, the note becomes a candidate Topic for the Library. Without that connection the note is saved to the Library without the repository anchor and enters Topic promotion right away. Changes to published Documents take a different path. When a Monitor finds that a pull request may make a Document stale, it proposes an edit that waits in Review, where a person accepts, edits, or declines it unless the Library auto-accepts, and the edit carries citations back to the pull requests, files, and threads it came from.

Dosu's public documentation does not specify how two contradicting notes get reconciled, so ask about it if contradiction handling decides your choice. Dosu is also not a general-purpose memory API for people building their own agents. If that is what you need, the graph and vector options above fit better, and our comparison of agent memory APIs covers Mem0, Zep, Letta, and more.

An unreviewed write in a shared store is wrong for everyone

Write controls barely matter when memory is personal. A stale workaround in your own store wastes your afternoon. The same entry in a shared store becomes the answer every agent on the team retrieves, in generated code and in summaries that cite nothing.

So treat the write path as a first-class part of the comparison rather than a detail. Ask what triggers a write, whether the entry keeps a link to the evidence it came from, who can edit or remove it, and whether anything stands between the write and the next retrieval. Agent memory governance covers the controls in more depth than a roundup can.

Adding the server everywhere does not give everyone the same memory

Each client configures MCP servers its own way. Claude Code documents three scopes for a server you add, and the default is the narrowest one. Local scope is stored in your own config under that project's path and "stays private to you." Project scope writes a .mcp.json at the repository root that you check into version control, so "everyone on your team gets the same MCP tools and services." User scope, added with claude mcp add --scope user, makes the server available across all your projects but stays private to your account.

Committing .mcp.json distributes the server configuration, not the memory. Every developer gets a connection to the same endpoint, and whether they then see the same knowledge depends on the store behind it.

Cursor and Codex keep their own configuration formats and scope rules, so confirm each one against its current documentation rather than copying a block between them. Then write a distinctive fact from one developer's client and read it back from a different developer's client, in their own checkout of the same repository and branch.

Instruction files and a memory server are different layers

Instruction files such as CLAUDE.md and AGENTS.md can look like a memory layer, but they work differently enough from a memory server that one rarely substitutes for the other.

Instruction files are loaded into context at the start of a session. Claude Code documents a load order from broadest to most specific, running from managed policy through user-level ~/.claude/CLAUDE.md, to project files committed for the team, to a personal CLAUDE.local.md, and the docs are careful to say Claude "treats them as context, not enforced configuration." AGENTS.md is read when there is no CLAUDE.md in the working directory or above it, with configuration available for loading both. Everything in those files costs context on every session, and someone has to edit them by hand when the code moves.

An MCP memory server is retrieved from during the session, so the store can be far larger than anything you would paste into a prompt. Claude Code also has auto memory, notes Claude writes itself, and the docs describe it as machine-local. Each repository gets a directory under ~/.claude/projects/ on the developer's own machine, and the files are not shared across machines or cloud environments.

The two layers have different jobs. Instruction files hold the stable rules, the memory server holds the knowledge that changes, and a line in CLAUDE.md or AGENTS.md telling the agent when to query the server is what makes the second one get used. For the layers underneath this, see team memory for coding agents.

FAQ

Is the reference MCP memory server good enough for a team?

No, and its maintainers say as much. The servers in that repository are described as educational examples rather than production-ready solutions. The server writes to a JSONL file in its own directory on whichever machine launched it, with no remote endpoint, no authentication, and no organization scoping. Run it to learn the tool shape of MCP memory, not to share anything.

Can CLAUDE.md or AGENTS.md replace a memory server?

For stable, repository-specific rules, yes, and they are better at that job. They are committed, reviewable, and loaded every session. They do not update themselves, they consume context whether or not the session needs them, and they are a bad fit for knowledge that changes weekly or spans repositories.

Does self-hosting give a team shared memory?

Not by itself. A centrally hosted process can still keep a separate store per user, per project, or per client. Confirm that there is one backing store, that access rules are evaluated before retrieval, and that you can name which write wins when two agents disagree.

Can one memory server serve Claude Code, Cursor, and Codex?

A hosted server over HTTP can, because every MCP client speaks the same protocol to the same endpoint. What differs is configuration. Each client keeps its own config format, its own scope rules, and its own authentication support, so a working connection in one client proves nothing about the next. Add the server in each client separately and confirm each one lists its tools.

Run the two-laptop test

Pick a decision your team explained to an agent this month. Ask a teammate to open their own agent, in their own checkout, and ask the question that decision answers. If the answer comes back wrong or blank, the memory layer you have is personal.

If that is where you land, the gap is a store your whole organization reads from. Dosu captures engineering knowledge from the repositories, threads, and documents your team is working in, shares agent notes with Library members on the same branch, turns those notes into candidate Topics when the pull request merges, routes proposed Document updates through Review with citations attached, and serves the result to Claude Code, Cursor, and VS Code Copilot over its MCP server. Connect your first repo to Dosu and run the two-laptop test against it from two checkouts of the same branch.