| name | repo-intel-search |
| description | Use the repo-intel MCP tools to answer questions about THIS repository's code — what depends on a symbol, who calls it, where it is defined, where behaviour lives, and what the module layout is. Prefer them over grep/glob for any of those questions. |
Answering questions about this repository with repo-intel
Five tools over a local index and a compiler-grade semantic graph. The graph tools answer questions
grep cannot express at all.
The graph tools — prefer these for structural questions
impact_of — what breaks if this changes. Input { "symbol": "<name>", "depth": 2 }. Returns the
symbol's actuals, its dependents to a bounded depth, the downstream modules, and any implementation
outside the indexed scope. The answer always states the depth applied and how many results were
elided. There is no way to ask this question with a text search.
who_calls — every call and reference site, each at its own file:line, qualified by source set, and
including callers in other modules and callers of an expect's actuals.
Input { "symbol": "<name>", "module": "<optional>", "sourceSet": "<optional>" }.
find_symbol — where a symbol is defined: the declaration, its compiler-bound actuals, and any
actual outside the indexed scope. Input { "symbol": "<name>" }.
Batch these. Asking find_symbol and then who_calls for the same symbol in two separate turns
costs a whole extra round trip for an answer the graph could have given at once.
The retrieval tools
search_code — hybrid keyword + semantic search over declaration-aware chunks.
Input { "query": "<what you are looking for>", "k": 10, "lane": "fused", "rerank": true }.
repo_map — a token-budgeted module → file → declaration outline.
Input { "token_budget": 1200, "module": "<optional>" }.
Reading the response
Every response carries index_state: lanes_available (which of lexical/dense/rerank actually served
THIS response), stale, fresh_as_of_commit, and for graph answers graph_status. Read them. If
stale is true the working tree moved since indexing and line numbers are approximate. If a lane you
expected is absent, it did not run — the response is honest about it rather than silently degraded.
A genuine failure is an MCP protocol error carrying {code, message}. A degradation — no dense lane,
a partial graph, an empty result — is a normal result with an honest index_state.
