Provides refactoring tools for JavaScript code through LSP integration, including symbol renaming, reference finding, function extraction, and code movement capabilities.
Provides refactoring tools for Python code through LSP integration, including symbol renaming, reference finding, function extraction, and code movement capabilities.
Provides refactoring tools for TypeScript code through LSP integration, including symbol renaming, reference finding, function extraction, and code movement capabilities.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@LSP MCP Server rename the calculateTotal function to computeSum in src/utils.ts on line 45"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An LSP (Language Server Protocol) MCP (Model Context Protocol) server that provides refactoring tools through LSP integration. This server exposes refactoring capabilities as MCP tools that can be used by MCP clients like Claude Code.
npm install -g lsp-mcp-serverClone the repository:
git clone <repository-url>
cd lsp-mcp-serverInstall dependencies:
pnpm installBuild the project:
pnpm run buildLink for global use:
npm linkAfter linking, you can use the mcp-lsp command globally.
Alternative: Use without linking:
# Run directly
pnpm start
# Or build and run
pnpm run devRelated MCP server: CodeGraph MCP Server
The server requires these language servers to be installed for full functionality:
npm install -g typescript-language-server typescript# Default LSP server for type checking and refactoring
npm install -g pyright
# Optional: For linting (when using serverType: 'lint')
pip install ruffIf you have the server installed globally:
/mcp add lsp-mcpOnce connected, you can ask Claude Code to use the refactoring tools:
"Rename the calculateTotal function to computeSum in src/utils.ts on line 45"
"Find all references to the UserService class in src/services/user.ts line 12"
"Extract lines 20-35 from src/components/Header.tsx into a new function called renderNavigation"
"Move the validateEmail function from src/utils/validation.ts line 8 to src/utils/email.ts"
"Rename the file src/old-name.ts to src/new-name.ts"
Claude Code will automatically use the appropriate LSP refactoring tools based on your requests.
The server can also be used directly by other MCP clients via stdio:
mcp-lsprename_file - Rename files/folders using LSP rename capabilities
move_function - Move functions between files using LSP refactoring
extract_function - Extract code selections into new functions
find_references - Find all references to symbols
rename_symbol - Rename symbols across all files
Each tool accepts parameters specific to the refactoring operation:
rename_symbol: Requires file, line, newName, and optionally character and language
find_references: Requires file, line, and optionally character and language
extract_function: Requires file, startLine, endLine, functionName, and optionally character positions and language
TypeScript/JavaScript
Python
pnpm install - Install dependencies
pnpm run build - Compile TypeScript to dist/
pnpm start - Run the compiled server
pnpm run dev - Build and run in one command
pnpm run type-check - Check types without building
pnpm run lint - Check code with ESLint
pnpm run lint:fix - Auto-fix linting issues
pnpm run format - Format code with Prettier
pnpm run clean - Remove dist/ directory
The server consists of:
LSPRefactorServer: Main server class implementing MCP interface
LSP Client Management: Manages connections to language servers
Tool Implementations: Each refactoring operation communicates with LSP servers
MCP Protocol: Server ↔ MCP clients via stdio
LSP Protocol: Server ↔ Language servers via JSON-RPC over stdio
Extract selected code into a new function
| Name | Required | Description | Default |
|---|---|---|---|
| file | Yes | File containing the code to extract | |
| startLine | Yes | Start line of code to extract | |
| startCharacter | No | Start character position | |
| endLine | Yes | End line of code to extract | |
| endCharacter | No | End character position | |
| functionName | Yes | Name for the new function | |
| language | No | Programming language | typescript |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While 'extract' implies a mutation operation, the description doesn't specify whether this modifies the original file, creates a new file, requires specific permissions, or has any side effects. No information about error conditions, rate limits, or response format is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's appropriately sized for the tool's complexity and gets straight to the point without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 7 parameters and no annotations or output schema, the description is inadequate. It doesn't explain what happens after extraction, whether the original code is replaced with a function call, what the return value contains, or any error conditions. The description fails to compensate for the lack of structured metadata.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 7 parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema - it doesn't explain relationships between parameters (like how start/end positions work together) or provide usage examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('extract') and target ('selected code into a new function'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'move_function' or 'rename_symbol', which might involve similar code manipulation operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'move_function' or 'rename_symbol'. There's no mention of prerequisites, appropriate contexts, or exclusions for when this tool should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find all references to a symbol using LSP
| Name | Required | Description | Default |
|---|---|---|---|
| file | Yes | File containing the symbol | |
| line | Yes | Line number of the symbol | |
| character | No | Character position of the symbol | |
| language | No | Programming language | typescript |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions using LSP, which hints at language-aware analysis, but doesn't describe key traits like whether it's read-only (implied by 'find'), performance considerations (e.g., speed, network usage), error handling, or output format. For a tool with 4 parameters and no annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Find all references to a symbol') and adds technical context ('using LSP'). There is no wasted verbiage or redundancy, making it highly concise and well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, no annotations, no output schema), the description is incomplete. It lacks details on behavioral aspects (e.g., read-only nature, potential side effects), output expectations (what 'references' look like), and usage context relative to siblings. Without annotations or output schema, the description should compensate more to provide a complete understanding, which it does not.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters (file, line, character, language) with descriptions and defaults. The description adds no additional meaning beyond what the schema provides, such as clarifying how parameters interact (e.g., file-path format, line/character indexing) or usage examples. Baseline 3 is appropriate as the schema handles the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Find all references') and the resource ('to a symbol'), specifying it uses LSP (Language Server Protocol). It distinguishes from siblings like 'rename_symbol' or 'move_function' by focusing on reference discovery rather than modification. However, it doesn't explicitly contrast with sibling tools beyond the general purpose difference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives is provided. The description implies usage for locating symbol references via LSP, but it doesn't specify scenarios (e.g., code navigation vs. refactoring), prerequisites, or when not to use it (e.g., for non-symbol elements). Sibling tools like 'extract_function' or 'rename_symbol' suggest related contexts, but no comparative advice is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Move a function to a different file using LSP refactoring
| Name | Required | Description | Default |
|---|---|---|---|
| sourceFile | Yes | Source file containing the function | |
| targetFile | Yes | Target file to move the function to | |
| functionName | Yes | Name of the function to move | |
| line | Yes | Line number where the function is located | |
| character | No | Character position where the function starts | |
| language | No | Programming language | typescript |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'move' implies mutation and 'LSP refactoring' suggests editor integration, it doesn't address critical behaviors: whether this operation is reversible, what happens to imports/references, if it requires specific permissions, or what the output looks like. For a mutation tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core action and includes the implementation mechanism. Every element earns its place without redundancy or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 6 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what happens after the move, how errors are handled, or what the agent should expect as a result. The combination of mutation complexity and lack of structured metadata requires more descriptive context than provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are documented in the schema. The description adds no additional parameter semantics beyond what the schema provides (like explaining why both line and character are needed for precise location). The baseline of 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Move a function') and mechanism ('using LSP refactoring'), distinguishing it from siblings like extract_function (which creates new functions) and rename_symbol (which renames within the same file). It precisely identifies both the resource (function) and destination (different file).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like extract_function or rename_symbol. It doesn't mention prerequisites, constraints, or typical scenarios for moving functions versus other refactoring operations, leaving the agent to infer usage context from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rename a file or folder using LSP rename capabilities
| Name | Required | Description | Default |
|---|---|---|---|
| oldPath | Yes | Current path of the file or folder | |
| newPath | Yes | New path for the file or folder | |
| language | No | Programming language (typescript, javascript, python, etc.) | typescript |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'LSP rename capabilities' which hints at Language Server Protocol integration, but doesn't disclose critical behavioral traits: whether this requires specific permissions, if it's destructive (renaming typically is), what happens on failure, or any rate limits. For a mutation tool with zero annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's appropriately sized and front-loaded, stating the core purpose immediately. Every word earns its place without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns, error conditions, or behavioral implications. The mention of 'LSP rename capabilities' adds some context but doesn't compensate for the missing safety and response information needed for a destructive operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema. It doesn't explain parameter relationships, constraints, or usage patterns. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('rename') and resource ('file or folder'), and specifies the mechanism ('using LSP rename capabilities'). However, it doesn't explicitly differentiate from sibling tools like 'rename_symbol' or 'move_function', which appear related. The purpose is specific but lacks sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'rename_symbol', 'move_function', and 'find_references', there's no indication of when this tool is appropriate versus those other options. No prerequisites, exclusions, or contextual usage information is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rename a symbol (variable, function, class, etc.) across all files
| Name | Required | Description | Default |
|---|---|---|---|
| file | Yes | File containing the symbol | |
| line | Yes | Line number of the symbol | |
| character | No | Character position of the symbol | |
| newName | Yes | New name for the symbol | |
| language | No | Programming language | typescript |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool renames symbols 'across all files', which suggests a potentially destructive, wide-scope operation, but doesn't disclose behavioral details like whether changes are reversible, what permissions are needed, how conflicts are handled, or what the response looks like. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('rename a symbol') and adds clarifying scope ('across all files'). There is zero wasted text, and it's appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool with no annotations and no output schema, the description is incomplete. It lacks critical behavioral context (e.g., safety, permissions, response format) and doesn't compensate for the absence of structured data. The 100% schema coverage helps with parameters, but overall completeness is poor for a tool that modifies code across files.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 5 parameters (file, line, character, newName, language) with descriptions. The description adds no additional parameter semantics beyond what the schema provides, such as explaining how 'character' is used or what 'language' affects. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'rename' and the resource 'symbol', specifying it applies to variables, functions, classes, etc. across all files. It distinguishes from siblings like 'rename_file' (which renames files, not symbols) and 'move_function' (which moves rather than renames).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for renaming symbols in codebases, but doesn't explicitly state when to use this vs. alternatives like 'find_references' (for locating symbols) or 'extract_function' (for refactoring). No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
extract_functionfind_referencesmove_functionrename_filerename_symbolScored across 5 tools
Each tool has a clearly distinct purpose with no overlap: extract_function creates new functions, find_references locates symbol usage, move_function relocates functions between files, rename_file handles file/folder renaming, and rename_symbol renames symbols across files. The descriptions make it impossible to confuse one tool for another.
All tool names follow a consistent verb_noun pattern (e.g., extract_function, find_references, move_function, rename_file, rename_symbol). The naming is perfectly uniform with no deviations in style or convention.
With 5 tools, this server is well-scoped for LSP-based code refactoring and navigation. Each tool earns its place by covering distinct refactoring operations without being too sparse or bloated.
The toolset covers key LSP refactoring operations (extract, move, rename) and symbol navigation (find references), but lacks tools for other common LSP features like code completion, diagnostics, or formatting. However, the provided tools form a coherent subset for core refactoring tasks.
Code intelligence for coding agents: semantic, AST, graph, and full-text search. 279+ languages.
Code intelligence platform for AI agents. 20 tools for architecture, security & impact analysis.
Ask a codebase what calls what: search, blast radius, paths between symbols, and diffs.
Codebase intelligence for agents: 152 structured artifacts across 21 programs, one call.
