MCP for code: giving agents a queryable graph instead of grep

The Model Context Protocol gives a coding agent a standard port into your codebase — and what you plug into that port decides how the agent sees your code. CGraph, our open-source code-intelligence engine, exposes eight MCP tools that let an agent query a repository as a graph of symbols, references, and dependencies instead of grepping it as text.

The problem

An agent that navigates by search sees text, not the structure the text encodes. Every request re-derives "what is this, who calls it, what depends on it" from scratch, and the answer is only as good as the search terms. The result is the grep-and-read loop we measured in the token tax of grep-and-read: the agent spends its budget on retrieval instead of reasoning.

MCP is the right place to fix this. It is the one integration surface every major agent — Claude Code, Codex, Cursor — already speaks, so a structural index wired in once is available to all of them.

Eight tools, four kinds of question

CGraph extracts the repository's structure once, keeps it warm in a per-project daemon, and serves it over MCP. The eight tools group by the question the agent is asking:

The agent wants to know	Reach for
"What is Parser and where is it used?"	graph_query, then 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, then graph_update (graph_shutdown ends the session)

Two of these are things grep cannot cheaply replicate. graph_impact returns the transitive blast radius of a change — everything reachable from a symbol — as a single query instead of a multi-round manual trace agents frequently skip. graph_context is built specifically for LLMs: it gathers the neighborhood around a node and packs it to a token budget, knapsack-style, reporting how it gathered and packed so the retrieval is inspectable rather than a black box.

The design decision that mattered: the MCP tools route through the same daemon operation handler as the CLI. We rejected a separate agent-facing API because two code paths drift — the agent would eventually see different semantics than a human at the terminal. One handler means one place to reason about correctness.

What it costs to adopt

Registering CGraph with an agent is one line. With Claude Code:

claude mcp add cgraph -- "$PWD/build/default/src/mcp/cgraph-mcp"

The server speaks JSON-RPC 2.0 over stdio and resolves the project root from the environment agents already set, so it usually needs no flags at all. In our published benchmark, answering four realistic navigation tasks through the graph used about 82% fewer tokens than the grep-and-read loop — a self-run benchmark on CGraph's own repository, with the caveats documented alongside the numbers.

Takeaway

An agent is only as good as the questions it can ask. Give it grep and it asks "what text matches?"; give it a graph over MCP and it asks "what breaks if I change this?" If you're wiring agents into a production codebase, that integration layer is an architecture decision — the kind we take on in AI and intelligent systems engagements.