Cross-Language
Overview
Modern codebases rarely live in a single language. A typical service might have TypeScript on the frontend calling a Python API, which in turn writes to SQL tables, while a performance-critical path calls into a C library via Rust FFI.
sqry’s unified graph detects these cross-language relationships automatically during indexing. The detection runs in Pass 5 of the multi-pass graph build pipeline, after all per-language symbol graphs are constructed. sqry matches declarations in one language to definitions in another — for example, matching a Rust extern "C" declaration to the corresponding C function definition, or matching a fetch("/api/users") call in TypeScript to a @app.route("/api/users") handler in Python.
Cross-language edges are first-class nodes in the graph and are queryable with the same tools and syntax as same-language edges.
Supported Edge Types
| Edge type | Example | Languages |
|---|---|---|
ffi_call | Rust extern "C" declaration matched to C/C++ function definition | Rust → C, Rust → C++, C → C++ |
http_request | fetch("/api/users") or axios.post("/users") matched to route handler | JS/TS → Python, JS/TS → Go, JS/TS → Java |
grpc_call | gRPC stub call matched to service method definition | Any client → any server language |
db_query | SQL SELECT/INSERT/UPDATE/DELETE referencing a named table | SQL → table definition (any language) |
web_socket | WebSocket emit/on matched across client and server | JS/TS ↔ Python, JS/TS ↔ Go |
graphql_operation | GraphQL query/mutation matched to resolver | JS/TS, Python |
message_queue | Message producer matched to consumer by topic/queue name | Any language |
process_exec | Shell exec/spawn calls referencing an external binary or script | Shell/Bash → any |
Detection is heuristic-based and works on naming conventions, route strings, and extern declarations. Accuracy improves when codebases follow standard framework patterns (Express, FastAPI, Gin, Spring MVC, etc.).
CLI Queries
List all cross-language edges in the current workspace:
sqry graph cross-language
Filter by source language and edge type:
# All FFI calls originating from Rust
sqry graph cross-language --from-lang rust --edge-type ffi
# All SQL table access edges
sqry graph cross-language --from-lang sql --edge-type table
# All HTTP calls from TypeScript to any backend
sqry graph cross-language --from-lang typescript --edge-type http
# Flutter/Dart platform channel invocations
sqry graph cross-language --from-lang dart --edge-type channel_invoke
Combine with visualization to produce a cross-language dependency diagram:
sqry visualize "callers:main" --format mermaid
sqry export --format dot --output-file cross-lang.dot
MCP Tool
The cross_language_edges MCP tool exposes cross-language relationship data to AI assistants via the Model Context Protocol. It is available to any MCP client (Claude, Codex, Gemini, Cursor, Windsurf) connected to a running sqry mcp server.
The tool returns a structured list of cross-language edges, each with:
- Source symbol and language
- Target symbol and language
- Edge type (ffi_call, http_request, db_query, etc.)
- File locations for both sides
This lets an AI assistant answer questions like “what Python routes does the TypeScript frontend call?” or “which C functions are exposed to Rust via FFI?” with ground-truth data from the graph, rather than guessing from code patterns.
The cross_language_edges tool can be enabled or disabled independently using the SQRY_MCP_ENABLE_CROSS_LANGUAGE environment variable:
# Disable cross-language edges in the MCP server (all other tools unaffected)
export SQRY_MCP_ENABLE_CROSS_LANGUAGE=false