MCP memory for teams: one server your agents share

Friday the on-call engineer is in Claude. The team will retry a failed webhook three times, then stop. They will not add a queue. The engineer tells a local memory server to store that fact. The server writes a file on that laptop.

Monday a teammate opens Cursor. That host starts its own memory server. The file is a different file. The agent drafts the queue. The rejection never left the first machine. ChatGPT, opened for the customer note, has neither file.

Each client did what a local MCP memory server does. The team still has no shared store.

People search for MCP memory and land on that shape. A server one person runs, on one computer. It is a real tool. The boundary fails when a second person, or a second host, has to continue the work.

What MCP memory is

MCP memory is an MCP server whose tools read and write a memory store. The client is the agent host. The server is the store. The model calls a tool. The memory lives where that server writes it. A host that speaks MCP can list the tools and read the result. Change the server, and you change who can read the next result.

A memory layer for AI agents can sit in the current prompt, in a file the host keeps for one person, or in a server the client calls. MCP memory is that server. The protocol is the door. The server decides the scope.

What is agentic memory? separates one agent's private recall from shared team context. This post stays on the server. The question is which process holds the memory, and who else can call it.

What a local MCP memory server does well

The reference implementation is the Knowledge Graph Memory Server in the modelcontextprotocol/servers repository. npm publishes it as @modelcontextprotocol/server-memory. The README describes a local knowledge graph that lets Claude remember information about the user across chats.

The graph has three parts.

• An entity has a name, a type, and a list of observations.
• A relation is a directed link. It names a source, a target, and a type in active voice, such as works_at.
• An observation is one string on an entity. The README asks for one fact per observation.

The server exposes that graph as tools. create_entities, create_relations, and add_observations write. read_graph returns the whole graph. search_nodes searches names, types, and observation text. open_nodes returns named entities and the relations between them. Delete tools remove entities, observations, or relations. A resource at memory://knowledge-graph returns the same shape as read_graph.

You run it as a local process. The README shows Claude Desktop and VS Code. The Claude Desktop example starts the server with npx and @modelcontextprotocol/server-memory, or with Docker. The default file is memory.jsonl in the server directory. MEMORY_FILE_PATH points the process at another file. The sample prompt is personal. It covers identity, habits, preferences, goals, and relationships for one user.

That fit is real. "Prefers morning meetings" is an observation, and the write is a tool call. Use this MCP memory server when the memory is about one person, and the next chat is on the same computer.

Where a personal memory server stops

The stop is the file.

Each MCP client starts its own server process. Two clients on one machine can share a store when both use the same MEMORY_FILE_PATH. The server takes an exclusive lock beside that file while it writes, so those processes take turns. The lock needs exclusive file creation, which a local filesystem provides. A teammate on another laptop does not receive the file. A host that never started the process does not have the graph.

Three gaps follow. They are the edge of a personal store.

The store is one machine. A copied file is a second copy. The copies drift the first time only one of them is updated.

There is no owner. An observation is a string. You can write a name inside it. The server has no member, no role, and no assignee.

There is no decision that keeps the options. "Do not add a queue" can be an observation. The server does not store a list of options, or a selected option with a time. A later string can contradict the first. Both sit in the file.

AI agent memory in this shape answers what this client should remember about this user. The next person, in a different host, still has to read the same choice.

	Local knowledge-graph server	One org server
Who it serves	One user, on the machine that holds the file	The organization
Where the bytes live	A local JSONL file, default memory.jsonl	The org, behind one HTTP endpoint
A second host	The same path on that machine, or a copy	The same URL, after OAuth, in the same org
A fact	Entity, relation, or observation string	Note, decision, task, or record
Options you ruled out	Another string, if someone wrote one	Options kept on the decision, with the one you selected
Owner	No member and no role	A participant on the decision, an assignee on the task

Both columns can be true for one person. Preferences can stay in the local graph. The retry policy cannot.

What the team has to carry

A shared memory layer for AI agents is small on purpose. It is the set the next host can cite.

• A decision. The problem, the options, and the one you selected. The options you did not select stay on it.
• An owner. A participant role on the decision. A task assignee for the next step. A person or an agent.
• A note. Content the graph can label, plus a kind. A fact that is not a choice.
• A record. The issue, the doc, or the pull request the decision rests on.
• The organization. Projects, tasks, work sessions, notes, decisions, and connected tools belong to one organization. Organizations and access states the boundary. A second organization does not see them.

MCP connectors for team context is a different job. A connector is how an agent reaches an app, and where that credential lives. This post is the store the agent reads and writes. A shared credential does not remember that the team left the queue unselected.

One MCP memory server for the org

BitsWeave keeps that set on the organization. Claude, Cursor, and the ChatGPT plugin connect to one MCP endpoint. Members of that org read the same decision.

The connect your agents guide points every client at https://bitsweave.com/api/mcp. Sign-in is OAuth in the browser. That handshake does not ask you to paste a token. Claude Code adds the server with one command: claude mcp add --transport http bitsweave https://bitsweave.com/api/mcp. The first tool call opens the consent flow. Approve it and the agent is bound to your account and to the active org.

Cursor and other JSON-config clients take the same URL. The guide names the ChatGPT plugin as a host you can install. Any client that speaks Streamable HTTP and OAuth can use that endpoint. Each person connects the host they already use. They pin the same organization as the active org.

An account in more than one org has to pin one. The guide says to call the accounts seed, then accounts_setActiveOrg, or to pin one from the org picker. Context reads do not take an organization argument. Explore context states the rule. The org comes from the active org, or from the org on the identifiers you pass.

The reads are four tools.

• context.search finds nodes that match free text. It returns ranked identifiers.
• context.graph returns how nodes relate. With no focal set, it is the org-wide map. With a focal set, it is that neighborhood. Depth defaults to 1. Budget defaults to 200.
• context.hydrate says what a node is. It returns snapshots. It does not walk.
• context.query returns evidence. Answer mode also returns claims and prose.

The context graph is that neighborhood. A person walks it at /app/context. An agent calls the same tools. A project, a decision, a note, and a member are focal kinds. Start from the decision, or from a project already linked to it.

A decision stores a title and a problem, then the options. You can mark one option recommended. When the decision is finalized, selected holds the chosen option and decided_at holds the time. Participants have roles. One role is owner. A later decision can supersede an earlier one. A note stores content. The graph labels the note from that content, and the note has a kind. A task has a title, a markdown body, a status, and an assignee. Tasks and projects lists those fields. The project holds the task tree.

Monday then has those objects. Three retries is the selected option. The queue stays on the decision as an option that was not selected. The on-call engineer is the owner. The customer note is an assigned task. The teammate does not need the laptop that wrote memory.jsonl.

BitsWeave does not read memory out of ChatGPT, Claude, or Cursor. The local knowledge graph stays on that machine. If nobody writes the decision, the org graph does not invent it. Someone still has to choose. Someone still has to record the options.

A checklist before you call it shared

1. Is the store a file on one machine? A JSONL path is a local server. An organization is a shared one.
2. Does a second laptop get the file without a copy? The same MEMORY_FILE_PATH only helps clients on that machine.
3. Do Claude, Cursor, and ChatGPT call the same endpoint? One URL, one OAuth sign-in, one active org.
4. Is there an owner? A sentence in an observation is not a member role.
5. Do the options you ruled out stay on the decision? A missing option gets proposed again.
6. Can the next person walk from the project to that decision? context.graph is that walk.
7. Did someone write it? Host memory does not fill the org. The write is a tool call, or it did not happen.

Questions teams ask

What is MCP memory?

MCP memory is an MCP server that exposes memory read and write tools to a client. The client is the agent host. The server is the store. A local server writes a file on one machine. An org server writes objects the organization can read.

Is an MCP memory server the same as AI agent memory?

No. AI agent memory is the broad name for continuity across turns. An MCP memory server is one way to build it. The client calls tools on a server. A host feature inside ChatGPT, Claude, or Cursor is a different layer.

Can two clients share the reference memory file?

Yes, on one machine. Point both at the same MEMORY_FILE_PATH. The server locks the file during a write. That share ends at the computer. It does not add an organization, an owner, or a decision with its options.

Does BitsWeave replace a personal memory server?

No. Keep the local graph for facts about one person on one computer. Use the org server when a teammate, or a second host, must see the choice, the options, and the owner.

One server. The same org.

Use a local MCP memory server when the next chat is yours, on that machine. Use one org server when the next reader is a teammate in Claude, Cursor, or ChatGPT.

Write the decision, including the options you did not take. Name the owner. Let the next host call the same endpoint.

Connect Claude, Cursor, or ChatGPT at bitsweave.com. The laptop can change. The memory should stay.