LynxMCP

LynxMCP is an MCP (Model Context Protocol) server that runs 100% locally, designed to answer code questions that grep cannot handle, such as: who calls this function? What is affected by modifying it? Where is the code that performs a certain behavior? How does the currently actually used library version behave? It works with any MCP client, including Claude Code, Cursor, Windsurf, Antigravity, and others.

Main capabilities:

• Behavior retrieval: when an identifier does not appear in the code literal, for example, "where do we limit camera zoom?", grep cannot match anything, while LynxMCP finds the relevant code through semantic retrieval.
• Structural queries: supports call graphs, inheritance relationships, polymorphic dispatch, and other structural questions with no textual traces, as well as the blast radius after modifying code.
• Knowledge supplementation: can index the documentation of the library versions you actually use and PDFs, filling knowledge gaps after the model's training cutoff.
• AST-aware chunking: uses Tree-sitter to parse 18+ languages (19 grammars, including TSX), indexing entire functions and classes rather than arbitrary text windows.
• Hybrid retrieval: combines dense vector embeddings with BM25 over code tokenization, fused via RRF, with optional cross-encoder reranking.
• Code knowledge graph (optional): records call relationships, inheritance, and imports, answers "what will break if I modify this?" and provides the actual blast radius.
• Multi-source indexing: codebases, public documentation sites (crawled once on demand; JS-rendered SPAs can be handled through optional headless Chromium), and PDFs can be searched side by side.
• Automatic rebuild: a file watcher reindexes about 2 seconds after a file is saved, with no manual rebuild needed.
• HTTP API and integrations: search and the graph are provided as NDJSON lines through a local HTTP API, and can be integrated with SQL engines, Coral, DuckDB, Steampipe, GitHub Action, etc., linking code with tickets, PRs, and logs.
• Browser management interface: lynx manager ui provides guided setup, a query playground, diagnostics, and client configuration snippets.
• Local operation: after HuggingFace models are downloaded once, switch to offline mode, with no telemetry, no cloud indexing, and no code upload. The only network access is model downloads and webdoc crawling explicitly triggered by the user.
• LightweightVolume dependency: based on ONNX Runtime, installation is about 460 MB, Linux download is about 165 MB, no need for the 4 GB CUDA libraries brought by PyTorch.
• Concurrent sessions: one index can serve multiple sessions simultaneously; only the indexing process is exclusive.

How to use:

• Initialize with lynx manager init; you can choose to open the Web UI and add sources through a guided form.
• Each AI tool is also a command, such as lynx find-definition ApplyDamage, lynx impact ApplyDamage, lynx graph query --op callers --symbol ApplyDamage; add --json for scripting.
• Register Lynx in an MCP client; complete guides are available for Claude Code, Cursor, Antigravity, and generic stdio clients, or let lynx manager ui generate a configuration snippet.
• The server responds to the MCP handshake in about one second and opens the index in the background; calls that arrive early return a loading state and retry.
• Double-click installers are provided for macOS and Windows.
• The tool set is fixed and does not grow with the number of sources; it is divided into core (5 tools, about 1300 tokens), standard (10 tools, about 2800 tokens, default), and full (17 tools, about 4150 tokens). You can set tools.profile in config.json or specify it with lynx serve --profile full; tools.include can add individual tools.
• Retrieval tools have the MCP readOnlyHint annotation, so clients can automatically approve them; the only write tool is export_graph.
• The server provides a usage manual during the MCP handshake (instructions plus the lynx://guide resource), so agents can query well without a rules file.
• Graph tools require the optional code knowledge graph to be enabled for the source.
• Shareable graph views: lynx graph export --symbol GetVoxel generates a self-contained offline file showing the symbol's impact scope, callers, and callees, which can be attached to a PR or archived for auditing.

Use cases:

• In large codebases, when built-in tools or grep are inefficient.
• Querying framework documentation when the model's training data is outdated.
• In repeated sessions, avoiding re-exploration from scratch.
• For developers who need to understand code structure, impact scope, and cross-source knowledge (code, documents, PDFs).

Limitations:

• On codebases with self-explanatory class names (such as Guava's BloomFilter, RateLimiter), grep ranks higher (hit@1 73% vs 60%).
• For repositories that fit entirely within an agent's context, built-in tools are sufficient.
• Developed by a single author; the API may change before stabilizing at 1.x.
• Benchmarks show that ranking fluctuates with how self-documenting the code is: leading on C#, mixed on Python, and behind on Guava; but token cost is reduced by 58% to 86% each time.
• Tool definitions consume tokens: core 1300, standard 2800, full 4150; a session pays for itself after one or two retrievals.
• Cost savings calculator: python benchmarks/savings_calculator.py --devs N or an interactive calculator; preset prices are editable.
• outline mode: search(query, outline=true) or ?view=outline returns ranked results without the body text, only a one-line signature and the first line of the docstring; agents can scan candidates and then read the needed body text by file:line. On psf/requests, tokens for the search step are reduced by 2.4x.
• Integrations: community sources in the Coral registry, DuckDB's read_ndjson_auto, Steampipe plugins, a GitHub Action that comments impact scope on PRs, MCP recipes combining GitHub, Sentry, and Jira.
• Firewall or air-gapped environments: models can come from a mirror, an automatic fallback from GitHub Releases, or a carried archive.
• The only network access is model downloads and explicit webdoc scraping; everything else is local.