MCP memory server
By Mike Schreiber · Updated 31 October 2026
MCP memory server
An MCP memory server is a service that makes persistent information available to an AI application through the Model Context Protocol. Its purpose is to let an assistant retrieve useful context beyond the current conversation, such as project decisions, preferences, or unfinished work. MCP supplies the context-exchange interface, not a prescribed memory database or a guarantee that the application will use everything retrieved. [1]
How it works
An AI application acts as the MCP host, connecting through a client to a server. Servers can expose tools for actions, resources for contextual data, and reusable prompts. A memory implementation can use those interfaces to retrieve stored records or offer operations for updating them. Storage format, retrieval behavior, and retention should therefore be evaluated for the particular implementation, rather than inferred from the MCP label. [1]
Memory is distinct from conversation replay. Claude Code, for example, separates persistent instructions and auto memory from saved session transcripts. Its auto memory is machine-local, while resuming a session restores conversation history according to its session and compaction rules. [2][3]
Local versus hosted
A local server runs on the same machine as its client, commonly communicating through standard input/output. A hosted server runs remotely, commonly using Streamable HTTP and potentially serving multiple clients. These describe server execution and transport, not how the host ultimately manages retrieved context: MCP explicitly leaves that management to the AI application. [1]
For a local deployment, check storage paths, backups, and which retrieved records the host sends onward. For a hosted deployment, review authentication, project permissions, retention, and supported client versions. HTTP supports authentication mechanisms, but each server and client still needs compatible protocol capabilities. [1]
Practical example
Suppose a team pauses a billing migration. A useful memory record would capture the accepted decision to preserve existing invoice identifiers, the evidence supporting it, the remaining validation task, and the next owner. In a later session, ask the assistant to retrieve that record before proposing changes, then verify that it returned the correct project and current decision.
Hark fits this project-record model rather than universal transcript transfer. Its briefs, Memory, and handoffs read one record covering Inventory, Health, Work, Authority, and Decisions. Records carry evidence labels and sources; its automatic session hooks and compaction protection are Claude Code-only, while other tools use their connection guides and explicit session tools. [4]
Sources
[1] MCP architecture
[4] How Hark works