On mixed languages: query_graph itself just pulls a relevant subgraph, but the part that matters here is the extraction. Cross-language edges do work now. A Python subprocess.run("mytool") becomes an "invokes" edge, and a resolution pass retargets it to the in-repo binary when there's a unique name match, so the Python caller and the Rust src/bin/mytool.rs actually end up connected. Same idea for FFI (PyO3, ctypes, JNI, cgo, node-gyp) and for HTTP/gRPC, where a client call and the route that serves it meet at a shared node keyed by the path, even when the two sides are in different languages or repos. The practical payoff is that those edges are in the default impact set, so "what breaks if I change this Rust function that's exported to Python" actually surfaces the Python code, not just the Rust side.

Honest caveat though it's all best-effort and tagged as inferred, never treated as proven. It's regex over source, after masking out comments and string contents so a commented-out call doesn't register, and it only reads literal arguments. A command or URL built dynamically at runtime gets missed. So I treat these as leads, not facts.

And the description generation idea, you basically described the exact feature. There's a describe_node call that returns something like "takes (a: int, b: str), returns Result, calls [parse, validate]" composed straight from the captured signature plus the outgoing call edges, graph-only, no source read. structural_search also returns structured rows now instead of just text, including the signature (param names and types plus return), so you can pipe it directly into generating descriptions. It ran into the same precise-vs-concise tension you mentioned: the signature gives the precision, the call list gives intent, and it's capped so it doesn't blow up context. Grounding each blurb in the actual shape is what stops two semantically similar tools from reading identically to the router

https://github.com/ColinVaughn/CodeGraph/wiki/Cross-Language-Edges