Every time I watched an AI coding assistant work on a large TypeScript project, I noticed the same pattern.
It wanted to answer something simple like:
Instead of reading a single symbol, it often opened an entire file.
Sometimes that meant 50 KB... sometimes 100 KB... just to extract a 30-line function.
Multiply that by dozens of requests during a coding session, and you quickly end up wasting thousands of tokens on code the model never actually needed.
So I built SymbolPeek.
SymbolPeek is an MCP server that gives AI coding agents symbol-level access to a codebase.
Instead of asking for a whole file, an agent can ask for exactly what it needs:
The result is dramatically smaller context with much richer information than plain text search.
Imagine a file with nearly 1,800 lines.
Instead of this:
Open the entire file.
the model can simply ask:
read_symbol(
path: ".../worker.js",
symbol: "createProject.collectImports"
)
and receive only the function it requested.
In one real example from the project itself, the response was about 2 KB instead of reading a 65 KB source file.
The model gets exactly what it asked for—and nothing else.
I wanted to know whether semantic navigation actually reduces context consumption for LLMs.
So I added lifetime statistics.
After normal day-to-day development, these are my current numbers:
Requests: 162
Files avoided: 163
Lines avoided: 352,910
Bytes avoided: 6.4 MB
Estimated tokens saved: ~1.61M
Average context reduction: 95.7%
These aren't synthetic benchmarks.
They're collected during real development while working with AI coding agents.
Each request compares the semantic response against the counterfactual of reading the complete source files involved.
The result surprised me more than I expected.
More than 95% of the source context simply wasn't necessary.
Text search is fantastic.
I still use grep every day.
But grep doesn't understand:
The TypeScript compiler already knows all of this.
Instead of parsing text again, SymbolPeek simply exposes the compiler's knowledge through MCP.
The project started as a TypeScript tool because that's where semantic navigation provides the biggest payoff.
Today it supports:
TypeScript and JavaScript use the official TypeScript Compiler API for semantic analysis.
Rust, Python, Java, Go, JSON and Markdown currently use Tree-sitter for fast syntax-aware navigation.
That means the same MCP server can be useful across mixed-language repositories instead of only TypeScript projects.
One thing I wanted to avoid was building "grep over MCP."
If a language already has a production-grade compiler capable of answering semantic questions, why ignore it?
For TypeScript, SymbolPeek uses the compiler itself to provide:
The information already exists.
The MCP server simply exposes it to AI coding agents.
For TypeScript and JavaScript:
Other supported languages currently provide syntax-aware navigation through Tree-sitter.
The goal isn't to replace grep.
It isn't to replace reading source files.
It's to eliminate one of the most expensive workflows AI agents perform every day:
Open a huge file just to inspect one declaration.
Less context.
Fewer tokens.
Better signal.
I'm especially interested in hearing from people building AI coding tools or working with:
Have you ever watched an AI spend thousands of tokens reading files just to answer a simple navigation question?
I'd love to hear how you're solving that today.
GitHub: