Memory MCP Server
Let your users’ off-the-shelf agents work with the same memory as the agents you build, secured by your enterprise identity provider.
Available to Enterprise Plan customers only.
Currently available and enabled per account — contact sales to turn it on for your project.
What it does
The Memory MCP Server lets an end user connect an MCP client — Claude, ChatGPT, Cursor, and others — to their own Zep memory. The user signs in through your enterprise identity provider; the client then searches their memory for context and, when you allow it, adds new memory.
It is not the Documentation MCP server, which serves Zep’s public docs to coding assistants. This server serves one end user’s own memory, gated by your IdP.
The principal is the Zep user — the person whose memory lives in a project graph — not a member of your Zep account. Authentication runs inside your Zep deployment, on managed cloud or BYOC. Your identity provider is the only external dependency, and it only handles login.
Who it’s for
Until now, only the agents your organization built on Zep’s API could reach a user’s memory. The Memory MCP Server opens that memory to the off-the-shelf agents your people already use.
Both work against the same memory. A user’s in-house agent and their personal MCP client share one user graph, so context written by one is available to the other. Access stays governed: each user signs in through your single sign-on, reaches only their own memory, and writes only when you allow it.
Two roles appear throughout this documentation:
- Administrators — privileged members of your Zep account who configure the identity-provider connection for a project. See Configuring authentication.
- End users — the people who connect an MCP client to their own memory. See Connecting a client.
What users can access
Each connected user reads and writes only their own user graph. Tools take no user, graph, or project argument — the target is fixed by the authenticated identity, so one user’s token can never reach another user’s memory or another project.
The server exposes these tools:
Write tools are offered only when an administrator enables writes on the connection. A connection is read-only by default, and an account-level kill switch can disable all writes regardless of per-connection settings. See Configuring authentication.
How it works
Two separate questions decide every request: who the user is, and what they can reach.
- Who the user is. The end user signs in through your identity provider. Zep brokers that sign-in — the MCP client authenticates against Zep, and Zep sends the user to your IdP to log in. Zep then issues the client a short-lived token for that user.
- What the user can reach. Each user reaches only their own user graph, with read or write access set by the connection. No tool takes a user, graph, or project argument, so one user can never reach another’s memory or another project.
Because Zep brokers the connection, your identity provider only handles login. The MCP client never registers with your IdP and never receives a token from it. You do not pre-register each client — Claude, ChatGPT, Cursor — in your IdP, and the same setup works across Entra ID, Okta, and Google Workspace.
The client needs only the project’s MCP endpoint URL. It discovers how to authenticate and registers itself automatically over standard OAuth 2.1 with PKCE — there is no manual client setup.
Mapping identities to users
Zep maps a claim from your identity provider — sub by default — to a Zep user, so a returning person reaches the same memory each time. When you enable just-in-time provisioning, a new user is created on first sign-in; otherwise only existing Zep users can connect. See Configuring authentication.
Sessions
Access tokens are short-lived — about five minutes by default — and the client renews them automatically while access remains valid. An administrator can revoke a user’s session or disable the connection at any time. See Revoking access.