Expose individual graph types as separate MCP tools

[jonathanpopham]

Summary

Currently the MCP server exposes only one tool (explore_codebase) which calls /v1/graphs/supermodel and returns the full combined graph. This takes 5-15 minutes and returns everything at once.

The API supports 5 distinct graph types that could be exposed as individual tools, allowing agents to request only what they need:

Tool	Endpoint	Use Case
get_call_graph	/v1/graphs/call	Trace function calls, find callers/callees
get_dependency_graph	/v1/graphs/dependency	Understand imports, module relationships
get_domain_graph	/v1/graphs/domain	High-level architecture overview
get_parse_graph	/v1/graphs/parse	AST-level detail for refactoring
create_supermodel_graph	/v1/graphs/supermodel	Full combined graph (current behavior)

Motivation

1. Faster responses - Individual graphs are smaller and faster to generate than the combined supermodel graph
2. Targeted context - Agent can request only the graph type relevant to the task (e.g., call graph for "what calls this function?")
3. Lower token cost - Smaller responses = fewer tokens in context
4. Better agent decision-making - Agent can choose the right tool for the job instead of always getting everything

Proposed Behavior

Each tool would:

• Accept the same path parameter as current explore_codebase
• Support jq_filter for response filtering
• Use the same caching/idempotency mechanism
• Return graph data in the same format as the corresponding API endpoint

Example Usage

Agent: "What functions call processPayment()?"
→ Calls get_call_graph (faster, focused)

Agent: "What modules does billing.ts depend on?"  
→ Calls get_dependency_graph (import relationships only)

Agent: "Give me an overview of the architecture"
→ Calls get_domain_graph (high-level domains)

Alternative Considered

Keep single explore_codebase tool but add a graph_type parameter. Decided against this because separate tools are more discoverable and match how agents typically select tools based on capability description.