Most shell-native code navigation works at the text level. It finds names, strings, and patterns. That is useful, but it is not the same as understanding symbol resolution.
The LSP bridge gives CodeSift access to language-server knowledge when it is available: resolved definitions, hover type information, and cross-file symbol rename.
These tools should be understood primarily as capability tools, not just token-optimization tools.
How it works
- Lazy-starts the LSP on first use — zero overhead until needed
- Proxies LSP requests through the MCP tool interface
- Falls back to tree-sitter/AST/index when LSP is unavailable or times out
- Auto-kills the LSP after 5 minutes of idle — no persistent resource use
Supported language servers
| Language | Server |
|---|---|
| TypeScript/JavaScript | typescript-language-server |
| Python | pylsp |
| Go | gopls |
| Rust | rust-analyzer |
| Ruby | solargraph |
| PHP | intelephense |
The four LSP tools
go_to_definition — jump to the actual definition of a symbol, understanding imports, re-exports, type aliases, and module resolution.
get_type_info — get return type, parameter types, and documentation via LSP hover. 50-200 tokens instead of reading entire files.
rename_symbol — rename across all files with type safety. Understands shadowing, overloads, interface implementations. Not sed -i.
get_call_hierarchy — get incoming callers and outgoing callees of a symbol via LSP. Type-resolved precision that complements trace_call_chain.
How to read benchmark claims
For LSP-backed tools, benchmark results should be interpreted carefully.
What we can measure well:
- Fewer follow-up file reads
- Fewer agent steps
- Lower task-level token cost
What we are not claiming:
- That every LSP-backed answer is universally perfect across all languages
- That raw shell commands are directly equivalent in semantic precision
The practical takeaway: for type-aware navigation tasks, shell tools force agents to reconstruct meaning from text, while LSP-backed tools can often return the answer directly.