Skip to main content
Glama

Graphiti Local

Graphiti Local

Local memory for your agents. You approve what they learn.

Retrieve project decisions through six read-only MCP tools or the kg CLI. Proposed updates stay in a separate queue until a human approves and applies them. Ollama handles local inference; embedded LadybugDB stores the graph. No Docker or cloud API key is needed for the local setup.

42-second synthetic memory demo

Captured output excerpts with pauses condensed. Measured results and limitations.

Try it in one command

uvx --from git+https://github.com/renezander030/graphiti-local kg-demo

Answers a question against a small synthetic graph shipped with the package. No Ollama, no model downloads, no database setup: retrieval runs on keywords alone, so nothing contacts a model. Ask your own question by passing it as an argument.

This is the read path only. Building a graph from your own text needs extraction, which needs a model, and that is the full setup below.

Related MCP server: loom

Try it locally

Install uv and Ollama, then start Ollama. Setup downloads need internet access. Run these commands in bash or zsh:

git clone https://github.com/renezander030/graphiti-local.git
cd graphiti-local
uv sync --frozen
ollama pull qwen2.5:7b
ollama pull nomic-embed-text
export GRAPHITI_LOCAL_CONFIG="$PWD/config/ollama.example.yaml"
export KG_WORKSPACE_DIR="$PWD/workspace/local-demo"
export KG_LADYBUG_PATH="$KG_WORKSPACE_DIR/graph.ladybug"
uv run --frozen kg-ladybug-setup --database "$KG_LADYBUG_PATH" --apply
uv run --frozen kg doctor
uv run --frozen kg-ingest examples/local_memory_demo.jsonl --apply
uv run --frozen kg ask "Which database does Aurora Analytics use?" example

The synthetic example returns DuckDB. Follow the complete walkthrough to propose PostgreSQL, review and apply that update, and retrieve it from an MCP client. Model extraction can be wrong; inspect the returned facts and validity timestamps.

To review extraction before it touches the configured graph, run kg-ingest INPUT --review-output review.jsonl, inspect the snapshot, and mark every fact in the generated review.jsonl.review.jsonl file as accept, refuse, or contested. The printed restore command refuses unresolved decisions and promotes a checksum-sealed snapshot containing accepted facts only. Searches return current facts by default; kg ask --history is the explicit historical view.

kg-ingest also accepts a Markdown/text file or a directory tree directly. Large documents split at stable text boundaries. Transient writes retry with one stable episode id; ingest-receipts.jsonl and ingest-failures.jsonl in the workspace show exactly what landed and what still needs attention.

Multiple users on Ladybug

Give each user a group, and each group its own Ladybug file:

graph:
  groups: [alice, bob]
database:
  provider: ladybug
  ladybug:
    layout: per-group          # default: single, one file for every group
    directory: ./workspace/groups
server:
  transport: streamable-http
  auth:
    tokens:
      - {name: alice, token: "${ALICE_TOKEN}", groups: [alice]}
      - {name: bob, token: "${BOB_TOKEN}", groups: [bob]}

Each file is named by the SHA-256 of its group, so no group id can point outside the directory. Reads, kg ask and the drain open only the file of the group they address; a token granted alice never opens Bob's file. A read names one group, or the token's single group is used. For a tenant boundary inside one database server, use FalkorDB or Neo4j.

Is it a fit?

Use it for local agent memory with explicit human review. Skip it if you need agents to write through MCP or want a hosted service without local setup. FalkorDB and Neo4j are also supported.

If this helps your workflow, star the repository and share your setup result.

Maintained by René Zander, who builds context layers for AI agents on temporal knowledge graphs.

Independent community project built on Graphiti, not affiliated with or endorsed by Zep. Apache-2.0.

Available Tools

6 tools
get_entity_edgeA

Get one fact edge by UUID from an allow-listed graph.

Inputs: uuid (required). Returns: object

get_episode_entitiesB

Trace which entities and facts were produced by source episodes.

Inputs: episode_uuids (required), group_id. Returns: object

get_episodesC

Return the most recent source episodes from configured groups.

Inputs: group_ids, max_episodes. Returns: object

get_statusA

Check the server and its configured database connection.

Inputs: no named parameters. Returns: object

search_memory_factsC

Search temporal facts with optional type, time, group, and center filters.

Inputs: query (required), group_ids, max_facts, edge_types, +5 more. Returns: object

search_nodesC

Search graph entities. Requests are restricted to configured groups.

Inputs: query (required), group_ids, max_nodes, entity_types, +1 more. Returns: object

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

Loading tool schema changelog…

    TDQS

    B3.1/5.0

    Scored across 6 tools

    Disambiguation4/5

    Each tool targets a distinct resource-action: searching entities (search_nodes), listing episodes (get_episodes), searching facts (search_memory_facts), fetching a single edge (get_entity_edge), tracing provenance (get_episode_entities), and health (get_status). Mild overlap exists between search_memory_facts and get_entity_edge (both about fact edges) and between search_nodes and get_episode_entities (both surface entities), but descriptions differentiate them adequately.

    Naming Consistency4/5

    All names follow a clean snake_case verb_noun pattern (search_*, get_*). Minor inconsistency: only search_memory_facts carries the 'memory' qualifier while its sibling search_nodes targets entities, and the get_* prefix is overloaded across heterogeneous resources.

    Tool Count4/5

    Six tools is a reasonable, well-scoped set for a graph-memory server, with each tool covering a distinct retrieval need. It leans slightly thin—no ingestion or mutation tools—but the read surface is coherent.

    Completeness3/5

    The surface is entirely read-only: no operations to add episodes/entities/facts, update them, or delete them, which would normally be part of a knowledge-graph lifecycle. As a local read consumer of an externally built graph this may be intentional, but the missing write/traversal operations are a notable gap.

    Maintenance

    ActivityNo data
    ResponsivenessOutdated data

    Related MCP Connectors

    Related MCP Servers

    • A
      license
      B
      quality
      B
      maintenance
      Local-first agentic knowledge layer over Obsidian notes, enabling MCP-aware agents to search, retrieve, and compile knowledge with provenance and task contracts.
      37
      16 npm
      1
      MIT
    • A
      license
      A
      quality
      A
      maintenance
      Local-first knowledge graph MCP server — hybrid BM25 + vector + graph retrieval over your personal vault with provenance-grade extraction. 8 tools for Claude Desktop including search, archaeology, and graph write.
      14
      16 PyPI
      3
      MIT
    • A
      license
      Not graded
      quality
      F
      maintenance
      Local-first personal cognitive engine that provides MCP tools for managing relationships, conversations, agenda, and memory, powered by Ollama.
      Apache 2.0
    • A
      license
      C
      quality
      C
      maintenance
      A local-first personal information manager for knowledge, pins, tasks, and mounted sources, with MCP tools for agent-friendly access.
      63
      MIT