All-in-one `codegraph_explore` performs worse than seperate tools

[wauxhall]

I've tested on GLM-5.1 on real task and observed that explore results were too poor, so that agent fallback to grep.
Investigated and tried to turn off explore but enable 7 other tools.
Here's summary of agent feedback:

---

Problem

codegraph_explore combines search, blast radius, and source code into a single response. This sounds convenient but fails in practice for three reasons:

1. Misses critical results due to vague query matching
   When asked "what do I need to change if I add a new parameter to ListObjects", explore matched on the method ListObjects but missed the struct ListObjectsCfg — the most important file (options.go) for this task. The same query against codegraph_search ListObjectsCfg + codegraph_impact ListObjectsCfg immediately found it.
   Natural language queries are ambiguous. A single combined tool picks one interpretation silently and the user never knows what was missed.

2. Floods context with irrelevant source code
   A single explore call returned ~440 lines of source code. Only ~15 lines were actually needed.
   With separate tools, the agent gets structure only (file + line numbers), then does targeted Read calls for the ~15 lines it actually needs.

3. Silent truncation hides results
   On larger codebases, explore truncates blast radius results with "+N more". The agent has no way to know what was hidden or to request more. With separate tools, limit parameters are explicit and controllable — the agent sees it got 10/20 results and can increase the limit.

What works instead

Separate tools give the agent control over each step:

• codegraph_search → where is the symbol defined
• codegraph_impact → what will be affected (blast radius)
• codegraph_node → source of a specific symbol (on demand)
• codegraph_callers/callees → call chain navigation

Each step is intentional. The agent gets structure first, then reads only the files it needs. No 440-line dumps, no silent truncation, no missed files due to ambiguous query interpretation.

---

So I don't know why you refused tool separation model, seems this is your experience, but please don't remove it completely in future releases, separate tool really worked better for me. I think explore is tradeoff for cheaper usage, but quality suffers.

[colbymchenry]

Thanks for the unusually detailed report, @wauxhall — you were right, and #1 was a real bug.

What was happening: for a question like "what do I need to change if I add a new parameter to ListObjects", codegraph_explore returned ListObjects but dropped the file that defines its options (ListObjectsCfg in options.go). That file shares no words with your question and is only reachable through ListObjects's signature, so it scored ~0 on every text/graph signal and fell outside the results — exactly the "missed the most important file → fall back to grep" you saw. (I reproduced it on grpc-go: NewClient → dialOptions in dialoptions.go, same shape.)

Fixed — merged to main, shipping in v1.1.5. explore now follows a named function's parameter/return types and pulls in the file that defines them when ranking would otherwise bury it, so the options/config struct shows up with its fields. Once 1.1.5 is published, upgrade with:

codegraph upgrade   # or however you installed

Your other two points — both fair, and partly by design:

• Floods context with source (git-hook potential issue when codegraph is not installed globally #2): explore inlines source on purpose — on capable models it stops the agent re-reading the same files, which nets fewer tool calls overall. On a smaller model that tradeoff can cut the other way, which is what the escape hatch below is for.
• Silent truncation (Svelte 5 #3): a real limitation of one combined tool. The separate tools give you explicit limit control.

Most importantly — the separate tools aren't going anywhere. They're unlisted by default, but all stay fully functional and you re-enable any subset with one env var:

CODEGRAPH_MCP_TOOLS=search,impact,node,callers,callees,files,status

(add explore to the list to keep it too). That's a supported path — running smaller/cheaper models like your GLM-5.1 is a perfectly good reason to use it.

If explore still misses files for you on 1.1.5, reopen with the query + the symbol it should have surfaced and I'll dig in. Thanks again.