Graph directory
Agents that can reach more than one standalone graph need a bounded catalog of
what each graph contains. The graph directory is that catalog: project-scoped
metadata for live standalone graphs, with pagination and lexical search over
graph_id, name, and description.
The directory does not search facts, entities, episodes, or other graph
contents. Use graph search after you select a
graph_id.
What the directory returns
Each entry is one live standalone graph in the authenticated project.
Names and descriptions are customer-authored routing metadata. Zep does not
generate them from graph contents. Graphs without a name or description still
appear; clients should fall back to graph_id for display.
The directory excludes user graphs, soft-deleted graphs, and graphs outside the authenticated project. For how to create standalone graphs and set routing metadata, see Create graph.
List and search with the SDKs
The SDK entry point is graph.list_all (GET /graph/list-all). Omit search
for an unfiltered page. Pass search to filter by graph_id, name, and
description: every whitespace-separated term must substring-match at least
one of those three fields (case-insensitive).
Default unfiltered order is newest first (created_at descending), with
graph_id as the tie-breaker. When search is set and order_by is omitted,
results order by lexical relevance, then name and graph_id. Passing
order_by with search sorts by that column and asc instead. Relevance
scores are internal and are not part of the public contract.
Responses include graphs, page_number, page_size, row_count (entries on
this page), and total_count (visible entries matching the filter). A page past
the end returns an empty graphs array with the correct total_count.
After you select a graph_id, search its contents with
graph.search (or add data with
graph.add).
Full request and response fields are in the List all graphs SDK reference.
Memory MCP exposure
When standalone graph access is enabled on the project connection, Memory MCP exposes the same directory contract through two surfaces:
Use the returned graph_id with search_graph_in (and the other _in tools)
to work with one selected standalone graph. Directory metadata search is not
the same as content search: list_graphs matches routing metadata;
search_graph and search_graph_in search graph contents.
Suggested agent flow:
- Read
zep://graphs/directoryfor an overview, or calllist_graphswithsearchwhen you know the kind of context you need. - Pick a matching
graph_id. - Call
search_graph_in(or another_intool) on that graph. - Do not query every accessible graph when one or a few clearly match.
Which graphs appear depends on the connection’s
standalone graph authorization
mode. Project-wide mode lists every live standalone graph in the token-bound
project. UserGroup ABAC mode applies the same graph.search grants as
search_graph_in before search, sort, count, and pagination. Hidden graphs do
not appear in results, counts, or ranking.
See Memory MCP Server and Connecting a client for setup and tool lists.
Limits
- The directory is metadata-only. It does not list user graphs or search graph contents.
- Descriptions are optional and customer-authored. Missing metadata does not hide a graph.
- Offset pagination can shift if graphs are created, updated, or deleted between page requests. Restart from page 1 when you need a coherent view after metadata changes.
- API and MCP share the directory contract. Page-size defaults: API and the
zep://graphs/directoryresource default to 50 (max 100); MCPlist_graphsdefaults to 20 (max 50).