Code Graph

On This Page

1. What the index captures
2. Building & keeping the index fresh
3. Practical workflows
4. MCP tools
5. REST API
6. Storage

Why it beats grep: a text search for a method name matches every string that happens to share it — comments, unrelated overloads, same-named members on other types. Because the graph resolves invocations through the semantic model, an edge like calls points at the actual method that runs, correctly distinguishing overloads and following overrides and inheritance — not a string match.

Indexing is automatic — the graph keeps itself fresh

A background service, CodeGraphWatcher, keeps the graph current so you don't have to remember to re-index. It does three things:

• Heals on startup. When the app launches it sweeps every registered C# project and re-indexes any whose graph is stale — so a graph that sat untouched for weeks is brought up to date automatically.
• Re-indexes on edit. While the app runs it watches each registered project's .cs files. After a short quiet window (a debounce, ~12s by default) it re-indexes the project that changed. Rapid saves coalesce into a single re-index; build output (obj/, bin/) and generated files are ignored, so a build doesn't trigger churn.
• Picks up new projects mid-session. A project created or registered while the app is running (new-project wizard, create_project, or POST /api/projects) is indexed straight away — no restart needed.

A per-project freshness floor (5 min by default) suppresses redundant re-indexes, and a single coordinator (CodeGraphIndexCoordinator) serializes every index — automatic and manual alike — so two runs can never overlap and corrupt the graph.

Manual indexing (still available)

You rarely need to index by hand now, but you can force a refresh on demand with the index_code_graph MCP tool or POST /api/code-graph/index (see below) — useful to index a directory that isn't a registered project, or to refresh immediately rather than waiting for the debounce. Both paths run through the same coordinator as the watcher.

Configuration

The watcher is on by default and tuned with environment variables:

Worked example: who creates the MessageBroker?

Find a symbol, then trace its callers. The watcher keeps the graph fresh, so step 1 (an explicit index) is usually unnecessary — it's shown here to force an immediate refresh and to demonstrate the tool. The MCP calls and representative (elided) results:

// 1. (optional) Force an immediate index — normally the watcher handles this
index_code_graph(directory: "H:\\DevLaptop\\...\\MultiTerminal",
                 projectName: "MultiTerminal")
   → { "success": true, "projectName": "MultiTerminal",
        "fileCount": 156, "symbolCount": 7841,
        "relationshipCount": 24193, "durationMs": 9120 }

// 2. Find the symbol (exact matches first, then substring)
search_code_graph(query: "MessageBroker", type: "class")
   → results: [
        { "id": 1422, "name": "MessageBroker", "type": "class",
          "file_path": "MCPServer/Services/MessageBroker.cs",
          "line_number": 19, "accessibility": "public" }
      ]

// 3. Trace its callers ("who creates / depends on this?")
get_symbol_callers(symbolName: "MessageBroker")   // or symbolId: 1422
   → results: [
        { "name": "MessageBroker", "member_of": "MultiTerminalRestServer",
          "call_file": "API/MultiTerminalRestServer.cs", "call_line": 94 }
      ]

The caller row points at the exact construction site — API/MultiTerminalRestServer.cs:94, where the REST host does _broker = new MessageBroker(); — so you can jump straight to where the dependency lives (object creation is a calls edge). Resolve callees the same way with get_symbol_callees, or widen to the full transitive set with get_impact_analysis. (The numeric ids and counts above are representative — your exact values depend on the current index.)

Find a symbol

Search by name (exact matches first, then substring), optionally filtered by kind. This returns the symbol's id, file, line, accessibility, signature, and source preview — the starting point for every other query.

Trace callers and callees

Given a symbol, list its direct callers ("who depends on this?") and direct callees ("what does this reach?"). Each result includes the call site's file and line.

Impact analysis before a change

Run a transitive blast-radius query — the recursive set of everything that (in)directly calls a symbol, with cycle detection and a depth cap (default 10). Do this before refactoring a hot method to see what you might break.

Find dead code

List public/internal methods and properties with no incoming calls edge — candidates for removal. Scope it to a single project if you like.

Map a type's hierarchy

Walk the inheritance/implementation tree to see everything that derives from or implements a class or interface.