MCP for agent memory: Graphiti + FalkorDB for persistent, multi-tenant knowledge graphs

Knowledge Graphs MCP with Claude Desktop and Graphiti

Highlights

Most agent memory demos collapse the moment you add a second user, a second project, or a second week of history. You either stuff more text into the prompt until latency spikes, or you bolt on a vector store and hope semantic search retrieves the right snippets. Neither approach gives you durable state, queryable relationships, or tenant isolation.

Graphiti’s MCP server takes a cleaner path: it turns conversations into a persistent knowledge graph and isolates each tenant’s memory by design using group_id. FalkorDB sits underneath as the default graph database, so the memory stays queryable, durable, and fast enough to use in production flows where response time and hallucination pressure both matter.

Agents Without Memory Are Just Expensive Chatbots Why Zep’s Graphiti Chose FalkorDB

MCP for agent memory

This walkthrough shows the shortest path from chat to persistent, isolated knowledge graph using Claude Desktop as the MCP client, Graphiti MCP server to extract entities and relationships, and FalkorDB to store the resulting graph with tenant isolation via Graphiti groups.

By the end, you will have a running local stack that writes every conversation turn into a knowledge graph, two completely separate graphs created from two unrelated conversations, and tenant isolation enforced via Graphiti group_id so “Project A memory” never shows up in “Project B memory.”

Why persistent graph memory matters for production agents

When an LLM hallucinates, it often does so because it lacks a reliable, retrievable state and still has to produce an answer. Persistent, structured memory changes the failure mode: the agent can retrieve explicit entities and relationships instead of making something up to fill gaps. Multi-tenancy is the second hard part. If you cannot isolate memory per user, org, workspace, or project, then agent memory becomes a data leak waiting to happen. Graphiti groups solve this at the storage layer, not as an afterthought in prompt formatting.

FalkorDB role in Graphiti

Model Context Protocol (MCP) matters here because it standardizes how an AI client connects to external tools and data sources through MCP servers, so integrations stop turning into one-off glue code. A single MCP-enabled client can connect to multiple MCP servers that expose typed tools, which keeps the integration surface consistent even as the underlying system evolves.

“At Block, open source is more than a development model, it’s the foundation of our work… Open technologies like the Model Context Protocol are the bridges that connect AI to real-world applications…”
— Dhanji R. Prasanna, CTO at Block

Run the stack (Graphiti MCP + FalkorDB)

Clone the Graphiti repository, navigate to the MCP folder, then bring up the services with Docker Compose. This starts a single container stack that includes FalkorDB (graph database), FalkorDB browser UI (so you can inspect graphs directly), and Graphiti MCP server (the MCP endpoint Claude Desktop talks to).

				
					git clone https://github.com/getzep/graphiti
cd graphiti/mcp_server
docker-compose up

				
			

The combined image runtime bundles FalkorDB with the MCP server as the default configuration, which means developers can run a single container stack that includes the graph store plus the MCP surface. This keeps local and staging environments aligned and reduces the friction when moving from single-user demo to real workloads.

Connect Claude Desktop to Graphiti

To connect Claude Desktop to the Graphiti MCP server, edit Claude Desktop’s config file and register Graphiti as an MCP server. On macOS, Claude Desktop stores its config under ~/Library/Application Support/Claude. In that directory, create claude_desktop_config.json if it does not already exist, then add:

				
					{
  "mcpServers": {
    "graphiti": {
      "command": "mcp-remote",
      "args": [
        "http://127.0.0.1:8000/mcp/"
      ]
    }
  },
  "globalShortcut": ""
}

				
			

Save the file and restart Claude Desktop. You can now send messages normally while Graphiti captures the conversation and persists it into FalkorDB as a knowledge graph.

Watch the knowledge graph appear

Open Claude Desktop and type a short, fact-rich conversation. The demo transcript uses space exploration facts. Graphiti automatically converts this conversation into a knowledge graph, creating entities and relationships. Open the FalkorDB browser interface to see your conversation structured as a knowledge graph where each piece of information becomes a node connected by relationships.

The important part is not that a graph exists. The important part is that the graph becomes a durable, queryable memory you can inspect and evolve. This turns unstructured chat into something you can query and constrain.

Concern Problem MCP + Graphiti + FalkorDB Approach (The Solution)
Tool sprawl Every system needs a custom connector Standardize client-to-server integration with **Model Context Protocol (MCP)**
Memory drift Facts disappear between sessions Persist **episodes** into a **knowledge graph** and retrieve nodes/facts by query
Tenant isolation One agent serves many users Use **Graphiti group_id namespacing** to separate contexts cleanly
Debuggability Prompts hide the real state Inspect the stored **graph** and run targeted **graph queries** when needed

Graph-based agent memory shows up as a reliability feature that helps when your agent must reconcile facts across time, users, and systems, and when you need inspectability for debugging. Join us on discord to share your projects and knowledge-share!

FAQ

Why use a knowledge graph for agent memory instead of vector search?

Knowledge graphs preserve explicit relationships and multi-hop connections between entities, making memory queryable and debuggable rather than probabilistic.

 Graphiti uses group_id namespacing to isolate each tenant’s conversation graph at the storage layer, preventing cross-contamination between contexts.