[FEATURE] LSP tool: add query parameter for workspaceSymbol operation

Resolved 💬 3 comments Opened Feb 28, 2026 by Drakonian Closed Feb 28, 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's workspaceSymbol operation is non-functional because the tool schema has no way to pass the required query string to the language server.

Per the LSP specification, workspace/symbol requires a query parameter — a text string to search for (e.g. "Customer", "HttpClient", "UserService"). However, Claude Code's LSP tool defines all operations with the same parameter set:

All operations require:
  filePath: The file to operate on
  line: The line number (1-based)
  character: The character offset (1-based)

There is no query field. When Claude invokes workspaceSymbol, the language server receives {"query": ""} and returns zero results, since it has nothing to search for.

This affects every language that has an LSP plugin, not just one ecosystem. Any developer using Claude Code with LSP who wants to discover symbols by name hits this limitation. The workspaceSymbol operation is listed in the tool description and appears functional, but silently returns nothing.

Current Behavior

❯ Find the UserService class across the workspace

● LSP(operation: "workspaceSymbol", file: "src/handler.ts")
  ⎿  Error: workspace/symbol returned 0 results

The language server never receives a search term. No matter what file, line, or character is provided, the result is always empty or an error.

This has been independently confirmed by multiple LSP plugin authors:

José Valim (creator of Elixir) also noted this design limitation:

"most LSP APIs are awkward for agentic usage because they require passing file:line:column, you can't simply ask 'tell me where Foo#bar is defined'" — source

Proposed Solution

Add an optional query parameter to the LSP tool, used when operation is workspaceSymbol:

LSP({
  operation: "workspaceSymbol",
  query: "UserService",       // ← new parameter
  filePath: "src/handler.ts", // used to identify which LSP server to query
  line: 1,                    // ignored for this operation
  character: 1                // ignored for this operation
})

The query value is passed directly as the query field in the workspace/symbol LSP request. filePath is still needed to determine which language server to route the request to (based on file extension → server mapping).

Alternative Solutions

_No response_

Priority

Critical - Blocking my work

Feature Category

CLI commands and flags

Use Case Example

workspaceSymbol is the only LSP operation that lets Claude discover objects by name without already knowing their file location. Without it, Claude cannot answer questions like:

  • "Find the UserService class" (TypeScript/Java/C#)
  • "Where is the Customer Card page defined?" (AL / Business Central)
  • "Show me all repository interfaces" (any language)

This forces Claude to fall back to grep, which:

  1. Has no semantic understanding — matches string literals, comments, and unrelated identifiers with the same name
  2. Cannot search inside compiled dependency symbols — many language servers index external libraries and SDKs that exist only as binary packages, not as searchable source files. grep can never find these.
  3. Is significantly slower on large workspaces compared to a language server's pre-built symbol index

Point 2 is especially critical. Many ecosystems rely on SDK symbol packages that the language server indexes but that don't exist as plain text files on disk. Without workspaceSymbol, Claude has zero visibility into these platform APIs — it can only work with the user's own source files.

Additional Context

_No response_

View original on GitHub ↗

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