code-graph

Code Graph

The code-graph-mcp server holds a pre-built knowledge graph of this repo: packages, files, components, frontend routes, HTTP calls, backend routes, and handler functions, with the edges between them. One tool call against the graph replaces a grep plus several file reads — use it first, read files second.

Question → tool mapping

The user asks…	Call
"Where does login land in the backend?" / "Which handler serves /users/:id?"	map_frontend_to_backend with the component, route, or path
"What uses Button?" / "What does Dashboard depend on?"	find_component_relations
"What's in this repo?" / "Which packages/services exist?"	repo_summary
"Where is X defined?"	search_symbols (never grep for this)
"What breaks if I change X?" / before a refactor	impact_of_change
"Show me the component tree / the flow"	visualize_graph
Results look stale after edits	reindex (incremental, cheap)

Workflow: answering a structural question

1. Call the single most specific tool from the table — not repo_summary first "for context" unless the question is actually repo-wide.
2. Answer from the tool output. Only read_file the specific files the graph named, and only if the user needs code-level detail beyond structure.
3. If a name isn't found, the tool returns closest matches — pick the right one and retry rather than switching to grep.

Workflow: adding a feature or fixing a bug

1. repo_summary — identify the right package/service.
2. find_component_relations on the nearest existing component/route — see its hooks, children, and endpoints so the new code matches local patterns.
3. map_frontend_to_backend if the change crosses the FE/BE boundary — know the handler before touching the client call (and vice versa).
4. impact_of_change on anything you're about to modify — list the blast radius and check the dependents after editing.
5. Only now read/edit the specific files identified. After substantial edits, call reindex so later questions in the session stay accurate.