LSP MCP Server
An MCP (Model Context Protocol) server for interacting with LSP (Language Server Protocol) interface. This server acts as a bridge that allows LLMs to query LSP Hover and Completion providers.
Overview
The MCP Server works by:
- Starting an LSP client that connects to a LSP server
- Exposing MCP tools that send requests to the LSP server
- Returning the results in a format that LLMs can understand and use
This enables LLMs to utilize LSPs for more accurate code suggestions.
Configuration:
{
"mcpServers": {
"lsp-mcp": {
"type": "stdio",
"command": "npx",
"args": [
"tritlo/lsp-mcp",
"<language-id>",
"<path-to-lsp>",
"<lsp-args>"
]
}
}
}
Features
MCP Tools
get_info_on_location: Get hover information at a specific location in a fileget_completions: Get completion suggestions at a specific location in a fileget_code_actions: Get code actions for a specific range in a fileopen_document: Open a file in the LSP server for analysisclose_document: Close a file in the LSP serverget_diagnostics: Get diagnostic messages (errors, warnings) for open filesstart_lsp: Start the LSP server with a specified root directoryrestart_lsp_server: Restart the LSP server without restarting the MCP serverset_log_level: Change the server's logging verbosity level at runtime
MCP Resources
lsp-diagnostics://resources for accessing diagnostic messages with real-time updates via subscriptionslsp-hover://resources for retrieving hover information at specific file locationslsp-completions://resources for getting code completion suggestions at specific positions
Additional Features
- Comprehensive logging system with multiple severity levels
- Colorized console output for better readability
- Runtime-configurable log level
- Detailed error handling and reporting
- Simple command-line interface
Prerequisites
- Node.js (v16 or later)
- npm
For the demo server:
- GHC (8.10 or later)
- Cabal (3.0 or later)
Installation
Building the MCP Server
-
Clone this repository:
git clone https://github.com/your-username/lsp-mcp.git cd lsp-mcp -
Install dependencies:
npm install -
Build the MCP server:
npm run build
Testing
The project includes integration tests for the TypeScript LSP support. These tests verify that the LSP-MCP server correctly handles LSP operations like hover information, completions, diagnostics, and code actions.
Running Tests
To run the TypeScript LSP tests:
npm test
or specifically:
npm run test:typescript
Test Coverage
The tests verify the following functionality:
- Initializing the TypeScript LSP with a mock project
- Opening TypeScript files for analysis
- Getting hover information for functions and types
- Getting code completion suggestions
- Getting diagnostic error messages
- Getting code actions for errors
The test project is located in test/ts-project/ and contains TypeScript files with intentional errors to test diagnostic feedback.
Usage
Run the MCP server by providing the path to the LSP executable and any arguments to pass to the LSP server:
npx tritlo/lsp-mcp <language> /path/to/lsp [lsp-args...]
For example:
npx tritlo/lsp-mcp haskell /usr/bin/haskell-language-server-wrapper lsp
Important: Starting the LSP Server
With version 0.2.0 and later, you must explicitly start the LSP server by calling the start_lsp tool before using any LSP functionality. This ensures proper initialization with the correct root directory, which is especially important when using tools like npx:
{
"tool": "start_lsp",
"arguments": {
"root_dir": "/path/to/your/project"
}
}
Logging
The server includes a comprehensive logging system with 8 severity levels:
debug: Detailed information for debugging purposesinfo: General informational messages about system operationnotice: Significant operational eventswarning: Potential issues that might need attentionerror: Error conditions that affect operation but don't halt the systemcritical: Critical conditions requiring immediate attentionalert: System is in an unstable stateemergency: System is unusable
By default, logs are sent to:
- Console output with color-coding for better readability
- MCP notifications to the client (via the
notifications/messagemethod)
Viewing Debug Logs
For detailed debugging, you can:
-
Use the
claude --mcp-debugflag when running Claude to see all MCP traffic between Claude and the server:claude --mcp-debug -
Change the log level at runtime using the
set_log_leveltool:{ "tool": "set_log_level", "arguments": { "level": "debug" } }
The default log level is info, which shows moderate operational detail while filtering out verbose debug messages.
API
The server provides the following MCP tools:
get_info_on_location
Gets hover information at a specific location in a file.
Parameters:
file_path: Path to the filelanguage_id: The programming language the file is written in (e.g., "haskell")line: Line numbercolumn: Column position
Example:
{
"tool": "get_info_on_location",
"arguments": {
"file_path": "/path/to/your/file",
"language_id": "haskell",
"line": 3,
"column": 5
}
}
get_completions
Gets completion suggestions at a specific location in a file.
Parameters:
file_path: Path to the filelanguage_id: The programming language the file is written in (e.g., "haskell")line: Line numbercolumn: Column position
Example:
{
"tool": "get_completions",
"arguments": {
"file_path": "/path/to/your/file",
"language_id": "haskell",
"line": 3,
"column": 10
}
}
get_code_actions
Gets code actions for a specific range in a file.
Parameters:
file_path: Path to the filelanguage_id: The programming language the file is written in (e.g., "haskell")start_line: Start line numberstart_column: Start column positionend_line: End line numberend_column: End column position
Example:
{
"tool": "get_code_actions",
"arguments": {
"file_path": "/path/to/your/file",
"language_id": "haskell",
"start_line": 3,
"start_column": 5,
"end_line": 3,
"end_column": 10
}
}
start_lsp
Starts the LSP server with a specified root directory. This must be called before using any other LSP-related tools.
Parameters:
root_dir: The root directory for the LSP server (absolute path recommended)
Example:
{
"tool": "start_lsp",
"arguments": {
"root_dir": "/path/to/your/project"
}
}
restart_lsp_server
Restarts the LSP server process without restarting the MCP server. This is useful for recovering from LSP server issues or for applying changes to the LSP server configuration.
Parameters:
root_dir: (Optional) The root directory for the LSP server. If provided, the server will be initialized with this directory after restart.
Example without root_dir (uses previously set root directory):
{
"tool": "restart_lsp_server",
"arguments": {}
}
Example with root_dir:
{
"tool": "restart_lsp_server",
"arguments": {
"root_dir": "/path/to/your/project"
}
}
open_document
Opens a file in the LSP server for analysis. This must be called before accessing diagnostics or performing other operations on the file.
Parameters:
file_path: Path to the file to openlanguage_id: The programming language the file is written in (e.g., "haskell")
Example:
{
"tool": "open_document",
"arguments": {
"file_path": "/path/to/your/file",
"language_id": "haskell"
}
}
close_document
Closes a file in the LSP server when you're done working with it. This helps manage resources and cleanup.
Parameters:
file_path: Path to the file to close
Example:
{
"tool": "close_document",
"arguments": {
"file_path": "/path/to/your/file"
}
}
get_diagnostics
Gets diagnostic messages (errors, warnings) for one or all open files.
Parameters:
file_path: (Optional) Path to the file to get diagnostics for. If not provided, returns diagnostics for all open files.
Example for a specific file:
{
"tool": "get_diagnostics",
"arguments": {
"file_path": "/path/to/your/file"
}
}
Example for all open files:
{
"tool": "get_diagnostics",
"arguments": {}
}
set_log_level
Sets the server's logging level to control verbosity of log messages.
Parameters:
level: The logging level to set. One of:debug,info,notice,warning,error,critical,alert,emergency.
Example:
{
"tool": "set_log_level",
"arguments": {
"level": "debug"
}
}
MCP Resources
In addition to tools, the server provides resources for accessing LSP features including diagnostics, hover information, and code completions:
Diagnostic Resources
The server exposes diagnostic information via the lsp-diagnostics:// resource scheme. These resources can be subscribed to for real-time updates when diagnostics change.
Resource URIs:
lsp-diagnostics://- Diagnostics for all open fileslsp-diagnostics:///path/to/file- Diagnostics for a specific file
Important: Files must be opened using the open_document tool before diagnostics can be accessed.
Hover Information Resources
The server exposes hover information via the lsp-hover:// resource scheme. This allows you to get information about code elements at specific positions in files.
Resource URI format:
lsp-hover:///path/to/file?line={line}&column={column}&language_id={language_id}
Parameters:
line: Line number (1-based)column: Column position (1-based)language_id: The programming language (e.g., "haskell")
Example:
lsp-hover:///home/user/project/src/Main.hs?line=42&column=10&language_id=haskell
Code Completion Resources
The server exposes code completion suggestions via the lsp-completions:// resource scheme. This allows you to get completion candidates at specific positions in files.
Resource URI format:
lsp-completions:///path/to/file?line={line}&column={column}&language_id={language_id}
Parameters:
line: Line number (1-based)column: Column position (1-based)language_id: The programming language (e.g., "haskell")
Example:
lsp-completions:///home/user/project/src/Main.hs?line=42&column=10&language_id=haskell
Listing Available Resources
To discover available resources, use the MCP resources/list endpoint. The response will include all available resources for currently open files, including:
- Diagnostics resources for all open files
- Hover information templates for all open files
- Code completion templates for all open files
Subscribing to Resource Updates
Diagnostic resources support subscriptions to receive real-time updates when diagnostics change (e.g., when files are modified and new errors or warnings appear). Subscribe to diagnostic resources using the MCP resources/subscribe endpoint.
Note: Hover and completion resources don't support subscriptions as they represent point-in-time queries.
Working with Resources vs. Tools
You can choose between two approaches for accessing LSP features:
- Tool-based approach: Use the
get_diagnostics,get_info_on_location, andget_completionstools for a simple, direct way to fetch information. - Resource-based approach: Use the
lsp-diagnostics://,lsp-hover://, andlsp-completions://resources for a more RESTful approach.
Both approaches provide the same data in the same format and enforce the same requirement that files must be opened first.
Troubleshooting
- If the server fails to start, make sure the path to the LSP executable is correct
- Check the log file (if configured) for detailed error messages
License
MIT License
Extensions
The LSP-MCP server supports language-specific extensions that enhance its capabilities for different programming languages. Extensions can provide:
- Custom LSP-specific tools and functionality
- Language-specific resource handlers and templates
- Specialized prompts for language-related tasks
- Custom subscription handlers for real-time data
Available Extensions
Currently, the following extensions are available:
- Haskell: Provides specialized prompts for Haskell development, including typed-hole exploration guidance
Using Extensions
Extensions are loaded automatically when you specify a language ID when starting the server:
npx tritlo/lsp-mcp haskell /path/to/haskell-language-server-wrapper lsp
Extension Namespacing
All extension-provided features are namespaced with the language ID. For example, the Haskell extension's typed-hole prompt is available as haskell.typed-hole-use.
Creating New Extensions
To create a new extension:
-
Create a new TypeScript file in
src/extensions/named after your language (e.g.,typescript.ts) -
Implement the Extension interface with any of these optional functions:
getToolHandlers(): Provide custom tool implementationsgetToolDefinitions(): Define custom tools in the MCP APIgetResourceHandlers(): Implement custom resource handlersgetSubscriptionHandlers(): Implement custom subscription handlersgetUnsubscriptionHandlers(): Implement custom unsubscription handlersgetResourceTemplates(): Define custom resource templatesgetPromptDefinitions(): Define custom prompts for language tasksgetPromptHandlers(): Implement custom prompt handlers
-
Export your implementation functions
The extension system will automatically load your extension when the matching language ID is specified.
Acknowledgments
- HLS team for the Language Server Protocol implementation
- Anthropic for the Model Context Protocol specification
