Memory MCP Server | Zep Documentation

Currently available and enabled per account — contact sales to turn it on. Google Workspace sign-in is available on managed cloud when the server is enabled; Custom OIDC requires the Enterprise plan.

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 Google Workspace or 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 and, when the standalone capability is enabled, standalone graphs in the same project, 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. Each user signs in through your single sign-on 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 can always read their own user graph. User-graph tools take no user, graph, or project argument — the target is fixed by the authenticated identity, so one user’s token cannot select another user’s memory or another project.

When standalone graph access is enabled for the account or BYOC deployment and allowed on the project connection, separate tools let the user list and select standalone graphs in the same project.

Standalone graph access is currently project-wide. Enabling it lets every authenticated MCP user in the project read every standalone graph in that project and, when writes are enabled, add data to them. Per-user and per-graph policy-based agent access (ABAC) controls are not applied to this capability.

The server exposes these tools:

Tool	Access	Purpose
`search_graph`	read	Search the user’s memory for context relevant to a query. `scope`: `auto` (default, optimized context block), `observations` (durable patterns such as preferences), `thread_summaries` (per-conversation summaries), or `episodes` (raw ingested messages/text/JSON)
`get_user_summary`	read	Read the user’s narrative summary
`add_memory`	write	Add new information to the user’s memory as text, JSON, or a message
`list_graphs`	read	List other accessible graphs in the project
`search_graph_in`	read	Search a selected standalone graph by `graph_id`; same `scope` options as `search_graph`
`add_memory_to_graph`	write	Add information to a selected standalone graph by `graph_id`

When standalone graph access is enabled, the server also exposes the paginated zep://graphs/directory resource. It returns each accessible graph’s graph_id, name, and description so an agent can select a graph before calling search_graph_in.

Write tools are offered when writes are enabled on the connection. A connection allows writes by default; an administrator can switch it to read-only, 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. Zep uses the user’s work email to discover the organization’s identity provider. After authentication, Zep finds every enabled project connection that admits the verified identity. It selects the project automatically when there is one, shows a chooser when there is more than one, and denies access when there are none. Zep binds the issued token to the selected connection and project. Each user reaches their own user graph, with read or write access set by the connection. If standalone access is enabled, the user can also select any standalone graph in the token-bound project. The project cannot be selected by an MCP request or tool argument.

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. Google Workspace is the default setup on managed cloud; Custom OIDC on Enterprise covers Entra ID, Okta, and other OIDC providers, and is the only option in BYOC.

The client uses one MCP endpoint URL for every project. The browser flow discovers the identity provider from the user’s work email and offers a project choice only when the verified identity can access more than one. The client discovers the rest of the authentication flow and registers itself automatically over standard OAuth 2.1 with PKCE.

Mapping identities to users

Zep maps a claim from your identity provider — sub by default, or the Google subject for Workspace — 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 with given and family name from the IdP when those claims are present; otherwise only existing Zep users can connect. If you later delete that Zep user, MCP recreates them on the next sign-in or request once the deletion finishes (same user ID, new graph). See Configuring authentication.

Sessions

Access tokens are short-lived — about five minutes by default — and the client renews them automatically while the grant remains within the connection’s grant maximum lifetime. An administrator can disable the connection at any time. See Revoking access.