[FEATURE] Expand LSP tool to support more protocol methods (call hierarchy, rename, code actions, type hierarchy)
Preflight Checklist
- [x] I have searched existing requests and this feature hasn't been requested yet
- [x] This is a single feature request (not multiple features)
Problem Statement
The LSP tool currently supports only 9 operations: goToDefinition, findReferences, hover, documentSymbol, workspaceSymbol, goToImplementation, prepareCallHierarchy, incomingCalls, and outgoingCalls.
However, several of these don't actually work because the LSP plugin infrastructure doesn't register handlers for the corresponding LSP protocol methods. Specifically, prepareCallHierarchy fails with:
Error: LSP request 'textDocument/prepareCallHierarchy' failed for server 'plugin:php-lsp:intelephense': Unhandled method textDocument/prepareCallHierarchy
This means incomingCalls and outgoingCalls are also broken (they depend on prepareCallHierarchy).
Beyond that, language servers like Intelephense (PHP) expose many more capabilities that would be extremely valuable for code navigation and refactoring — but there's no way to use them because the LSP tool doesn't expose those operations.
This significantly limits Claude's ability to safely refactor code. For example, without rename, Claude must manually find-and-replace symbol names across files, which is error-prone compared to an LSP-powered rename that understands scope and semantics.
Proposed Solution
1. Fix already-declared operations
prepareCallHierarchy, incomingCalls, and outgoingCalls are already listed as supported operations in the LSP tool, but the plugin infrastructure returns "Unhandled method." These should be wired through to the language server.
2. Add new LSP operations
The following standard LSP protocol methods would be highly valuable:
| Operation | LSP Method | Why it matters |
|---|---|---|
| rename | textDocument/rename | Safe, scope-aware symbol renaming across files — the #1 most impactful missing feature for refactoring |
| codeAction | textDocument/codeAction | Quick fixes, auto-imports, extract method/variable — many language servers provide powerful automated refactorings |
| typeHierarchy | textDocument/prepareTypeHierarchy + supertypes/subtypes | Navigate class inheritance chains — essential for understanding OOP codebases |
| diagnostics | textDocument/publishDiagnostics | Get real-time errors/warnings after edits without running external tools |
| signatureHelp | textDocument/signatureHelp | Parameter info when writing function calls — helps Claude write correct code |
3. Ensure premium language server features work
Many language servers (e.g., Intelephense for PHP) have free and premium tiers. Premium features like goToImplementation, rename, typeHierarchy, and codeAction only activate when a licence key is provided. The current plugin system doesn't support passing initializationOptions to the language server, so there's no way to activate these features.
Workaround we found: Intelephense reads $HOME/intelephense/licence.txt automatically, but this only works because Intelephense has this fallback behavior. Other language servers may not. Supporting initializationOptions in the plugin config (or in .claude/settings.json) would solve this generically.
Alternative Solutions
- For call hierarchy: Using
findReferences+ manually tracing callers works, but is slow, token-expensive, and error-prone in large codebases. - For rename: Using Grep + Edit across files works, but doesn't understand scope — it can rename unrelated symbols with the same name or miss dynamically referenced ones.
- For type hierarchy: Reading files manually to trace
extends/implementschains works but is tedious for deep hierarchies.
Priority
High - Significant impact on productivity
The LSP tool is one of Claude Code's most powerful features for working with typed languages. Expanding it to cover more LSP methods would make Claude significantly more capable at navigating and refactoring large codebases safely.
Feature Category
Developer tools/SDK
Use Case Example
Scenario: Renaming a repository interface method in a Symfony project
- I ask Claude to rename
SectionRepositoryInterface::getByEvent()tofindByEventId() - Currently, Claude must: Grep for the method name → read each file → manually edit each occurrence → hope it didn't miss any or rename an unrelated method with the same name
- With
renamesupport, Claude would: callLSP renameon the symbol → get back all precise edits across the codebase → apply them atomically - This is safer, faster, and uses fewer tokens
Scenario: Understanding a class hierarchy
- I ask Claude how
Offerentity subtypes are structured - Currently, Claude must Grep for
extends Offeracross the codebase and manually piece together the hierarchy - With
typeHierarchy, one LSP call would return the full inheritance tree
Scenario: Tracing callers of a method
- I ask Claude "what calls
OfferService::create()?" incomingCallsshould answer this in one call, but currently fails with "Unhandled method"- Claude falls back to
findReferencesand manually filters for call sites, which is slower and less precise
Additional Context
Tested with: Intelephense 1.x (PHP LSP) with premium licence on Linux. The goToImplementation operation works correctly after activating the premium licence, confirming the language server supports these features — it's the Claude Code LSP infrastructure that's the bottleneck.
LSP specification reference: All proposed methods are part of the LSP 3.17 specification and are widely supported by mature language servers (TypeScript, PHP/Intelephense, Python/Pyright, Go/gopls, Rust/rust-analyzer, etc.).
This issue has 5 comments on GitHub. Read the full discussion on GitHub ↗