How to give Cursor a code knowledge graph (2026 guide)

Out of the box, Cursor answers codebase questions by searching: it greps for a symbol, opens the files that match, reads them into context, and assembles an answer. That works — and it's expensive in a specific way. The exploration repeats every session, the same files get re-read, and the architectural picture the agent builds is gone the moment you close the window.

A code knowledge graph changes the move available to the agent. Instead of re-deriving structure from text, Cursor queries a persistent map of your repo — functions, classes, tables, and config as nodes; calls, imports, and references as typed edges — built once and stored on your machine. Graphify is the open-source (MIT) tool that builds that graph and hands it to Cursor. The whole setup is four commands.

Step 1: install the Graphify CLI

Graphify is a Python package: uv tool install graphifyy. That puts the graphify command on your path. Everything runs on-device with no telemetry — code parsing is fully local, and the only optional network call is the model used to fold non-code sources into the graph, which can itself be local via Ollama.

Step 2: run graphify install

This is the wiring step. graphify install detects Cursor and registers Graphify's server over the Model Context Protocol — the open standard Cursor already speaks for external tools. That gives Cursor's agent eight graph tools it can call natively mid-conversation: query the structure, trace paths between nodes, explain why a node matters, and so on. No config files to hand-edit; the Cursor integration page has the specifics.

Step 3: map the repo with /graphify .

In your next agent session — or straight from the shell — run /graphify . in the repo. Tree-sitter parses your code locally across 36 languages, so the call and import edges come from real AST extraction with no model involved in reading your source. Docs, PDFs, SQL, Postgres schemas, and Terraform are folded in by whichever model you choose.

A few minutes later, three files sit in your repo: graph.html (an interactive map you can explore in a browser), GRAPH_REPORT.md (a written brief covering god nodes, subsystem communities, and suggested questions), and graph.json (the raw structure).

Step 4: ask Cursor structural questions

Now try the questions that used to trigger long search-and-read loops: what calls this function, what's the blast radius of renaming this column, how does the webhook handler reach the database. Cursor answers by traversing the graph — a handful of nodes and edges rather than the full text of every matching file — and every edge carries a provenance tag: EXTRACTED from the AST, INFERRED by the model, or AMBIGUOUS when the evidence couldn't be resolved. Why that tagging matters is covered in concepts.

You can run the same queries yourself: graphify query, graphify path, and graphify explain all work from the shell, and the full command reference lives in the docs.

What to expect

The durable win is structural: graph answers are small and the graph persists, so context stops being spent on re-discovery. Actual savings depend on your repo and your questions — one community user reported 71.5× fewer tokens on their workload, which is a community-reported figure rather than a benchmark, but it illustrates the direction. The other change is qualitative: because every answer traces to a path through real files, you can audit what Cursor tells you instead of taking a plausible-sounding reconstruction on faith.

Two habits keep the setup healthy. Re-run /graphify . when the code changes meaningfully so the map tracks reality, and open GRAPH_REPORT.md at least once — the god nodes and subsystem communities it names are usually worth knowing about even before the agent starts using them.