Memory MCP alternatives
The Memory reference server keeps a local knowledge graph of entities, relations, and observations, with tools like create_entities, add_observations, read_graph, and search_nodes. It is a small, self-hosted process from Anthropic, and the graph lives wherever you run it. People reach past it for one of two reasons: they want an agent that touches real systems rather than a private graph, or they want something other than a local file backing the memory.
The servers below are a mixed set, because Memory itself sits in the developer-tools category rather than any one product. Some give an agent a sandbox to read and act on (files, containers, clusters); others connect it to a code host or a quality scanner. Each note says what the server actually does so you can tell which job it fits.
The 8 best alternatives
Where Memory holds a static graph, Fetch pulls live pages: it retrieves a URL and converts the page to clean markdown for the agent to read. It is the reference server for getting outside text in, not for storing it.
Set up Fetch →Another Anthropic reference server, Time answers current-time lookups and converts between zones using the IANA database. Pair it with a memory store when an agent needs to reason about when something happened rather than only what.
Set up Time →- DockerOfficial
Running other servers is the job of Docker's MCP Gateway: it aggregates containerized MCP servers behind one endpoint, with on-demand discovery from the Docker MCP Catalog. It is infrastructure for hosting a memory server, not a memory store itself.
Set up Docker → - FilesystemOfficial
The Filesystem reference server reads, writes, edits, and searches within allowed directories. If the persistence you wanted from Memory is really just notes on disk, this gives an agent direct file access instead of a graph abstraction.
Set up Filesystem → - KubernetesCommunity
For clusters rather than notes, the Kubernetes server lists and inspects pods, nodes, namespaces, and Helm releases through the Kubernetes API. It is an operations tool, useful when the state your agent tracks lives in a live cluster.
Set up Kubernetes → Version history is its own durable record, which is why the Git reference server lands next to a memory store: it reports status, diffs, commits, branches, and history on a local repo path.
Set up Git →GitHub's official remote server reaches repos, issues, pull requests, Actions, and code search. It is the move when the context worth remembering already lives in a code host rather than a private graph you maintain.
Set up GitHub →Sonar's official server runs SonarQube code quality, security, and coverage analysis from an agent. It is adjacent rather than a replacement: it produces findings about a codebase, which you might then want a memory layer to retain.
Set up SonarQube →
How to choose
Memory is a local knowledge graph, so its closest cousins are the other Anthropic reference servers: Fetch for reading the web and Time for clock and timezone work. If what you actually wanted was durable state in real systems, Filesystem keeps notes on disk, Git and GitHub track code history, and Kubernetes reflects live cluster state. Docker and SonarQube are adjacent tools rather than memory stores. None of these is a drop-in graph replacement, so pick by the job, not by the label.
FAQ
- What does the Memory MCP server actually store?
- Entities, relations, and observations in a local knowledge graph. It exposes tools such as create_entities, create_relations, add_observations, read_graph, and search_nodes. The data sits on the machine running the server, not in a hosted service.
- Is there a hosted version of the Memory server?
- No. The Memory reference server is open source and runs locally over stdio; there is no managed endpoint. If you want memory behind a URL with OAuth, you are looking at a different product than this reference server.
- Which of these is the closest replacement?
- None is a one-to-one graph swap. Filesystem is the nearest if you mainly wanted persistent notes on disk; Git and GitHub fit when the durable record is code and its history. The rest are adjacent tools for live systems.