Unified agent memory in any MCP client Zep released the Memory MCP Server, enabling any MCP client to access a unified user memory graph governed by enterprise single sign-on. The server allows desktop assistants, coding agents, and custom agents to share context while maintaining access controls and deployment boundaries. Unified agent memory in any MCP client Your team's agents are split across surfaces: the desktop assistant, the coding tool, the agents you build in-house. Each keeps its own memory or none at all. The Memory MCP Server puts them on one governed user graph, gated by your enterprise single sign-on. Key takeaways One graph across every surface. Desktop assistants like Claude and ChatGPT, coding agents like Cursor and Claude Code, and the custom agents you build on Zep's API all read and write the same user agent memory https://help.getzep.com/memory-mcp-server?ref=blog.getzep.com . Context written by one is available to the next. Your enterprise SSO governs access. Each user signs in through the identity provider you already run, so who reaches agent memory follows the access controls you already enforce. No per-client setup, and the same connection works across Entra ID, Okta, and Google Workspace. Users reach only their own context. Zep's user model scopes every connection to the authenticated person's own graph, so one user can never reach another user's memory or another project. Governed by Zep's access and retention policies. Memory reached through the MCP server follows the same access controls and retention rules as the rest of your project, and a connection can be left read-only. Stays inside your deployment boundary. The server runs where your agent memory already lives, on Zep Cloud or in your VPC, so no user data leaves your deployment and your identity provider's only job is login. The problem: memory stranded on each surface A person on your team works across several agents in a day. They draft in a desktop assistant, write code in an agent inside their editor, and use the in-house agents your organization built. Each of these holds its own context, or starts cold every session. The desktop assistant does not know what the in-house agent already learned about that user, and the coding agent knows neither. Until now, only the agents your organization built on Zep's API could reach a user's memory. The off-the-shelf agents your people already live in had no way in. The same user is modeled three times, inconsistently, and the work one agent does to understand them is lost to the others. The requirement is narrow and hard at the same time: let any client a user trusts reach that user's memory, without loosening who can read what. The shared user graph The Memory MCP Server lets an end user connect an MCP https://modelcontextprotocol.io/?ref=blog.getzep.com client 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 to it. Both kinds of agent now work against the same memory. A user's in-house agent and their personal MCP client share one user graph, so a fact the in-house agent recorded this morning is available to the desktop assistant this afternoon. This covers the surfaces where work actually happens: desktop assistants such as Claude and ChatGPT, coding agents such as Cursor and Claude Code, and the custom agents you build on the API. One user, one graph, reachable from each. Built for the enterprise The same memory is now reachable from more agents, and it stays under the controls you already run: your single sign-on, your access policies, your deployment. Sign-in goes through your identity provider, so everyone who reaches agent memory is already governed by it, with nothing to register per client. An administrator connects the provider once see Configuring authentication https://help.getzep.com/memory-mcp-server/authentication?ref=blog.getzep.com ; after that, any client a user trusts connects with the project's endpoint URL. Each user reaches only their own context. One user's connection can never read another user's memory or another project, and memory served through the server follows the same access and retention policies as the rest of your project. Connections are read-only by default, and an administrator decides per connection whether a client may add memory, with an account-level kill switch to stop all writes at once. Everything runs inside your Zep deployment, on Zep Cloud or in your VPC. What your users can do Each connected user reads and writes only their own user graph. The server exposes three tools. | Tool | Access | Purpose | |---|---|---| search graph | read | Search the user's memory for context relevant to a query. Returns a ready-to-use context block by default, or raw observations, thread summaries, or episodes. | get user summary | read | Return a narrative summary of who the user is and what is stable about them. | add memory | write | Add new information to the user's memory as text, JSON, or a message. | Write access appears only when an administrator enables writes on the connection. The account-level kill switch disables all writes regardless of per-connection settings. Connecting a client An end user connects in three steps, with no manual configuration: - Add the project's MCP endpoint URL to your client as a remote server. In Claude Code: claude mcp add zep-memory --transport http