LSPTool: Language Service Access

The significance of LSPTool lies not in "adding yet another search tool", but in:

Claude Code is no longer limited to text search; it can invoke a language server for semantic-level understanding.

This enables it to:

• go to definition
• find references
• hover
• document symbol
• call hierarchy

In other words, it already approaches the "code intelligence" layer found in an IDE.

tools/LSPTool/LSPTool.ts:

const inputSchema = z.strictObject({
  operation: z.enum([
    'goToDefinition',
    'findReferences',
    'hover',
    'documentSymbol',
    'workspaceSymbol',
    'goToImplementation',
    'prepareCallHierarchy',
    'incomingCalls',
    'outgoingCalls',
  ]),
  filePath: z.string(),
  line: z.number().int().positive(),
  character: z.number().int().positive(),
})

This shows that LSPTool is not a single API, but a unified entry point for an entire suite of code intelligence operations.

Model needs semantic-level understanding > LSPTool > Check file & permissions > Connect to LSP manager > Issue requests for definition/references/hover, etc. > Format output and return to main thread.

The essential difference between the two is:

• GrepTool: string matching
• LSPTool: language semantics

For example, when looking up a function definition:

• GrepTool might match comments, strings, or similar names
• LSPTool can truly ask the language server "where is this symbol defined"

So it resembles IDE capabilities more closely than terminal search capabilities.

In the source code, beyond just checking parameter formats, it also verifies:

• whether the file exists
• whether the path is a regular file
• large file limits
• whether the current LSP is connected

This shows it's not a "try to call it if possible" utility, but a fairly rigorous entry point for semantic operations.

The most noteworthy aspect of LSPTool is:

Claude Code is no longer satisfied with text search; it has officially integrated the language server capabilities from an IDE into its agent toolchain.