The fastest way to give Claude Code context on your codebase is not to paste files into the prompt — it is to register a graph of the codebase over MCP and let the agent query it. A coding agent that reads code by grepping and dumping files re-derives the structure of your project on every turn; a graph lets it ask precise questions and get file:line answers back, spending fewer tokens rediscovering the code and more on the task at hand.
This post is the practical version: how to wire CGraph into Claude Code, what the agent gains, and why a queryable graph beats stuffing raw files into context. For the deeper mechanism — how the graph decides which nodes to hand back within a token budget — see Budgeted context: just enough of your repo for an LLM.
The problem with dumping files
When you hand an agent context by pasting files (or letting it grep and read them itself), two things go wrong.
First, the agent sees text, not structure. As the CGraph overview puts it, an agent that reads code by grepping "sees text, not the graph of files, symbols, and references that the text encodes." A question like what breaks if I change this function's signature has no answer in a pile of files — the agent has to reconstruct the call relationships by hand, imperfectly, from repeated searches.
Second, it is expensive. The grep-and-read loop reloads source the model then has to re-read on every round-trip. Our benchmark against Graphify and grep measured this directly: against the grep-and-read behavior agents actually exhibit, querying a graph used roughly 82% fewer tokens and 60% fewer round-trips on a set of realistic navigation tasks. (That is a self-run benchmark on CGraph's own repo in a Debug build — read the caveats in the post before quoting any single figure.)
The alternative: a queryable graph over MCP
CGraph parses a repository once into a deterministic graph, keeps it resident in a per-project daemon, and exposes it to coding agents through an MCP server called cgraph-mcp. Instead of feeding the agent files, you feed it a connection to a warm graph it can interrogate.
Registering it with Claude Code is a one-line MCP setup, per the AI Agent Integration docs:
claude mcp add cgraph -- "$PWD/build/default/src/mcp/cgraph-mcp"
That is the whole configuration in Claude Code. cgraph-mcp resolves the project root and the daemon location on its own. As documented in the MCP integration page, it looks for the root in priority order — a --root flag, then the CLAUDE_PROJECT_DIR environment variable, then the working directory. Claude Code sets CLAUDE_PROJECT_DIR, and CGraph ships graphd next to the binary, so from Claude Code it needs no flags at all.
The one prerequisite is a built cgraph-mcp binary and a reachable daemon — see the CGraph installation guide for the build.
What the agent gains
With the server registered, the agent has eight graph tools alongside its usual file and shell access. The MCP docs list all eight: graph_query, graph_explain, graph_impact, graph_path, graph_context, graph_update, graph_status, and graph_shutdown. In practice you can think of them by the questions they answer:
| What you (or the agent) ask | Tool |
|---|---|
"What is Parser and where is it used?" | graph_query, graph_explain |
| "What breaks if I change this signature?" | graph_impact |
| "How do these two modules connect?" | graph_path |
| "Give me the relevant context, within budget." | graph_context |
| "Is the graph up to date?" | graph_status, graph_update |
The mapping above is straight from the AI Agent Integration docs. A few of these deserve calling out because they are things a file dump simply cannot do:
graph_impactreturns the transitive blast radius of a change — everything downstream that a signature edit would touch — in a single call. Doing that by grepping is a multi-round manual trace, which is exactly the kind of tedious analysis agents tend to skip.graph_contexthands back a packed, budgeted neighborhood around a node: enough of the surrounding code to be useful, few enough tokens to fit the window. That is the RAG-for-code path covered in the budgeted-context post.graph_pathfinds the shortest path between two symbols, which is how you answer "how does the auth layer end up calling the database" without reading every file in between.
Why this beats grepping on every turn
The core difference is persistence. Per the AI Agent Integration docs, an agent without a graph "re-derives structure from search on every turn." With CGraph it "asks precise questions and gets precise answers from a warm, persistent graph — fewer tokens spent rediscovering the codebase, more spent on the task."
Because MCP tool calls route through the same daemon operation handler as the command-line client, the agent gets exactly the semantics you would get from a shell — there is no separate, lossy "agent view" of your code. Ask graph_impact from Claude Code or run impact from cgraph-client and you get the same answer from the same warm graph.
The graph also stays current. The graph_status and graph_update tools let the agent check whether the graph is fresh and fold in changes, so it is not reasoning over a stale snapshot.
What this does not replace
CGraph indexes code structure — files, symbols, references, call relationships. It is not a full-text search engine. String literals, comments, config values, and file types it does not extract still need grep, as the benchmark post is careful to note. The right mental model is complementary: the graph answers structural questions ("who calls this, what breaks if I change it"), and grep answers content questions ("where does this string appear"). Giving Claude Code both is strictly better than giving it a folder of files and hoping it reconstructs the rest.
Get started
If you already have CGraph built, wiring it into Claude Code is the single claude mcp add line above. If you do not, start with the CGraph getting-started guide, then read Budgeted context: just enough of your repo for an LLM for how graph_context decides what to hand your agent. The whole engine is open source — read the code on GitHub.