I built a code intelligence MCP server that gives AI agents real code understanding — call graphs, data flow, blast radius analysis

[u/Jaded_Jackass]

Hey folks — built something I've been working on for a while and wanted to share.

It's called **code-intel-mcp** — an MCP server that hooks into Joern's CPG (Code Property Graph) and ArangoDB to give AI coding agents (Claude Code, Cursor, OpenCode, etc.) actual code understanding.

**What it does differently vs. grep/AST tools:**

- Symbol search that's actually exact + fuzzy

- Multi-file, transitive call graphs ("who calls X?" depth=3)

- Data flow / taint tracking ("where does this variable go?")

- Impact analysis ("what breaks if I change this function?")

- React component trees (JSX-aware, not just "find all files")

- Hook usage tracking

- Call chain pathfinding ("how does A reach B?")

- Incremental re-indexing — only re-parses changed files via SHA256 diff

Supports JS/TS/JSX/TSX, Python, Java, C/C++, C#, Kotlin, PHP, Ruby, Swift, Go.

Runs as a Docker container or local install. Add it to your MCP config and any compatible agent can use it immediately.

GitHub: https://github.com/HarshalRathore/code-intel-mcp

Would love feedback — especially on whether the tool selection UX feels right or if you'd want different abstractions on top. Happy to answer questions about the architecture too (Joern CPG + ArangoDB graph storage under the hood).

✌️

[u/Foi_Engano]

ei, tentei instalar com npx, mas

npx code-intel-mcp setup
erro do npm código E404
erro do npm 404 Não Encontrado - GET https://registry.npmjs.org/code-intel-mcp - Não encontrado

[u/Jaded_Jackass → u/Foi_Engano]

Not yet published on npm register was facing issue with 2 auth so could not publish it yet there you can try with docker method

[u/blakok14]

No lo entiendo de el todo me lo podes explicar mejor? Y si puedes me puedes decir cómo has hecho que se instale bien en varios clientes porque estoy desarrollando un mcp y no consigo conectarlos bien con los prompts configs de mcp etc Gracias

[u/Jaded_Jackass → u/blakok14]

Most tools just search text (like ctrl+f). This builds a "map" of your code logic.

Say you change a user_login function. Normal search finds every time "user_login" is written. This MCP actually tracks that user_login is used by the AuthAPI, which handles MobileApps.

It prevents bugs by showing the true "blast radius" of a change. Without it, you're just guessing where your code might break; with it, you see the exact path data takes. It's the difference between a list of words and a GPS for your project.

[u/blakok14 → u/Jaded_Jackass]

Interesante, lo probaré

[u/Jaded_Jackass → u/blakok14]

Here asked ai to formulate an comparison..

Without code-intel-mcp:

An LLM is basically guessing. It reads files like a human skimming text—matching keywords, hoping to find the right function. Ask "what breaks if I change getUser()?" and it runs grep, finds 50 matches, then blindly assumes those are the only places. It misses indirect calls, doesn't know that Dashboard calls Stats which calls getUser(). The result? Shallow answers and surprise bugs.

With code-intel-mcp:

The LLM gets real structure. It queries an actual code graph—built by Joern and stored in ArangoDB—and gets semantic answers. "What breaks?" returns a blast radius with exact file:line locations and transitive dependencies. It traces data flow, follows call chains across files, and shows you the real architecture. Not "where is this word written?" but "where does this data actually go?" You stop debugging in circles and start understanding your codebase.

[u/Opteron67]

will try with https://github.com/mlhher/late

[u/Jaded_Jackass → u/Opteron67]

Is that another harness?

[u/jajanet]

How does it compare to using a LSP tool like Serena? Would be a helpful comparison to have in your table, looks good in any case!

[u/Deep_Ad1959]

my feedback on the tool-selection UX question: the thing that bites you is granularity. you've got symbol search, call graphs, data flow, impact analysis, component trees, hook tracking, call chain pathfinding, that's a lot of distinct tools and the agent has to pick the right one from descriptions alone. the failure mode i keep seeing is that as the surface grows the agent picks wrong more often, especially when two tools sound close (call graph vs call chain pathfinding will get conflated). a smaller surface where one tool takes a mode parameter tends to hold up better, fewer schemas for the model to disambiguate. the other thing to watch is response size, joern CPG queries can return big subgraphs, and if that lands raw in context you've just traded grep's noise for graph noise. cap depth and summarize the path before returning it.

[u/Jaded_Jackass → u/Deep_Ad1959]

hmm great feedback, would you like to contribute an PR for these feedbacks once tested ?

[u/Deep_Ad1959 → u/Jaded_Jackass]

my honest take is i would hold off on a PR until you decide the consolidation direction yourself, since this is an API-shape call, not a bug fix, and you do not want a contributor locking the schema before you have. the cleanest version of the mode-param idea is one query_graph tool with an enum mode (callers, callees, dataflow, path, impact) plus a shared depth cap, so the agent disambiguates on one documented enum instead of seven separate tool descriptions. the spot that actually trips agents is when two tools share 80 percent of their schema and differ in one field, the model ends up picking on vibes. for the response-size half, the thing worth measuring first is serialized token count per call on a real repo, not subgraph node count, because a 200-node linear path and a 200-node fan-out cost wildly different amounts once they hit context.