[FEATURE] Expand LSP tool to support more protocol methods (call hierarchy, rename, code actions, type hierarchy)

Resolved 💬 5 comments Opened Mar 9, 2026 by akserikawa Closed Apr 29, 2026

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/implements chains 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

  1. I ask Claude to rename SectionRepositoryInterface::getByEvent() to findByEventId()
  2. 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
  3. With rename support, Claude would: call LSP rename on the symbol → get back all precise edits across the codebase → apply them atomically
  4. This is safer, faster, and uses fewer tokens

Scenario: Understanding a class hierarchy

  1. I ask Claude how Offer entity subtypes are structured
  2. Currently, Claude must Grep for extends Offer across the codebase and manually piece together the hierarchy
  3. With typeHierarchy, one LSP call would return the full inheritance tree

Scenario: Tracing callers of a method

  1. I ask Claude "what calls OfferService::create()?"
  2. incomingCalls should answer this in one call, but currently fails with "Unhandled method"
  3. Claude falls back to findReferences and 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.).

View original on GitHub ↗

This issue has 5 comments on GitHub. Read the full discussion on GitHub ↗