graphlens-navigation

graphlens Navigation

graphlens exposes exactly three MCP tools — search, relations, info — that replace grep/ls/file-reads for code navigation. Every result is a graph node (from a real parse, not text matching), so trust it instead of re-verifying with grep.

Decision tree: how to start

Know the exact symbol name or a node id?
  YES → relations(name) for callers/callees/implementors/refs in one call
        info(name) for its source + signature
  NO  → Can you describe it as literal text (a name fragment, a code snippet)?
          YES → search(query)  # name, content, and meaning are unified here
          NO  → search(query) still works — it falls back to semantic (meaning) matching

relations and info both accept a node id OR a plain symbol name — no separate lookup call needed. Pass either straight from a search result's id/qualified_name, or a name you already know.

The three tools

search(query, limit=25, path_glob=None, exhaustive=False)

The one way in — unifies NAME, CONTENT, and MEANING matching:

• Content is matched literally, not as regex — write Request( or getErrorMap( as-is, no escaping.
• Returns graph nodes with their signature (nodes), plus non-symbol text hits (text_matches) for content with no enclosing symbol (config/comments).
• Scope with path_glob (e.g. "tests/*", "*.ts", "!tests/*" to exclude a subtree) — there is no file:/content: query syntax, use path_glob instead of guessing one.
• Test files are excluded by default unless path_glob is set explicitly or the query itself mentions "test" — pass path_glob="tests/*" to search them on purpose.
• Set exhaustive=true for "list EVERY file that calls/imports X" — returns every matching file path (no signatures), uncapped by the normal top-N limit (which can silently drop matches on a large fan-out).
• If the response's note field is set, your literal text matched nothing — every node came from a name/meaning guess, not a confirmed hit. Simplify the query instead of repeating it verbatim.