Context engine for AI coding agents
A context engine for your repo: search by meaning, return exact snippets, and keep the rest out of context.
No config · any MCP client
The problem
Grep matches text, not intent. So agents guess, open file after file, and burn thousands of tokens before they find the function they actually needed. Finder indexes your repo once — embeddings plus a call graph — and answers with exact locations.
Context engine
A context engine is the layer between your AI agent and your codebase — it decides which code reaches the model's context window. Instead of dumping whole files into the prompt, it indexes the repo, retrieves only the relevant snippets, and assembles them into context the model can actually use.
The tools
Instead of your AI client crawling the repo, it calls Finder — one tool per kind of question, each returning bounded, read-only, cited evidence.
Semantic search expanded through the call graph and framework edges (React, Express, Django, Spring, Gin). Returns an evidence-graded context pack — code, dependencies, data flows, impact, tests — every item marked proven or inferred with file:line citations, and gaps listed as gaps.
When the file is known but the range isn't, it hands back path#Lstart-end with numbered lines — the exact snippet. The model never sees the other 99% of the file.
Definition, callers, callees, snippets and tests for a known function or class. Pure local graph analysis — no embedding call, no credits, and ambiguous names return candidates instead of a guess.
Which files, symbols and tests a change to a symbol touches, with the traversal that proves it. Your agent checks impact before editing instead of finding out in CI.
Plus housekeeping your agent uses on its own: index-status for readiness and freshness, list-repos for multi-repo setups, and approve-indexing — nothing gets indexed until you approve that exact folder. Opt-in power tools: repo-overview, detect-changes, rename (dry-run plan), checks and graph-query.
The kit
Finder ships finder-kit: skills that teach your AI how to work with the index at every stage of a task — explore, frame, plan, implement, test, review — so each phase costs the fewest tokens possible.
And zero setup for your tools — one click auto-configures the MCP server and prompt files for your agent harness:
How it works
Finder reads your repo and builds a semantic map of the code.
Your agent asks a question — no need to know file names or paths.
Only the relevant lines come back. The rest of the repo never touches your context.
Benchmark
8 ground-truth questions on a real Rust + TypeScript repo. Recall = share of the right files found.
| Setup | Recall | Main file | Tokens to read | Speed |
|---|---|---|---|---|
| No MCP grep + read files | 0.29 | 2/8 | ~143,000 | ~16 tool calls |
| Finder 1.0.0 | 0.76 | 8/8 | ~6,000 | 0.7 s new 40 ms repeated |
| GitNexus | 0.27 | 4/8 | ~1,230 | 175 ms |
| CodeGraph | 0.43 | 4/8 | ~6,240 | 161 ms |
Grep plus reading the top files cost ~143k tokens and ~16 tool calls per question — and still missed the main file on 6 of 8. Finder answered in one call, ~6k tokens, main file 8/8.
"How does the web UI get live indexing progress?" — the code never says that. Graph tools match names, so they scored 0 here; Finder matches meaning and found 3 of the 4 files. Overall recall 0.76 vs 0.27–0.43.
GitNexus and CodeGraph answer in 0.16–0.18 s from a local graph vs ~0.7 s for a never-seen Finder query (one remote embedding call), and GitNexus returns ~1.2k tokens against Finder's ~6k. When the question uses the code's own names, they match or beat Finder.
Our questions, our repo, and Finder was tuned on them — treat the gap as an upper bound. Only each tool's discovery call was tested. The no-MCP arm is a grep-and-read script, not a model run.
Apple M1 Pro · Finder 1.0.0 and GitNexus 1.6.9 re-run Oct 10 · CodeGraph 1.6.1 row is from the Oct 4 run · Finder new-question time is from the Oct 9 run · method and script (written up for 0.0.11)
Against another local context-engine MCP server, October 9: Finder 1.0.0, both on default settings.
| Setup | New question | Repeat | Recall | Memory |
|---|---|---|---|---|
| Finder 1.0.0 Flutter app, 4 questions | 484 ms | 33 ms | 0.85 | 181 MB |
| Other engine Flutter app, 4 questions | 650 ms | 729 ms | 0.82 | 227 MB |
| Finder 1.0.0 Rust repo, 8 questions | 708 ms | 37 ms | 0.73 | 139 MB |
| Other engine Rust repo, 8 questions | 954 ms | 1,135 ms | 0.73 | 237 MB |
Apple M1 Pro · mean latency · recall is level on the Rust repo, and Finder was slower on 2 of 12 first asks · Finder output 21 KB vs 48 KB · full results, CPU, cold start and caveats
Languages
FAQ
A context engine for AI coding agents. It indexes your repository with embeddings and a call graph, then answers your agent's questions over MCP with exact snippets and file:line citations instead of whole files.
Any MCP client. One click configures 15 agent harnesses, including Claude Code, Codex, Cursor, VS Code, Gemini CLI, Windsurf, Cline and Zed.
The index and call graph are built and stored on your machine, only for folders you approve. To search by meaning, Finder sends code snippets and your questions through our gateway to an embedding provider. The gateway does not store those request bodies, and we do not train on your code. The privacy policy has the details.
Indexing and queries use credits based on the tokens processed. As a guide, indexing one mid-size project takes about 36 credits and a typical query about 0.54. These are estimates, not fixed quotas; the pricing page shows what each pack covers.
No. Packs are one-time purchases and nothing renews automatically. Credits are valid for 1 month after activation, and top-ups made within that month share the same expiry date.
Yes. Ask within 14 days of purchase and we refund a pack whose credits have not been used. See the refund policy.
Email [email protected] or message the support bot on Telegram. We reply within 3 business days.
Run the server, point your MCP client at it, and let Finder do the reading.