Build an MCP memory server agents can trust

What is an MCP memory server?

A Model Context Protocol memory server is a program that exposes memory operations to an MCP host through tools, resources or prompts. Tools perform actions such as remembering or searching. Resources expose readable context. The MCP specification defines how clients discover and call these capabilities; it does not decide what should be remembered.

That boundary matters. MCP is the connection layer, not the memory architecture. A production server still needs identity, scoped storage, extraction, ranking, source history, correction and deletion. Without those controls, a memory server becomes a shared text file that every connected agent can poison or overread.

Should an MCP memory server run locally or remotely?

Use local STDIO when one desktop or coding client needs memory tied to that machine. Use remote Streamable HTTP when several clients need the same customer or team memory. The MCP architecture describes local STDIO servers as typically serving one client and remote Streamable HTTP servers as serving many clients.

Do not copy a local JSON memory file into a remote deployment and call it multi-client memory. The remote version needs a real identity and authorization model.

Which tools should an MCP memory server expose?

Expose a small, unambiguous tool surface. The model should know exactly when to search memory, when to save a durable fact and when a fact should be corrected or removed. Bloated tool sets create ambiguous choices and increase context cost.

The tool schema should not accept userId or tenantId from the model. Those values belong to the authenticated MCP connection.

How should an MCP memory server scope user and tenant data?

Resolve authorization before a tool handler runs. Bind the MCP session or access token to a principal, then pass that trusted context into memory reads and writes. If scope resolution fails, return an error instead of falling back to a shared identity.

• Use the authenticated principal, not generated tool arguments, for scope.
• Keep tenant at the outermost boundary and user inside it.
• Use client and agent identifiers for provenance, not as a bypass around user scope.
• Block writes that contain credentials, payment data or unrelated sensitive details.

type Principal = {
  tenantId: string;
  userId: string;
  clientId: string;
};

async function searchMemory(
  input: { query: string; limit?: number },
  principal: Principal
) {
  if (!principal.tenantId || !principal.userId) {
    throw new Error('Authorized memory scope is missing');
  }

  return memory.search({
    query: input.query,
    userId: principal.userId,
    metadata: { tenant: principal.tenantId },
    limit: Math.min(input.limit ?? 8, 12),
  });
}

How can several MCP clients share the same memory?

Share a remote memory service, not a raw transport session. Each host opens its own MCP connection, authenticates the same human identity and receives a scoped view of the same durable graph. A Cursor client, Claude client and web agent can then remember the same project without copying private context into one another’s local files.

Use separate agent identities when working context should stay private. A shared project decision can live at project scope while a coding agent’s temporary hypothesis remains scoped to that agent or run. Promotion from private to shared memory should be an explicit operation.

How should you secure an MCP memory server?

Remote servers should use standard HTTP authorization, normally OAuth-based access tokens, and validate the token on every request. Local servers still need a boundary because a compromised host process can read anything that server can access.

Memory tools also expand the prompt-injection surface. Treat tool results as untrusted data, attach provenance to every memory, and require confirmation before high-impact actions based on remembered facts. A poisoned preference should not be able to redirect a payment or change production access.

• Require authenticated transport for remote memory and rotate credentials.
• Validate token audience, tenant, user and expiry before dispatch.
• Store source, timestamp and trust level next to every durable fact.
• Rate-limit searches and writes per principal to contain noisy clients.
• Log tool name, scope hash and outcome without logging memory content.
• Test deletion through every client and every read path.

How do you test an MCP memory server?

Test protocol behavior and memory behavior separately. First prove discovery and tool calls work in the MCP Inspector. Then prove the same identity retrieves only authorized memory and that a second user or tenant cannot cross the boundary.

What is the recommended MCP memory architecture?

Keep the MCP layer thin and the memory contract explicit. Resolve identity at the transport boundary, expose only a few tools, enforce scopes inside every handler and make correction and deletion first-class. The protocol makes memory portable across clients only when the service behind it remains portable and governed.