Expose host IDE language server (LSP) capabilities as tools

Problem

Claude Code running inside VSCode (or any LSP-capable editor) has no access to the language server infrastructure that the host IDE already provides. This means all code navigation and refactoring falls back to text-based grep and string replacement — tools that have no semantic understanding of the code.

This is a significant regression from what IDEs have offered for decades. IntelliJ, VSCode, Eclipse, etc. all provide type-aware, AST-based operations through the Language Server Protocol. Claude Code is sitting right next to this infrastructure but can't use it.

What's missing

Operations that could be dramatically better with LSP access:

• Find References — Currently grep-based, which can't distinguish report.getTitle() from narrative.getTitle(). LSP's textDocument/references resolves this semantically.
• Rename Symbol — Currently string find/replace, which is error-prone across large codebases. LSP's textDocument/rename handles this safely with type awareness.
• Go to Definition / Type Definition — Would allow Claude to navigate to the actual source of a symbol instead of guessing with glob patterns.
• Find Implementations — Critical for working in codebases with interfaces/abstract classes. Currently requires grep + manual reasoning.
• Code Actions / Extract Method — LSP provides refactoring actions that understand scope, variable capture, return types, etc.
• Workspace Symbol Search — Type-aware symbol lookup across the entire project, far more precise than filename or content grep.
• Diagnostics — Access to compiler errors and warnings without needing to run a full build.

Proposed solution

Expose a set of tools that delegate to the host editor's LSP when running as a VSCode extension (or any editor with LSP support):

• lsp_find_references(file, line, column) → textDocument/references
• lsp_rename_symbol(file, line, column, newName) → textDocument/rename
• lsp_go_to_definition(file, line, column) → textDocument/definition
• lsp_find_implementations(file, line, column) → textDocument/implementation
• lsp_workspace_symbols(query) → workspace/symbol
• lsp_diagnostics(file?) → current diagnostics from the language server
• lsp_code_actions(file, range) → textDocument/codeAction

These could gracefully degrade — if no language server is available for a given file type, the tool returns an error and Claude falls back to grep/edit as it does today.

Why this matters

• Correctness: Semantic rename across 500 files is safe. Regex rename is a gamble.
• Speed: LSP operations are near-instant with an indexed workspace. Grep + manual reasoning is slow and token-expensive.
• The infrastructure already exists: VSCode is already running language servers for Java, TypeScript, Python, Go, Rust, etc. Claude Code just needs a bridge to call into them.
• Competitive gap: AI coding tools that leverage LSP will be strictly more capable than those limited to text search. This is low-hanging fruit.

Context

This came up while working in a large Java monorepo (~thousands of files) where grep-based "find usages" of a method name returns hundreds of false positives from unrelated classes with the same method name. The language server sitting in the same VSCode instance already knows exactly which 12 call sites are the real ones.