Consider focusing on call graph + classification as primary tools

[jonathanpopham]

Context

From team discussion: GitHub's code intelligence features focus primarily on call graphs (find references, go to definition, find callers). Maybe we should do the same rather than offering 5 different graph types.

Observation

The most actionable questions agents ask are:

• "What calls this function?" → call graph
• "What does this function call?" → call graph
• "What domain/module does this belong to?" → domain classification

Less common:

• "What are all the imports?" → dependency graph
• "What's the AST structure?" → parse graph

Proposal

Consider a more focused toolset:

Primary tools (high value, fast)

1. find_callers - Given a function, return what calls it
2. find_callees - Given a function, return what it calls
3. classify_file - Given a file, return its domain/module classification

Secondary (full graph when needed)

4. get_full_graph - Current explore_codebase behavior for comprehensive analysis

Benefits

1. Faster - Call graph queries can be answered from indexed graph without regenerating
2. More intuitive - Agent asks "what calls X?" not "generate me a call graph"
3. Matches mental model - This is how developers think (find references, go to definition)
4. Proven approach - GitHub code intelligence, LSP, IDEs all do this

Prior Art

• GitHub Code Navigation: find references, go to definition
• LSP: textDocument/references, textDocument/definition
• IDE features: "Find Usages", "Call Hierarchy"

Questions

1. Is call graph sufficient for most agent tasks, or do we lose value by not offering dependency/parse graphs?
2. Should classification be a separate tool or bundled with call graph results?
3. How does this affect the context injection story (issue Support local graph.json file for instant context injection #82)?