### Complete LSP MCP Workflow Example in JavaScript

Source: https://context7.com/tritlo/lsp-mcp/llms.txt

This JavaScript example demonstrates the complete workflow of using the LSP MCP client to interact with a language server. It covers starting the server, connecting the client, initializing the LSP, opening files, fetching diagnostics, getting hover information, retrieving code completions, and applying code actions. It also includes error handling and server restart logic.

```javascript
import { Client } from '@modelcontextprotocol/sdk/client/index.js';
import { spawn } from 'child_process';

// Start MCP server process
const serverProcess = spawn('npx', [
  'tritlo/lsp-mcp',
  'typescript',
  '/usr/bin/typescript-language-server',
  '--stdio'
], { stdio: ['pipe', 'pipe', 'pipe'] });

// Create MCP client
const client = new Client(
  { name: "my-app", version: "1.0.0" },
  { capabilities: { tools: true, resources: true, logging: true } }
);

// Connect to server
await client.connect(customTransport);

try {
  // Step 1: Initialize LSP with project root
  await client.callTool({
    name: "start_lsp",
    arguments: { root_dir: "/home/user/myproject" }
  });

  // Step 2: Open files for analysis
  const filePath = "/home/user/myproject/src/index.ts";
  await client.callTool({
    name: "open_document",
    arguments: {
      file_path: filePath,
      language_id: "typescript"
    }
  });

  // Step 3: Check for errors
  const diagnostics = await client.callTool({
    name: "get_diagnostics",
    arguments: { file_path: filePath }
  });

  const errors = JSON.parse(diagnostics.content[0].text);
  console.log(`Found ${Object.values(errors)[0].length} diagnostics`);

  // Step 4: Get hover information
  const hover = await client.callTool({
    name: "get_info_on_location",
    arguments: {
      file_path: filePath,
      language_id: "typescript",
      line: 10,
      column: 5
    }
  });
  console.log("Hover info:", hover.content[0].text);

  // Step 5: Get completions
  const completions = await client.callTool({
    name: "get_completions",
    arguments: {
      file_path: filePath,
      language_id: "typescript",
      line: 15,
      column: 8
    }
  });
  const suggestions = JSON.parse(completions.content[0].text);
  console.log(`${suggestions.length} completion suggestions available`);

  // Step 6: Get code actions for a range with errors
  const actions = await client.callTool({
    name: "get_code_actions",
    arguments: {
      file_path: filePath,
      language_id: "typescript",
      start_line: 20,
      start_column: 1,
      end_line: 20,
      end_column: 30
    }
  });
  const fixes = JSON.parse(actions.content[0].text);
  console.log("Available fixes:", fixes.map(f => f.title));

  // Step 7: Clean up
  await client.callTool({
    name: "close_document",
    arguments: { file_path: filePath }
  });

} catch (error) {
  console.error("Error:", error);

  // Restart LSP if needed
  await client.callTool({
    name: "restart_lsp_server",
    arguments: {}
  });
} finally {
  serverProcess.kill('SIGINT');
}

```

--------------------------------

### Haskell Extension Example in LSP-MCP Server Startup

Source: https://github.com/tritlo/lsp-mcp/blob/main/README.md

Demonstrates how to start the LSP-MCP server with the Haskell extension enabled, specifying the path to the Haskell language server wrapper. Extensions are loaded based on the language ID provided.

```bash
npx tritlo/lsp-mcp haskell /path/to/haskell-language-server-wrapper lsp
```

--------------------------------

### start_lsp

Source: https://github.com/tritlo/lsp-mcp/blob/main/README.md

Initializes and starts the LSP server for a given project directory.

```APIDOC
## POST /tools/start_lsp

### Description
Starts the LSP server with a specified root directory. This must be called before using any other LSP-related tools.

### Method
POST

### Endpoint
/tools/start_lsp

### Parameters
#### Request Body
- **tool** (string) - Required - Must be 'start_lsp'
- **arguments** (object) - Required - Contains the parameters for the tool
  - **root_dir** (string) - Required - The root directory for the LSP server (absolute path recommended)

### Request Example
```json
{
  "tool": "start_lsp",
  "arguments": {
    "root_dir": "/path/to/your/project"
  }
}
```

### Response
#### Success Response (200)
- **result** (string) - A confirmation message indicating the LSP server has started.

#### Response Example
```json
{
  "tool": "start_lsp",
  "result": "LSP server started successfully for /path/to/your/project."
}
```
```

--------------------------------

### CLI Usage for Starting MCP Server

Source: https://github.com/tritlo/lsp-mcp/blob/main/README.md

This command demonstrates how to run the MCP server from the command line. It requires specifying the language, the path to the LSP executable, and any additional arguments for the LSP server. An example for Haskell is provided.

```shell
npx tritlo/lsp-mcp <language> /path/to/lsp [lsp-args...]

```

```shell
npx tritlo/lsp-mcp haskell /usr/bin/haskell-language-server-wrapper lsp
```

--------------------------------

### Start LSP Server via CLI and MCP Configuration

Source: https://context7.com/tritlo/lsp-mcp/llms.txt

Demonstrates how to start the LSP MCP Server using the command line interface (CLI) and how to configure it within MCP settings. This is the initial step required before utilizing other LSP functionalities.

```bash
npx tritlo/lsp-mcp typescript /usr/bin/typescript-language-server --stdio
```

```json
{
  "mcpServers": {
    "lsp-mcp": {
      "type": "stdio",
      "command": "npx",
      "args": ["tritlo/lsp-mcp", "typescript", "/usr/bin/typescript-language-server", "--stdio"]
    }
  }
}
```

--------------------------------

### Start LSP Server

Source: https://context7.com/tritlo/lsp-mcp/llms.txt

Initializes the LSP server with a project root directory. This is a prerequisite for using other LSP functionalities.

```APIDOC
## Start LSP Server

### Description
Initializes the LSP server with a project root directory. This is a prerequisite for using other LSP functionalities.

### Method
`tool_call` or Configuration

### Endpoint
N/A

### Parameters
#### Tool Call Arguments
- **root_dir** (string) - Required - The root directory of the project to be analyzed.

### Request Example (Tool Call)
```javascript
const initResult = await client.callTool({
  name: "start_lsp",
  arguments: {
    root_dir: "/home/user/my-typescript-project"
  }
});
```

### Response
#### Success Response
- **content** (array) - Contains a text message indicating successful startup.
  - **type** (string) - Type of content, expected to be 'text'.
  - **text** (string) - Confirmation message.

#### Response Example
```json
{
  "content": [{
    "type": "text",
    "text": "LSP server successfully started with root directory: /home/user/my-typescript-project"
  }]
}
```
```

--------------------------------

### Get Hover Information using Tool Call and Resource Access

Source: https://context7.com/tritlo/lsp-mcp/llms.txt

Provides examples for retrieving hover information (documentation, type info) at specific code locations. It demonstrates using both a tool call with file path, line, and column, and accessing information via a resource URI.

```javascript
// Get hover info for a function call
const hoverResult = await client.callTool({
  name: "get_info_on_location",
  arguments: {
    file_path: "/home/user/project/src/index.ts",
    language_id: "typescript",
    line: 42,
    column: 10
  }
});

// Expected response:
// {
//   content: [{
//     type: "text",
//     text: "```typescript\nfunction calculateTotal(items: Item[]): number\n```\nCalculates the total price of all items in the cart.\n\n@param items - Array of shopping cart items\n@returns The sum of all item prices"
//   }]
// }

// Use resource-based access for hover info
const hoverResource = await client.readResource({
  uri: "lsp-hover:///home/user/project/src/index.ts?line=42&column=10&language_id=typescript"
});

// Resource response format:
// {
//   contents: [{
//     type: "text",
//     text: "function calculateTotal(items: Item[]): number",
//     uri: "lsp-hover:///home/user/project/src/index.ts?line=42&column=10&language_id=typescript"
//   }]
// }
```

--------------------------------

### JSON for Explicitly Starting LSP Server

Source: https://github.com/tritlo/lsp-mcp/blob/main/README.md

This JSON object is used to explicitly start the LSP server, which is required for versions 0.2.0 and later. It ensures proper initialization by specifying the root directory of the project, especially when using tools like npx.

```json
{
  "tool": "start_lsp",
  "arguments": {
    "root_dir": "/path/to/your/project"
  }
}
```

--------------------------------

### Language-Specific Extensions with LSP-MCP (Haskell Example)

Source: https://context7.com/tritlo/lsp-mcp/llms.txt

Access specialized features for supported languages through the extension system. This example demonstrates using the Haskell typed-hole prompt to synthesize code.

```javascript
// Haskell extension: typed-hole prompt
const prompts = await client.listPrompts();
// Includes: "haskell.typed-hole-use" prompt

const typedHolePrompt = await client.getPrompt({
  name: "haskell.typed-hole-use",
  arguments: {}
});

// Response provides guidance:
// {
//   messages: [
//     {
//       role: "user",
//       content: {
//         type: "text",
//         text: "Please use a typed-hole to synthesize replacement code..."
//       }
//     }
//   ]
// }

// Use typed hole workflow in Haskell:
// 1. Replace expression with _mcp_typed_hole
// 2. Get code actions at the hole location
const holeActions = await client.callTool({
  name: "get_code_actions",
  arguments: {
    file_path: "/project/src/Main.hs",
    language_id: "haskell",
    start_line: 15,
    start_column: 10,
    end_line: 15,
    end_column: 25
  }
});
// 3. Examine available identifiers from code action labels
```

--------------------------------

### Shell Commands for Building and Testing

Source: https://github.com/tritlo/lsp-mcp/blob/main/README.md

These shell commands cover the essential steps for building the MCP server, including cloning the repository, installing Node.js dependencies, and compiling the project. It also includes commands for running integration tests for TypeScript LSP support.

```shell
git clone https://github.com/your-username/lsp-mcp.git
cd lsp-mcp
npm install
npm run build
```

```shell
npm test

```

```shell
npm run test:typescript
```

--------------------------------

### Get Hover Information

Source: https://context7.com/tritlo/lsp-mcp/llms.txt

Retrieves type information, documentation, and contextual details for a specific location within an opened file.

```APIDOC
## Get Hover Information

### Description
Retrieves type information, documentation, and contextual details for a specific location within an opened file.

### Method
`tool_call` or `readResource`

### Endpoint
N/A (for `tool_call`)
`lsp-hover://` URI (for `readResource`)

### Parameters
#### Tool Call Arguments
- **file_path** (string) - Required - The path to the file containing the location.
- **language_id** (string) - Required - The language identifier of the file.
- **line** (integer) - Required - The line number of the location (0-based).
- **column** (integer) - Required - The column number of the location (0-based).

#### Resource URI Parameters
- **uri** (string) - Required - The resource URI in the format `lsp-hover://<file_path>?line=<line>&column=<column>&language_id=<language_id>`.

### Request Example (Tool Call)
```javascript
const hoverResult = await client.callTool({
  name: "get_info_on_location",
  arguments: {
    file_path: "/home/user/project/src/index.ts",
    language_id: "typescript",
    line: 42,
    column: 10
  }
});
```

### Request Example (Resource)
```javascript
const hoverResource = await client.readResource({
  uri: "lsp-hover:///home/user/project/src/index.ts?line=42&column=10&language_id=typescript"
});
```

### Response
#### Success Response (Tool Call)
- **content** (array) - Contains the hover information.
  - **type** (string) - Type of content, expected to be 'text'.
  - **text** (string) - The hover information, often in markdown format.

#### Success Response (Resource)
- **contents** (array) - Contains the hover information.
  - **type** (string) - Type of content, expected to be 'text'.
  - **text** (string) - The hover information, often in markdown format.
  - **uri** (string) - The URI of the resource.

#### Response Example (Tool Call)
```json
{
  "content": [{
    "type": "text",
    "text": "```typescript\nfunction calculateTotal(items: Item[]): number\n```\nCalculates the total price of all items in the cart.\n\n@param items - Array of shopping cart items\n@returns The sum of all item prices"
  }]
}
```

#### Response Example (Resource)
```json
{
  "contents": [{
    "type": "text",
    "text": "function calculateTotal(items: Item[]): number",
    "uri": "lsp-hover:///home/user/project/src/index.ts?line=42&column=10&language_id=typescript"
  }]
}
```
```

--------------------------------

### Get Code Completions - JSON

Source: https://github.com/tritlo/lsp-mcp/blob/main/README.md

Fetches code completion suggestions for a given position in a file. Requires file path, language ID, and line/column numbers. Assists in writing code faster by providing relevant suggestions.

```json
{
  "tool": "get_completions",
  "arguments": {
    "file_path": "/path/to/your/file",
    "language_id": "haskell",
    "line": 3,
    "column": 10
  }
}
```

--------------------------------

### Get Code Completions in TypeScript

Source: https://context7.com/tritlo/lsp-mcp/llms.txt

Retrieves intelligent code completion suggestions for a specified file and cursor position. It supports both direct tool calls and resource-based access via URIs. Dependencies include a client object with `callTool` and `readResource` methods. Input is a file path, language ID, line, and column; output is a list of completion items.

```javascript
const completionsResult = await client.callTool({
  name: "get_completions",
  arguments: {
    file_path: "/home/user/project/src/app.ts",
    language_id: "typescript",
    line: 15,
    column: 8
  }
});

const completionUri = "lsp-completions:///home/user/project/src/app.ts?line=15&column=8&language_id=typescript";
const completions = await client.readResource({ uri: completionUri });
const items = JSON.parse(completions.contents[0].text);
console.log(`Found ${items.length} completion suggestions`);
```

--------------------------------

### Get Code Actions - JSON

Source: https://github.com/tritlo/lsp-mcp/blob/main/README.md

Requests available code actions (e.g., refactoring, quick fixes) for a specified range within a file. Requires file path, language ID, and start/end line and column coordinates.

```json
{
  "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
  }
}
```

--------------------------------

### Get Hover Info - JSON

Source: https://github.com/tritlo/lsp-mcp/blob/main/README.md

Retrieves detailed hover information for a specific code location within a file. Requires the file path, language ID, and precise line and column numbers. Used for displaying contextual help or documentation.

```json
{
  "tool": "get_info_on_location",
  "arguments": {
    "file_path": "/path/to/your/file",
    "language_id": "haskell",
    "line": 3,
    "column": 5
  }
}
```

--------------------------------

### Get Diagnostics - JSON

Source: https://github.com/tritlo/lsp-mcp/blob/main/README.md

Retrieves diagnostic information (errors, warnings, etc.) for open files. Can be used to request diagnostics for a specific file or for all currently open files.

```json
{
  "tool": "get_diagnostics",
  "arguments": {
    "file_path": "/path/to/your/file"
  }
}
```

```json
{
  "tool": "get_diagnostics",
  "arguments": {}
}
```

--------------------------------

### Get Diagnostics for TypeScript Files

Source: https://context7.com/tritlo/lsp-mcp/llms.txt

Fetches code diagnostics (errors, warnings, etc.) for a given TypeScript file or all open files. It also allows subscribing to real-time diagnostic updates. The function relies on a client object with `callTool` and `subscribe` methods. Input is a file path or an empty object for all files; output is a map of file URIs to diagnostic lists. Real-time updates are received via `notifications/resources/update`.

```javascript
// Get diagnostics for a specific file
const diagnosticsResult = await client.callTool({
  name: "get_diagnostics",
  arguments: {
    file_path: "/home/user/project/src/broken.ts"
  }
});

// Get diagnostics for all open files
const allDiagnostics = await client.callTool({
  name: "get_diagnostics",
  arguments: {}
});

// Subscribe to real-time diagnostic updates
await client.subscribe({
  uri: "lsp-diagnostics:///home/user/project/src/app.ts"
});
```

--------------------------------

### Get Code Actions for TypeScript Errors and Refactorings

Source: https://context7.com/tritlo/lsp-mcp/llms.txt

Retrieves available code actions, such as quick fixes and refactorings, for specific code locations or ranges within a TypeScript file. This function uses the `get_code_actions` tool. Input includes file path, language ID, and start/end line/column coordinates. Output is a list of possible actions, which may include edits to the code.

```javascript
// Get code actions for a diagnostic error
const codeActionsResult = await client.callTool({
  name: "get_code_actions",
  arguments: {
    file_path: "/home/user/project/src/app.ts",
    language_id: "typescript",
    start_line: 10,
    start_column: 15,
    end_line: 10,
    end_column: 23
  }
});

// Get refactoring actions for a code selection
const refactorResult = await client.callTool({
  name: "get_code_actions",
  arguments: {
    file_path: "/home/user/project/src/app.ts",
    language_id: "typescript",
    start_line: 20,
    start_column: 1,
    end_line: 25,
    end_column: 1
  }
});
```

--------------------------------

### Working with Resources vs. Tools

Source: https://github.com/tritlo/lsp-mcp/blob/main/README.md

Choose between a tool-based approach (e.g., `get_diagnostics`) or a resource-based approach (e.g., `lsp-diagnostics://`) for accessing LSP features. Both require files to be opened first.

```APIDOC
## Working with Resources vs. Tools

You can choose between two approaches for accessing LSP features:

1. **Tool-based approach**: Use the `get_diagnostics`, `get_info_on_location`, and `get_completions` tools for a simple, direct way to fetch information.
2. **Resource-based approach**: Use the `lsp-diagnostics://`, `lsp-hover://`, and `lsp-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.
```

--------------------------------

### Initialize LSP Server via MCP Tool Call

Source: https://context7.com/tritlo/lsp-mcp/llms.txt

Shows how to initialize the LSP MCP Server programmatically using an MCP tool call. This method requires specifying the root directory of the project to be analyzed. The expected response confirms successful initialization.

```javascript
const initResult = await client.callTool({
  name: "start_lsp",
  arguments: {
    root_dir: "/home/user/my-typescript-project"
  }
});

// Expected response:
// {
//   content: [{
//     type: "text",
//     text: "LSP server successfully started with root directory: /home/user/my-typescript-project"
//   }]
// }
```

--------------------------------

### Listing Available Resources

Source: https://github.com/tritlo/lsp-mcp/blob/main/README.md

Discover all available resources, including diagnostics, hover, and code completion templates for open files, using the `resources/list` endpoint.

```APIDOC
## 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
```

--------------------------------

### JSON Configuration for MCP Servers

Source: https://github.com/tritlo/lsp-mcp/blob/main/README.md

This JSON configuration defines how to set up an MCP server, specifically for the 'lsp-mcp' type. It specifies the command to execute and arguments to pass, including placeholders for language ID, LSP path, and LSP arguments.

```json
{
  "mcpServers": {
    "lsp-mcp": {
      "type": "stdio",
      "command": "npx",
      "args": [
        "tritlo/lsp-mcp",
        "<language-id>",
        "<path-to-lsp>",
        "<lsp-args>"
      ]
    }
  }
}
```

--------------------------------

### Resource-Based Access Patterns with LSP-MCP

Source: https://context7.com/tritlo/lsp-mcp/llms.txt

Use URI-based resources as an alternative to tool calls for LSP features. This includes listing, accessing, subscribing, and unsubscribing from resources like diagnostics and hovers.

```javascript
// List all available resources
const resources = await client.listResources();

// Expected response includes:
// {
//   resources: [
//     {
//       uri: "lsp-diagnostics://",
//       name: "All diagnostics",
//       description: "Diagnostics for all open files",
//       subscribe: true
//     },
//     {
//       uri: "lsp-diagnostics:///project/src/app.ts",
//       name: "Diagnostics for app.ts",
//       description: "LSP diagnostics for /project/src/app.ts",
//       subscribe: true
//     },
//     {
//       uri: "lsp-hover:///project/src/app.ts?line={line}&column={column}&language_id={language_id}",
//       name: "Hover for app.ts",
//       description: "LSP hover information template for app.ts",
//       subscribe: false,
//       template: true
//     }
//   ]
// }

// Access all diagnostics via resource
const allDiags = await client.readResource({
  uri: "lsp-diagnostics://"
});

// Subscribe to diagnostic updates for all files
await client.subscribe({
  uri: "lsp-diagnostics://"
});

// Unsubscribe when done
await client.unsubscribe({
  uri: "lsp-diagnostics://"
});
```

--------------------------------

### get_completions

Source: https://github.com/tritlo/lsp-mcp/blob/main/README.md

Fetches code completion suggestions for a given location in a file.

```APIDOC
## POST /tools/get_completions

### Description
Gets completion suggestions at a specific location in a file.

### Method
POST

### Endpoint
/tools/get_completions

### Parameters
#### Request Body
- **tool** (string) - Required - Must be 'get_completions'
- **arguments** (object) - Required - Contains the parameters for the tool
  - **file_path** (string) - Required - Path to the file
  - **language_id** (string) - Required - The programming language the file is written in (e.g., "haskell")
  - **line** (integer) - Required - Line number
  - **column** (integer) - Required - Column position

### Request Example
```json
{
  "tool": "get_completions",
  "arguments": {
    "file_path": "/path/to/your/file",
    "language_id": "haskell",
    "line": 3,
    "column": 10
  }
}
```

### Response
#### Success Response (200)
- **result** (array) - A list of completion items returned by the LSP server.

#### Response Example
```json
{
  "tool": "get_completions",
  "result": [
    {
      "label": "myFunction",
      "kind": 12, // Function completion item kind
      "detail": "A sample function",
      "insertText": "myFunction()"
    }
  ]
}
```
```

--------------------------------

### Open Document for Analysis

Source: https://context7.com/tritlo/lsp-mcp/llms.txt

Opens a source file for LSP analysis, enabling tracking of diagnostics and other language features.

```APIDOC
## Open Document for Analysis

### Description
Opens a source file for LSP analysis, enabling tracking of diagnostics and other language features.

### Method
`tool_call`

### Endpoint
N/A

### Parameters
#### Tool Call Arguments
- **file_path** (string) - Required - The absolute path to the file to be opened.
- **language_id** (string) - Required - The language identifier for the file (e.g., 'typescript', 'python', 'haskell').

### Request Example (Tool Call)
```javascript
const openResult = await client.callTool({
  name: "open_document",
  arguments: {
    file_path: "/home/user/my-typescript-project/src/index.ts",
    language_id: "typescript"
  }
});
```

### Response
#### Success Response
- **content** (array) - Contains a text message indicating successful file opening.
  - **type** (string) - Type of content, expected to be 'text'.
  - **text** (string) - Confirmation message.

#### Response Example
```json
{
  "content": [{
    "type": "text",
    "text": "File successfully opened: /home/user/my-typescript-project/src/index.ts"
  }]
}
```
```

--------------------------------

### Code Completion Resources

Source: https://github.com/tritlo/lsp-mcp/blob/main/README.md

Obtain code completion suggestions at specific positions in files using the `lsp-completions://` resource scheme.

```APIDOC
## 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` (integer) - Required - Line number (1-based)
- `column` (integer) - Required - Column position (1-based)
- `language_id` (string) - Required - The programming language (e.g., "haskell")

### Example
```
lsp-completions:///home/user/project/src/Main.hs?line=42&column=10&language_id=haskell
```
```

--------------------------------

### Open Documents for LSP Analysis

Source: https://context7.com/tritlo/lsp-mcp/llms.txt

Illustrates how to open individual source files for LSP analysis and diagnostics tracking. It shows opening a single TypeScript file and then iterating through a list of files with different language IDs to open them sequentially.

```javascript
// Open a TypeScript file
const openResult = await client.callTool({
  name: "open_document",
  arguments: {
    file_path: "/home/user/my-typescript-project/src/index.ts",
    language_id: "typescript"
  }
});

// Expected response:
// {
//   content: [{
//     type: "text",
//     text: "File successfully opened: /home/user/my-typescript-project/src/index.ts"
//   }]
// }

// Open multiple files in sequence
const files = [
  { path: "/project/src/utils.ts", lang: "typescript" },
  { path: "/project/src/main.hs", lang: "haskell" },
  { path: "/project/src/app.py", lang: "python" }
];

for (const file of files) {
  await client.callTool({
    name: "open_document",
    arguments: {
      file_path: file.path,
      language_id: file.lang
    }
  });
}
```

--------------------------------

### open_document

Source: https://github.com/tritlo/lsp-mcp/blob/main/README.md

Opens a document in the LSP server, making it available for analysis.

```APIDOC
## POST /tools/open_document

### Description
Opens a file in the LSP server for analysis. This must be called before accessing diagnostics or performing other operations on the file.

### Method
POST

### Endpoint
/tools/open_document

### Parameters
#### Request Body
- **tool** (string) - Required - Must be 'open_document'
- **arguments** (object) - Required - Contains the parameters for the tool
  - **file_path** (string) - Required - Path to the file to open
  - **language_id** (string) - Required - The programming language the file is written in (e.g., "haskell")

### Request Example
```json
{
  "tool": "open_document",
  "arguments": {
    "file_path": "/path/to/your/file",
    "language_id": "haskell"
  }
}
```

### Response
#### Success Response (200)
- **result** (string) - A confirmation message indicating the document has been opened.

#### Response Example
```json
{
  "tool": "open_document",
  "result": "Document /path/to/your/file opened successfully."
}
```
```

--------------------------------

### Extensions

Source: https://github.com/tritlo/lsp-mcp/blob/main/README.md

Enhance LSP-MCP capabilities with language-specific extensions, providing custom tools, resource handlers, prompts, and subscription handlers.

```APIDOC
## 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:

1. Create a new TypeScript file in `src/extensions/` named after your language (e.g., `typescript.ts`)
2. Implement the Extension interface with any of these optional functions:
   - `getToolHandlers()`: Provide custom tool implementations
   - `getToolDefinitions()`: Define custom tools in the MCP API
   - `getResourceHandlers()`: Implement custom resource handlers
   - `getSubscriptionHandlers()`: Implement custom subscription handlers
   - `getUnsubscriptionHandlers()`: Implement custom unsubscription handlers
   - `getResourceTemplates()`: Define custom resource templates
   - `getPromptDefinitions()`: Define custom prompts for language tasks
   - `getPromptHandlers()`: Implement custom prompt handlers

3. Export your implementation functions

The extension system will automatically load your extension when the matching language ID is specified.
```

--------------------------------

### Subscribing to Resource Updates

Source: https://github.com/tritlo/lsp-mcp/blob/main/README.md

Subscribe to diagnostic resources via the `resources/subscribe` endpoint to receive real-time updates. Hover and completion resources do not support subscriptions.

```APIDOC
## 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.
```

--------------------------------

### Diagnostic Resources

Source: https://github.com/tritlo/lsp-mcp/blob/main/README.md

Access diagnostic information for open files. Subscribe to these resources for real-time updates when diagnostics change.

```APIDOC
## 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 files
- `lsp-diagnostics:///path/to/file` - Diagnostics for a specific file

**Note:** Files must be opened using the `open_document` tool before diagnostics can be accessed.
```

--------------------------------

### Hover Information Resources

Source: https://github.com/tritlo/lsp-mcp/blob/main/README.md

Retrieve hover information for code elements at specific positions in files using the `lsp-hover://` resource scheme.

```APIDOC
## 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` (integer) - Required - Line number (1-based)
- `column` (integer) - Required - Column position (1-based)
- `language_id` (string) - Required - The programming language (e.g., "haskell")

### Example
```
lsp-hover:///home/user/project/src/Main.hs?line=42&column=10&language_id=haskell
```
```

--------------------------------

### restart_lsp_server

Source: https://github.com/tritlo/lsp-mcp/blob/main/README.md

Restarts the LSP server process, optionally with a new root directory.

```APIDOC
## POST /tools/restart_lsp_server

### Description
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.

### Method
POST

### Endpoint
/tools/restart_lsp_server

### Parameters
#### Request Body
- **tool** (string) - Required - Must be 'restart_lsp_server'
- **arguments** (object) - Required - Contains the parameters for the tool
  - **root_dir** (string) - Optional - The root directory for the LSP server. If provided, the server will be initialized with this directory after restart.

### Request Example (without root_dir)
```json
{
  "tool": "restart_lsp_server",
  "arguments": {}
}
```

### Request Example (with root_dir)
```json
{
  "tool": "restart_lsp_server",
  "arguments": {
    "root_dir": "/path/to/your/project"
  }
}
```

### Response
#### Success Response (200)
- **result** (string) - A confirmation message indicating the LSP server has restarted.

#### Response Example
```json
{
  "tool": "restart_lsp_server",
  "result": "LSP server restarted successfully."
}
```
```

--------------------------------

### Restart LSP Server with LSP-MCP

Source: https://context7.com/tritlo/lsp-mcp/llms.txt

Restart the LSP server process to recover from errors or apply configuration changes. It supports restarting with the same root directory or reinitializing with a new one.

```javascript
// Restart with same root directory
const restartResult = await client.callTool({
  name: "restart_lsp_server",
  arguments: {}
});

// Expected response:
// {
//   content: [{
//     type: "text",
//     text: "LSP server successfully restarted"
//   }]
// }

// Restart and reinitialize with new root directory
const restartWithDirResult = await client.callTool({
  name: "restart_lsp_server",
  arguments: {
    root_dir: "/home/user/different-project"
  }
});

// Expected response:
// {
//   content: [{
//     type: "text",
//     text: "LSP server successfully restarted and initialized with root directory: /home/user/different-project"
//   }]
// }
```

--------------------------------

### Restart LSP Server - JSON

Source: https://github.com/tritlo/lsp-mcp/blob/main/README.md

Restarts the LSP server process. This is useful for applying configuration changes or recovering from errors without affecting the MCP server. An optional `root_dir` can be provided to re-initialize the server with a specific project.

```json
{
  "tool": "restart_lsp_server",
  "arguments": {}
}
```

```json
{
  "tool": "restart_lsp_server",
  "arguments": {
    "root_dir": "/path/to/your/project"
  }
}
```

--------------------------------

### get_diagnostics

Source: https://github.com/tritlo/lsp-mcp/blob/main/README.md

Retrieves diagnostic information (errors, warnings) for open files.

```APIDOC
## POST /tools/get_diagnostics

### Description
Gets diagnostic messages (errors, warnings) for one or all open files.

### Method
POST

### Endpoint
/tools/get_diagnostics

### Parameters
#### Request Body
- **tool** (string) - Required - Must be 'get_diagnostics'
- **arguments** (object) - Required - Contains the parameters for the tool
  - **file_path** (string) - Optional - Path to the file to get diagnostics for. If not provided, returns diagnostics for all open files.

### Request Example (for a specific file)
```json
{
  "tool": "get_diagnostics",
  "arguments": {
    "file_path": "/path/to/your/file"
  }
}
```

### Request Example (for all open files)
```json
{
  "tool": "get_diagnostics",
  "arguments": {}
}
```

### Response
#### Success Response (200)
- **result** (object) - An object where keys are file paths and values are arrays of diagnostic objects.
  - **[file_path]** (array) - A list of diagnostic messages for the file.
    - **severity** (integer) - The severity of the diagnostic (e.g., 1 for error, 2 for warning).
    - **range** (object) - The range in the document where the diagnostic applies.
    - **message** (string) - The diagnostic message.

#### Response Example (for a specific file)
```json
{
  "tool": "get_diagnostics",
  "result": {
    "/path/to/your/file": [
      {
        "severity": 1,
        "range": {
          "start": {"line": 5, "character": 10},
          "end": {"line": 5, "character": 25}
        },
        "message": "Undefined variable 'x'."
      }
    ]
  }
}
```

#### Response Example (for all open files)
```json
{
  "tool": "get_diagnostics",
  "result": {
    "/path/to/your/file": [
      {
        "severity": 1,
        "range": {
          "start": {"line": 5, "character": 10},
          "end": {"line": 5, "character": 25}
        },
        "message": "Undefined variable 'x'."
      }
    ],
    "/path/to/another/file": [
      {
        "severity": 2,
        "range": {
          "start": {"line": 10, "character": 0},
          "end": {"line": 10, "character": 5}
        },
        "message": "Unused import."
      }
    ]
  }
}
```
```

--------------------------------

### Open Document for LSP - JSON

Source: https://github.com/tritlo/lsp-mcp/blob/main/README.md

Notifies the LSP server that a specific file has been opened. This allows the server to begin analysis and provide language features for that file. Requires the file path and its language ID.

```json
{
  "tool": "open_document",
  "arguments": {
    "file_path": "/path/to/your/file",
    "language_id": "haskell"
  }
}
```

--------------------------------

### get_code_actions

Source: https://github.com/tritlo/lsp-mcp/blob/main/README.md

Retrieves available code actions for a specified range in a file.

```APIDOC
## POST /tools/get_code_actions

### Description
Gets code actions for a specific range in a file.

### Method
POST

### Endpoint
/tools/get_code_actions

### Parameters
#### Request Body
- **tool** (string) - Required - Must be 'get_code_actions'
- **arguments** (object) - Required - Contains the parameters for the tool
  - **file_path** (string) - Required - Path to the file
  - **language_id** (string) - Required - The programming language the file is written in (e.g., "haskell")
  - **start_line** (integer) - Required - Start line number
  - **start_column** (integer) - Required - Start column position
  - **end_line** (integer) - Required - End line number
  - **end_column** (integer) - Required - End column position

### Request Example
```json
{
  "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
  }
}
```

### Response
#### Success Response (200)
- **result** (array) - A list of code actions returned by the LSP server.

#### Response Example
```json
{
  "tool": "get_code_actions",
  "result": [
    {
      "title": "Quick Fix: Add missing import",
      "kind": "quickfix",
      "edit": {
        "changes": {
          "/path/to/your/file": [
            {
              "range": {
                "start": {"line": 0, "character": 0},
                "end": {"line": 0, "character": 0}
              },
              "newText": "import Data.List\n"
            }
          ]
        }
      }
    }
  ]
}
```
```

--------------------------------

### Enable MCP Debug Logging - Shell

Source: https://github.com/tritlo/lsp-mcp/blob/main/README.md

Activates detailed logging of all MCP traffic between the Claude client and the server. This is useful for diagnosing communication issues. No specific inputs or outputs are required beyond running the command.

```shell
claude --mcp-debug
```

--------------------------------

### get_info_on_location

Source: https://github.com/tritlo/lsp-mcp/blob/main/README.md

Retrieves hover information for a specific location within a file.

```APIDOC
## POST /tools/get_info_on_location

### Description
Gets hover information at a specific location in a file.

### Method
POST

### Endpoint
/tools/get_info_on_location

### Parameters
#### Request Body
- **tool** (string) - Required - Must be 'get_info_on_location'
- **arguments** (object) - Required - Contains the parameters for the tool
  - **file_path** (string) - Required - Path to the file
  - **language_id** (string) - Required - The programming language the file is written in (e.g., "haskell")
  - **line** (integer) - Required - Line number
  - **column** (integer) - Required - Column position

### Request Example
```json
{
  "tool": "get_info_on_location",
  "arguments": {
    "file_path": "/path/to/your/file",
    "language_id": "haskell",
    "line": 3,
    "column": 5
  }
}
```

### Response
#### Success Response (200)
- **result** (any) - The hover information returned by the LSP server.

#### Response Example
```json
{
  "tool": "get_info_on_location",
  "result": {
    "contents": [
      {
        "kind": "markdown",
        "value": "```haskell\n-- Example type signature\n```"
      }
    ]
  }
}
```
```

--------------------------------

### Control Log Verbosity with LSP-MCP

Source: https://context7.com/tritlo/lsp-mcp/llms.txt

Adjust logging levels at runtime for debugging and troubleshooting. Various levels from 'emergency' to 'debug' can be set.

```javascript
// Set log level to debug for detailed output
const logResult = await client.callTool({
  name: "set_log_level",
  arguments: {
    level: "debug"
  }
});

// Expected response:
// {
//   content: [{
//     type: "text",
//     text: "Log level set to: debug"
//   }]
// }

// Available log levels (least to most verbose):
// "emergency", "alert", "critical", "error", "warning", "notice", "info", "debug"

// Set to minimal logging for production
await client.callTool({
  name: "set_log_level",
  arguments: { level: "error" }
});

// Set to moderate detail for normal operation
await client.callTool({
  name: "set_log_level",
  arguments: { level: "info" }
});
```

--------------------------------

### Set MCP Log Level - JSON

Source: https://github.com/tritlo/lsp-mcp/blob/main/README.md

Dynamically changes the log level of the MCP server at runtime. This allows adjustment of logging verbosity without restarting the server. Accepts a 'level' argument specifying the desired log level.

```json
{
  "tool": "set_log_level",
  "arguments": {
    "level": "debug"
  }
}
```