MCP memory servers, explained.
The Model Context Protocol turned “connect this tool to my assistant” into a standard. Run memory as an MCP server and it stops being a feature locked inside one app and becomes infrastructure any assistant can read. This is what MCP is, why memory belongs behind it, how connectors and OAuth actually work, and how to self-host the engine.
What MCP is.
The Model Context Protocol (MCP) is an open standard for connecting AI assistants to external tools and data. Anthropic introduced it in November 2024; it is now developed as an open project stewarded under the Linux Foundation. The shape is client–server: a host application (Claude, ChatGPT in developer mode, an IDE agent) runs MCP clients, and each client connects to an MCP server that exposes tools it can call and resources it can read.
The point of a standard is that the two sides do not have to know about each other in advance. A server written once works in every host that speaks MCP, and a host gains a new capability just by connecting a server — no bespoke integration on either end. That is what makes memory worth building as an MCP server rather than as one more feature inside a single app.
One server beats a feature in every app.
Built-in memory is convenient and captive. A memory server is a little more setup and a lot more leverage.
The concrete payoff is cross-assistant continuity: a fact stored from Claude is recalled in ChatGPT because both are pointed at the same server. We walk through that setup in share memory between ChatGPT and Claude.
How connecting actually works.
A connectoris a host's configured link to an MCP server. For a local server, the client launches the server process and talks to it over standard input and output — no network and no sign-in. For a remote server reached over HTTPS, the host needs to know the request is authorized, and that is where OAuth comes in.
MCP's authorization builds on OAuth 2.1. The memory server acts as an OAuth resource server and advertises its authorization server through Protected Resource Metadata (RFC 9728). When you add the connector, the client discovers that authorization server, runs the flow with PKCE, and receives an access token scoped to that specific server. You approve access once; from then on the client attaches the token to each request. Because the token is bound to one server, it cannot be replayed against a different one.
https://genesys-api.astrixlabs.ai/mcp — and approve the sign-in popup.Run the engine yourself.
The Genesys memory engine is open source (AGPLv3) and published on PyPI. It ships a lightweight stdio MCP server for local use, runs with no API keys using a local embedder, and reaches every backend through a storage abstraction — so you are never importing a database client into business logic. The hosted server at the Genesys /mcp endpoint is the same engine, run for you with authentication and a database.
On retrieval quality, the same engine scores 85.55 ± 0.37 on LoCoMo, the mean of ten runs under a frozen gpt-4o-mini answerer and judge at temperature 0 (n=1,540, categories 1–4; evaluated July 2026) — published with its ceiling, its churn, and the answers it loses as well as gains.
Common questions.
What is an MCP memory server?
An MCP memory server is a Model Context Protocol server whose tools store, recall, and manage long-term memory, backed by a persistent store. Any assistant that supports MCP connectors can connect to it and read or write the same memory — so the server, not the app, holds your context. MCP is an open standard introduced by Anthropic in November 2024 and now stewarded under the Linux Foundation.
Why use an MCP memory server instead of an app's built-in memory?
Built-in memory is locked to one application: you cannot inspect it as data, move it, or reuse it in another assistant. An MCP memory server inverts that — one server, many clients. The memory becomes portable across apps, swappable for a different backend, and, if the server is open source, fully inspectable. You connect once per client and the same store answers everywhere.
How do MCP connectors and OAuth work?
For remote servers, MCP's authorization builds on OAuth 2.1. The server acts as an OAuth resource server and advertises its authorization server through Protected Resource Metadata (RFC 9728). When you add the connector, the client discovers that authorization server, runs the OAuth flow with PKCE, and receives an access token scoped to that specific server. You approve access once; the client then presents the token on each request.
Can I self-host an MCP memory server?
Yes. Genesys ships an open-source engine on PyPI: pip install genesys-memory, then run python -m genesys_memory to start a local stdio MCP server. It runs with no API keys using a local embedder, stores data through a storage abstraction so you can swap backends, and is AGPLv3 licensed. The hosted server at the Genesys /mcp endpoint is the same engine, run for you with auth and a database.
Does an MCP memory server need the internet or API keys?
Not necessarily. A local stdio server communicates over standard input and output on your own machine — no network, no OAuth, and no API keys when paired with a local embedder. OAuth and HTTPS come into play only for a remote server that assistants connect to over the internet.
Related.
Share memory between ChatGPT & Claude
The MCP memory server pattern applied — connected on both sides, step by step.
What is an AI memory layer?
Store, recall, forgetting; vector vs. temporal-graph vs. causal-graph architectures.
LoCoMo results
The certified number and how to cite it, with the comparability caveats.
Genesys for developers
The open-source engine: scoring, causal graph, lifecycle, and the MCP tools.