LSP-MCP
README.md
# LSP-MCP
Minimal MCP server that bridges any Language Server Protocol (LSP) server to AI agents (e.g. GitHub Copilot CLI). Exposes diagnostics (errors, warnings, info) as lightweight tool calls.
## Tools
Tools are generated per server entry, prefixed by the config key:
| Tool pattern | Description |
|------|-------------|
| `{prefix}_get_errors` | Compilation errors for a file (or all open files) |
| `{prefix}_get_warnings` | Warnings for a file |
| `{prefix}_get_info` | Info/hint diagnostics (style rules, analyzers) |
| `lsp_status` | All LSP servers' state for debugging |
Example with `"cs"` prefix: `cs_get_errors`, `cs_get_warnings`, `cs_get_info`
## Setup
```bash
pip install -e .
```
## Configuration
Create `.github/lsp.json` in your workspace root. Each key is the **tool prefix** — keep it short:
```json
{
"lspServers": {
"cs": {
"command": "path/to/Microsoft.CodeAnalysis.LanguageServer.exe",
"args": ["--stdio", "--autoLoadProjects"],
"fileExtensions": {".cs": "csharp"}
}
}
}
```
Multiple servers generate prefixed tools automatically:
```json
{
"lspServers": {
"cs": { "command": "...", "args": [...], "fileExtensions": {".cs": "csharp"} },
"py": { "command": "pyright-langserver", "args": ["--stdio"], "fileExtensions": {".py": "python"} }
}
}
```
This exposes: `cs_get_errors`, `cs_get_warnings`, `py_get_errors`, `py_get_warnings`, etc.
The `fileExtensions` map tells the server which `languageId` to send in `textDocument/didOpen`. Common extensions (`.py`, `.ts`, `.go`, `.rs`, etc.) are detected automatically if omitted.
## Usage with Copilot CLI
Add to `~/.copilot/mcp-config.json`:
```json
{
"mcpServers": {
"lsp": {
"type": "stdio",
"command": "python",
"args": ["-m", "lsp_mcp", "--workspace", "/path/to/your/project"]
}
}
}
```
## CLI Options
```
lsp-mcp [--workspace PATH]
```
- `--workspace`, `-w`: Workspace root containing `.github/lsp.json` (defaults to cwd)
## How It Works
1. Reads `.github/lsp.json` to find the LSP server command
2. Spawns the language server with `--stdio` and performs the LSP initialize handshake
3. On tool call: opens the file, pulls diagnostics via `textDocument/diagnostic`, filters by severity
4. Falls back to push diagnostics (`publishDiagnostics`) if pull returns empty
5. Returns concise JSON with line, column, severity, message, and diagnostic code
TDQS
A3.8/5.0
Scored across 1 tool
Disambiguation5/5
With only one tool, there is no possibility of confusion between tools. The tool's purpose is clear and singular.
Naming Consistency5/5
The single tool name 'lsp_status' follows a consistent verb_noun pattern, which is clear and predictable.
Tool Count2/5
The server's name suggests broader LSP interaction capabilities, but it exposes only a single tool for status. This is too few tools for the implied scope, limiting its usefulness.
Completeness1/5
The server only provides a status check, lacking essential LSP operations like initialization, document management, or diagnostics retrieval. The tool surface is severely incomplete for any real LSP interaction.
Maintenance
ActivityInactive
ResponsivenessNo issues