cclsp

MCP ServerFree

MCP server for accessing LSP functionality

Open Source

/ 100

12 capabilities

Capabilities12 decomposed

lsp-to-mcp protocol bridging with multi-language server support

Medium confidence

Exposes Language Server Protocol (LSP) capabilities through the Model Context Protocol (MCP) interface, enabling Claude and other MCP clients to invoke LSP features (code completion, diagnostics, hover information, symbol navigation) by translating MCP tool calls into LSP JSON-RPC messages and routing responses back through the MCP transport layer. Implements bidirectional message marshaling between the two protocol stacks with automatic capability discovery from connected LSP servers.

Solves for

Enable Claude to perform code intelligence tasks (completion, diagnostics, refactoring) against any LSP-compatible language serverAccess language-specific tooling (TypeScript, Python, Rust, Go LSPs) through a unified MCP interface without reimplementing language analysisIntegrate existing editor LSP infrastructure (VS Code, Neovim, Emacs language servers) into AI agent workflows

Best for

AI agent developers building code-aware systems that need language-specific intelligence

Teams integrating Claude with existing LSP-based development infrastructure

Developers building MCP servers that need to expose language tooling capabilities

Requires

Node.js 16+ (for MCP server runtime)

At least one Language Server Protocol (LSP) server installed and accessible (e.g., typescript-language-server, pylsp, rust-analyzer)

MCP client capable of connecting to stdio-based MCP servers (Claude Desktop, custom MCP client, or similar)

Limitations

Latency overhead from protocol translation layer — each LSP request incurs JSON-RPC serialization/deserialization and MCP message wrapping (~50-200ms per round-trip depending on server responsiveness)

LSP server availability and stability directly impacts capability — if underlying LSP crashes or becomes unresponsive, the MCP bridge cannot recover without manual restart

No built-in caching of LSP responses — repeated queries for the same symbol or completion context will re-query the LSP server, potentially causing performance degradation with large codebases

What makes it unique

Implements a bidirectional protocol adapter that maps the full LSP specification onto MCP's tool-calling interface, allowing any LSP server to become an MCP resource without modifying the LSP server itself. Uses stdio-based process management to spawn and communicate with LSP servers, with automatic capability negotiation via LSP's initialize handshake.

vs alternatives

Unlike language-specific MCP servers (e.g., separate TypeScript, Python, Rust MCP implementations), cclsp provides a single unified bridge that works with any LSP-compatible server, reducing maintenance burden and enabling support for new languages immediately when LSP servers are available.

code completion and intellisense via lsp textdocument/completion

Medium confidence

Translates MCP tool calls into LSP textDocument/completion requests, querying the connected language server for context-aware code suggestions at a specific file position. Returns completion items with type information, documentation, and insertion text, leveraging the LSP server's semantic understanding of the codebase rather than pattern matching or static analysis.

Solves for

Get intelligent code completions for a specific cursor position in a fileRetrieve completion context including parameter hints, return types, and documentationEnable Claude to suggest code with full awareness of available symbols, imports, and type constraints

Best for

AI agents generating or editing code that need to respect language semantics and available APIs

Code generation workflows where completion context improves suggestion quality

Developers building Claude-powered code editors or IDE plugins

Requires

LSP server with textDocument/completion capability (most modern LSP servers support this)

File URI and cursor position (line and character) in the target file

LSP server must have the file indexed (typically requires the file to be opened via didOpen notification)

Limitations

Completion quality depends entirely on the underlying LSP server's implementation — some LSP servers provide richer metadata than others

No filtering or ranking of completions by relevance — returns raw LSP completion list, requiring client-side ranking logic

Requires file to be open and indexed by the LSP server — completions for unsaved or newly created files may be incomplete

What makes it unique

Directly exposes LSP's textDocument/completion protocol without abstraction, preserving all metadata (completion kind, documentation, additionalTextEdits) that the LSP server provides. Handles completion context negotiation (trigger characters, incomplete flags) transparently.

vs alternatives

Provides semantic completions from the actual language server (with full type awareness) rather than regex-based or token-frequency approaches, resulting in more accurate suggestions for complex codebases with multiple imports and namespaces.

document and workspace synchronization with lsp didopen, didchange, didclose notifications

Medium confidence

Manages LSP document lifecycle notifications (didOpen, didChange, didClose, didSave) to keep the LSP server's view of the codebase synchronized with the MCP client's state. Translates file changes from the MCP client into LSP notifications, ensuring the LSP server has current file content for accurate analysis. Implements incremental change tracking to minimize bandwidth and server load.

Solves for

Keep the LSP server synchronized with file changes made through the MCP clientEnable LSP analysis on modified files without saving to diskMaintain accurate diagnostics and code intelligence as code is edited

Best for

Interactive code editing workflows where Claude modifies code and needs real-time analysis

Code generation systems that need to validate generated code immediately

Developers building Claude-powered code editors with live analysis

Requires

LSP server with document synchronization support (all LSP servers support this)

MCP client that can track file changes and send notifications

File URI and content for each file being synchronized

Limitations

Synchronization overhead — each file change requires an LSP notification, which can impact performance with rapid edits

No built-in conflict resolution — if multiple clients modify the same file, synchronization state may become inconsistent

LSP server may have stale state if notifications are lost or reordered — requires careful message ordering

What makes it unique

Implements LSP's document synchronization protocol with support for both full and incremental document updates. Maintains document version tracking to ensure the LSP server processes changes in order.

vs alternatives

Enables real-time LSP analysis on in-memory file changes without requiring disk I/O, compared to approaches that require saving files to disk before analysis.

multi-language server orchestration and capability negotiation

Medium confidence

Manages connections to multiple LSP servers simultaneously, each serving different languages or file types. Implements LSP initialize/shutdown handshake for each server, negotiates supported capabilities, and routes file operations to the appropriate language server based on file extension or language ID. Enables a single MCP instance to provide code intelligence for polyglot codebases.

Solves for

Support code intelligence for multiple languages in a single workspace (TypeScript, Python, Go, etc.)Automatically route file operations to the correct language serverDiscover and negotiate capabilities with multiple LSP servers

Best for

Polyglot development teams working with multiple languages in a single codebase

Monorepo environments with code in multiple languages

Developers building universal code intelligence tools

Requires

Multiple LSP servers installed and configured (one per language)

File type to language mapping (file extension or language ID)

Configuration specifying which LSP server to use for each language

Limitations

Complexity increases with each additional LSP server — managing multiple server connections adds operational overhead

Resource consumption scales with number of servers — each LSP server consumes memory and CPU, which can be problematic on resource-constrained systems

No built-in load balancing or failover — if one LSP server crashes, that language becomes unavailable

What makes it unique

Manages multiple LSP server instances with independent lifecycle management and capability negotiation. Routes requests to the appropriate server based on file language ID, enabling seamless multi-language support.

vs alternatives

Provides language-specific code intelligence for each language (using the actual language server) rather than attempting to provide generic code intelligence across all languages, resulting in more accurate and feature-rich analysis.

diagnostic collection and code quality analysis via lsp textdocument/publishdiagnostics

Medium confidence

Subscribes to LSP textDocument/publishDiagnostics notifications and exposes collected diagnostics (errors, warnings, hints) as queryable MCP resources. Maintains a diagnostic cache indexed by file URI, allowing Claude to retrieve current code quality issues, their severity levels, and suggested fixes without re-running analysis.

Solves for

Retrieve all errors and warnings in a file to inform code generation or refactoring decisionsIdentify type errors, linting violations, and other code quality issues before suggesting fixesEnable Claude to prioritize fixes based on diagnostic severity and location

Best for

Code quality automation workflows that need to understand existing issues before suggesting changes

AI-assisted debugging where Claude needs to see compiler/linter errors

Refactoring agents that must validate changes against the language server's analysis

Requires

LSP server with diagnostic support (most LSP servers implement this)

File must be opened in the LSP server (via didOpen notification) to receive diagnostics

MCP client must maintain a persistent connection to receive publishDiagnostics notifications

Limitations

Diagnostics are only available after the LSP server has analyzed the file — newly opened files may have stale or missing diagnostics until the server completes its analysis pass

No real-time diagnostic updates if the LSP server is slow or overloaded — diagnostic freshness depends on server performance

Diagnostic interpretation is language-specific — error codes and messages vary significantly across LSP servers, requiring client-side parsing for actionable insights

What makes it unique

Passively collects LSP publishDiagnostics notifications and exposes them as queryable state rather than requiring active polling. Maintains diagnostic history indexed by file, enabling Claude to track which issues have been resolved or introduced.

vs alternatives

Provides real-time diagnostics from the language server's actual compilation/analysis pipeline rather than running separate linters, ensuring diagnostics match the language server's understanding of the codebase (important for type-aware languages like TypeScript).

symbol definition and reference navigation via lsp textdocument/definition and textdocument/references

Medium confidence

Implements LSP textDocument/definition and textDocument/references requests to enable code navigation and symbol resolution. Translates MCP queries into LSP position-based requests, returning file locations and ranges where a symbol is defined or referenced, enabling Claude to understand code structure and trace dependencies.

Solves for

Find the definition of a symbol (function, class, variable) to understand its implementationLocate all references to a symbol to assess impact of changesNavigate code structure to understand dependencies and relationships between modules

Best for

Code refactoring agents that need to understand symbol usage across a codebase

Developers building code navigation features in Claude-powered IDEs

Codebase analysis workflows that require understanding symbol relationships

Requires

LSP server with textDocument/definition and textDocument/references capability

File URI and cursor position (line and character) pointing to the symbol

LSP server must have indexed the codebase (typically requires opening files or running a workspace initialization)

Limitations

Definition resolution depends on LSP server's indexing — may fail for dynamically generated code or symbols from external packages not in the workspace

Reference finding can be slow on large codebases — some LSP servers may timeout or return incomplete results for heavily-used symbols

No built-in filtering of results — returns all references including comments and strings, requiring client-side filtering for actionable results

What makes it unique

Delegates symbol resolution to the LSP server's semantic index rather than implementing custom parsing or regex-based matching. Supports both definition and references queries through a unified position-based interface, enabling bidirectional code navigation.

vs alternatives

Provides accurate symbol resolution for statically-typed languages (TypeScript, Go, Rust) where the LSP server has full type information, compared to regex-based approaches that struggle with overloaded functions, shadowed variables, and complex scoping rules.

hover information and type inspection via lsp textdocument/hover

Medium confidence

Exposes LSP textDocument/hover requests through MCP, returning type signatures, documentation, and contextual information about a symbol at a specific position. Enables Claude to inspect types, read documentation, and understand symbol semantics without opening the symbol's definition file.

Solves for

Inspect the type signature of a variable, function, or expression at a cursor positionRetrieve documentation and comments associated with a symbolUnderstand parameter types and return types before generating code that uses a symbol

Best for

Code generation workflows where Claude needs to understand symbol types before suggesting usage

Interactive code exploration where Claude explains code to users

Type-aware code completion and suggestion systems

Requires

LSP server with textDocument/hover capability

File URI and cursor position (line and character) pointing to the symbol

LSP server must have indexed the file and its dependencies

Limitations

Hover information quality varies by LSP server — some servers provide rich markdown documentation while others return minimal type information

No caching of hover results — repeated queries for the same symbol will re-query the LSP server

Hover information is position-dependent — the same symbol may have different hover information in different contexts (e.g., overloaded functions)

What makes it unique

Directly exposes LSP's hover capability without interpretation, preserving markdown formatting and rich documentation that the LSP server provides. Enables Claude to access type information without navigating to definition files.

vs alternatives

Provides accurate type information from the language server's semantic analysis (with full type inference) rather than static parsing, enabling Claude to understand complex types like generics, union types, and conditional types in TypeScript.

workspace symbol search via lsp workspace/symbol

Medium confidence

Implements LSP workspace/symbol requests to enable global symbol search across the entire workspace. Translates MCP search queries into LSP symbol queries, returning matching symbols with their locations, kinds (function, class, variable, etc.), and file paths. Enables Claude to discover available APIs and understand codebase structure without file-by-file navigation.

Solves for

Search for a function or class by name across the entire codebaseDiscover available APIs and exported symbols in a workspaceUnderstand codebase structure by exploring symbol hierarchies

Best for

Code generation agents that need to discover available functions and classes to use

Codebase exploration workflows where Claude needs to understand what's available

Refactoring tools that need to find all instances of a symbol across the workspace

Requires

LSP server with workspace/symbol capability

Workspace initialized with LSP server (typically requires opening a folder or project root)

Search query string (symbol name or partial name)

Limitations

Search performance degrades with large workspaces — some LSP servers may timeout or return truncated results for broad queries

Symbol search is typically fuzzy and may return many false positives — requires client-side filtering and ranking

Results depend on LSP server's indexing completeness — may miss symbols from unopened files or excluded directories

What makes it unique

Delegates workspace-wide symbol indexing to the LSP server rather than implementing custom indexing. Supports fuzzy matching and filtering by symbol kind, enabling flexible discovery of available APIs.

vs alternatives

Provides accurate symbol search across the entire workspace (including external dependencies and generated code) compared to grep-based approaches that may miss symbols in non-text files or have difficulty with language-specific syntax.

code formatting and style normalization via lsp textdocument/formatting

Medium confidence

Exposes LSP textDocument/formatting requests to enable code formatting and style normalization. Translates MCP formatting requests into LSP formatting calls, returning TextEdit arrays that describe the formatting changes needed. Allows Claude to format code according to the project's configured style rules without implementing language-specific formatters.

Solves for

Format generated code to match the project's style conventionsNormalize code style across a file or selectionApply formatting rules defined in the project's configuration (prettier, black, rustfmt, etc.)

Best for

Code generation workflows where Claude needs to format generated code before returning it

Style normalization tasks where code must conform to project standards

Developers building Claude-powered code editors with formatting support

Requires

LSP server with textDocument/formatting capability

File URI and optional range (if formatting only a selection)

LSP server must have a formatter configured (e.g., prettier for JavaScript, black for Python)

Limitations

Formatting quality depends on the LSP server's formatter integration — some LSP servers may not have formatters configured

Formatting can be slow on large files — some formatters may timeout or return incomplete results

No preview of formatting changes — must apply TextEdits to see the result

What makes it unique

Delegates formatting to the LSP server's configured formatter rather than implementing language-specific formatting logic. Supports range-based formatting and respects project-specific formatting configuration.

vs alternatives

Applies the project's actual configured formatter (prettier, black, rustfmt) rather than a generic formatter, ensuring generated code matches the project's style conventions exactly.

rename refactoring with cross-file impact analysis via lsp textdocument/rename

Medium confidence

Implements LSP textDocument/rename requests to enable safe symbol renaming across the codebase. Translates MCP rename requests into LSP rename calls, returning WorkspaceEdit objects that describe all necessary changes across multiple files. Enables Claude to perform refactoring with confidence that all references are updated consistently.

Solves for

Rename a symbol (function, class, variable) and update all references across the codebasePerform safe refactoring with LSP-verified impact analysisUnderstand the scope of a rename operation before applying changes

Best for

Refactoring agents that need to rename symbols safely across large codebases

Code transformation workflows where consistency is critical

Developers building Claude-powered refactoring tools

Requires

LSP server with textDocument/rename capability

File URI and cursor position (line and character) pointing to the symbol to rename

New name for the symbol

Limitations

Rename operations can be slow on large codebases — some LSP servers may timeout when computing all affected files

Rename may fail if the new name conflicts with existing symbols — requires client-side validation

No preview of rename changes — must inspect the WorkspaceEdit to understand the impact

What makes it unique

Leverages LSP's semantic understanding to compute rename impact across the entire workspace, ensuring all references are updated consistently. Returns a WorkspaceEdit that can be applied atomically.

vs alternatives

Provides accurate rename refactoring that respects language scoping rules and type information (important for languages like TypeScript with complex scoping) compared to text-based find-and-replace that may incorrectly rename unrelated symbols.

code action and quick fix suggestions via lsp textdocument/codeaction

Medium confidence

Exposes LSP textDocument/codeAction requests to retrieve suggested fixes and refactoring actions for a specific code range. Translates MCP requests into LSP code action queries, returning Command and CodeAction objects that describe available fixes (e.g., 'add missing import', 'fix type error', 'extract function'). Enables Claude to discover and apply automated fixes without implementing language-specific fix logic.

Solves for

Retrieve suggested fixes for errors and warnings at a specific locationDiscover available refactoring actions (extract function, inline variable, etc.)Apply automated fixes to resolve code quality issues

Best for

Code quality automation where Claude needs to apply LSP-suggested fixes

Refactoring workflows that leverage language-specific refactoring actions

Error resolution agents that automatically fix common issues

Requires

LSP server with textDocument/codeAction capability

File URI and range (start and end positions) to query for code actions

Optional context (diagnostics at the range, code action kind filter)

Limitations

Code action availability depends on the LSP server's implementation — not all LSP servers provide code actions for all error types

Code actions may have side effects or unintended consequences — requires careful review before applying

No built-in ranking or filtering of code actions — returns all available actions, requiring client-side selection logic

What makes it unique

Exposes LSP's code action interface which aggregates fixes from multiple sources (compiler, linters, custom plugins) into a unified API. Supports filtering by code action kind (quickfix, refactor, source) to enable targeted fix discovery.

vs alternatives

Provides language-specific fixes from the actual LSP server (with full semantic understanding) rather than generic pattern-based fixes, enabling accurate fixes for complex issues like missing imports, type mismatches, and unused variables.

semantic token highlighting and syntax analysis via lsp textdocument/semantictokens

Medium confidence

Implements LSP textDocument/semanticTokens requests to retrieve semantic token information for a file or range. Returns token type and modifier information (e.g., 'function', 'readonly', 'deprecated') that enables semantic-aware syntax highlighting and code analysis. Allows Claude to understand code structure at a semantic level beyond simple syntax highlighting.

Solves for

Analyze code structure using semantic token information (identify functions, classes, variables, etc.)Understand semantic properties of code (readonly variables, deprecated functions, etc.)Enable semantic-aware code generation that respects language semantics

Best for

Code analysis workflows that need semantic understanding beyond syntax

Developers building semantic-aware code editors or analysis tools

Code generation agents that need to understand code structure semantically

Requires

LSP server with textDocument/semanticTokens capability

File URI and optional range (if querying only a portion of the file)

LSP server must have indexed the file

Limitations

Semantic token support varies by LSP server — not all LSP servers implement this capability

Semantic token computation can be expensive on large files — may impact performance

Token information is position-dependent and may change as code is edited — requires re-querying after edits

What makes it unique

Exposes LSP's semantic token protocol which provides token-level semantic information (type, modifiers) beyond simple syntax highlighting. Enables fine-grained semantic analysis of code structure.

vs alternatives

Provides semantic token information from the language server's actual semantic analysis (with full type and scope information) compared to regex-based syntax highlighting that cannot distinguish between different uses of the same token.

Capabilities are decomposed by AI analysis. Each maps to specific user intents and improves with match feedback.

Related Artifactssharing capabilities

Artifacts that share capabilities with cclsp, ranked by overlap. Discovered automatically through the match graph.

MCP Server24

Language Server

** 🏎️ - MCP Language Server gives MCP enabled clients access to semantic tools like get definition, references, rename, and diagnostics.

multi-language lsp client with protocol abstractionlsp-backed symbol definition retrieval with full source contextmcp tool registration and request routingreal-time diagnostic aggregation from language servers

4 shared capabilities

MCP Server36

cclsp

MCP server for accessing LSP functionality

multi-language semantic code completion via lspmulti-lsp server orchestration and lifecycle managementlanguage server protocol bridging via mcplsp protocol translation and mcp integration

4 shared capabilities

Workflow37

Windmill

Developer platform for internal tools.

language server protocol (lsp) integration for code editing

1 shared capability

MCP Server27

@theia/ai-mcp-server

Theia - MCP Server

language server protocol (lsp) integration via mcp

1 shared capability

Repository23

Zed

** multiplayer code editor from the creators of atom

language server protocol (lsp) integration with multi-language tree-sitter parsing

1 shared capability

MCP Server44

octocode-mcp

MCP server for semantic code research and context generation on real-time using LLM patterns | Search naturally across public & private repos based on your permissions | Transform any accessible codebase/s into AI-optimized knowledge on simple and complex flows | Find real implementations and live d

local filesystem code analysis with lsp integration

1 shared capability

Best For

✓AI agent developers building code-aware systems that need language-specific intelligence
✓Teams integrating Claude with existing LSP-based development infrastructure
✓Developers building MCP servers that need to expose language tooling capabilities
✓AI agents generating or editing code that need to respect language semantics and available APIs
✓Code generation workflows where completion context improves suggestion quality
✓Developers building Claude-powered code editors or IDE plugins
✓Interactive code editing workflows where Claude modifies code and needs real-time analysis
✓Code generation systems that need to validate generated code immediately

Known Limitations

⚠Latency overhead from protocol translation layer — each LSP request incurs JSON-RPC serialization/deserialization and MCP message wrapping (~50-200ms per round-trip depending on server responsiveness)
⚠LSP server availability and stability directly impacts capability — if underlying LSP crashes or becomes unresponsive, the MCP bridge cannot recover without manual restart
⚠No built-in caching of LSP responses — repeated queries for the same symbol or completion context will re-query the LSP server, potentially causing performance degradation with large codebases
⚠Limited to LSP capabilities exposed by the connected server — if an LSP server doesn't implement a feature (e.g., semantic tokens), the MCP bridge cannot provide it
⚠Completion quality depends entirely on the underlying LSP server's implementation — some LSP servers provide richer metadata than others
⚠No filtering or ranking of completions by relevance — returns raw LSP completion list, requiring client-side ranking logic

Requirements

Node.js 16+ (for MCP server runtime)At least one Language Server Protocol (LSP) server installed and accessible (e.g., typescript-language-server, pylsp, rust-analyzer)MCP client capable of connecting to stdio-based MCP servers (Claude Desktop, custom MCP client, or similar)Network or local IPC access to the LSP server (stdio, TCP socket, or Unix domain socket depending on LSP server configuration)LSP server with textDocument/completion capability (most modern LSP servers support this)File URI and cursor position (line and character) in the target fileLSP server must have the file indexed (typically requires the file to be opened via didOpen notification)LSP server with document synchronization support (all LSP servers support this)

Input / Output

Accepts: LSP request parameters (file URIs, positions, query strings, code snippets), MCP tool call arguments (serialized LSP method names and parameters), File paths and code context from the MCP client, File URI (e.g., file:///path/to/file.ts), Position object with line and character numbers (0-indexed), Optional completion context (trigger character, incomplete token), File URI to open/close, File content (full content for didOpen, incremental changes for didChange), Change range and new text for incremental updates, File URI and language ID to determine which LSP server to use, LSP server configuration (command, arguments, environment), File URI to query diagnostics for, Optional severity filter (error, warning, information, hint), File URI and position (line, character) of the symbol to navigate, Optional context (include declaration, include definition), File URI and position (line, character) to inspect, Optional context (surrounding code for better type inference), Query string (symbol name or partial match), Optional filters (symbol kind, file path pattern), File URI to format, Optional range (line and character range) to format only a selection, Optional formatting options (tab size, insert spaces, etc.), File URI and position (line, character) of the symbol to rename, New name string, File URI and range (line and character range) to query, Optional code action kind filter (e.g., 'quickfix', 'refactor', 'source'), Optional diagnostics context, File URI to analyze, Optional range (line and character range) to analyze only a selection

Produces: LSP response objects (completion items, diagnostics, hover information, symbol definitions), Structured JSON containing code intelligence results (type information, references, implementations), Diagnostic arrays with severity levels and fix suggestions, Array of CompletionItem objects (label, kind, detail, documentation, insertText, sortText), Completion metadata (isIncomplete flag indicating more results available), LSP notifications (no direct output, but enables downstream LSP features), Implicit output through updated diagnostics and code intelligence, Capability information for each connected LSP server, Routing decisions mapping file types to LSP servers, Array of Diagnostic objects (range, message, severity, code, source, relatedInformation), Diagnostic metadata including suggested fixes (CodeAction objects), Array of Location objects (file URI and range) for definitions or references, LocationLink objects with additional context (originSelectionRange, targetRange, targetSelectionRange), Hover object containing contents (markdown or plaintext) and optional range, Type information and documentation as formatted text, Array of SymbolInformation objects (name, kind, location, containerName), Workspace symbol results with file URIs and ranges, Array of TextEdit objects describing formatting changes (range and new text), Formatted code as a sequence of edits to apply, WorkspaceEdit object containing TextEdit arrays for each affected file, Document changes describing all necessary modifications across the codebase, Array of CodeAction objects (title, kind, edit, command, diagnostics), Command objects describing actions that require execution, WorkspaceEdit objects for actions that modify code, SemanticTokens object containing token data (encoded as relative positions and token type/modifier indices), Token type and modifier information describing semantic properties

UnfragileRank

Adoption45%(30% weight)

Quality23%(25% weight)

Ecosystem45%(25% weight)

Match Graph10%(15% weight)

Freshness75%(5% weight)

UnfragileRank is computed from adoption signals, documentation quality, ecosystem connectivity, match graph feedback, and freshness. No artifact can pay for a higher rank.

Type: MCP Server

12 capabilities

Visit cclsp→

Package Details

npm

Registry

0.7.0

Version

9,204

Weekly Downloads

About

MCP server for accessing LSP functionality

Alternatives to cclsp

IntelliCode50Extension

AI-assisted development

Compare →

GitHub Copilot Chat53Extension

AI chat features powered by Copilot

Compare →

GitHub Copilot52Extension

Your AI pair programmer

Compare →

Claude Code for VS Code52Extension

Claude Code for VS Code: Harness the power of Claude Code without leaving your IDE

Compare →

Are you the builder of cclsp?

Claim this artifact to get a verified badge, access match analytics, see which intents users search for, and manage your listing.

Claim this artifact →Verification via email

Get the weekly brief

New tools, rising stars, and what's actually worth your time. No spam.

Data Sources

mcp registry

Looking for something else?

Search →

Capabilities12 decomposed

lsp-to-mcp protocol bridging with multi-language server support

Medium confidence

Solves for

Best for

AI agent developers building code-aware systems that need language-specific intelligence

Teams integrating Claude with existing LSP-based development infrastructure

Developers building MCP servers that need to expose language tooling capabilities

Requires

Node.js 16+ (for MCP server runtime)

At least one Language Server Protocol (LSP) server installed and accessible (e.g., typescript-language-server, pylsp, rust-analyzer)

MCP client capable of connecting to stdio-based MCP servers (Claude Desktop, custom MCP client, or similar)

Limitations

LSP server availability and stability directly impacts capability — if underlying LSP crashes or becomes unresponsive, the MCP bridge cannot recover without manual restart

No built-in caching of LSP responses — repeated queries for the same symbol or completion context will re-query the LSP server, potentially causing performance degradation with large codebases

What makes it unique

vs alternatives

code completion and intellisense via lsp textdocument/completion

Medium confidence

Solves for

Best for

AI agents generating or editing code that need to respect language semantics and available APIs

Code generation workflows where completion context improves suggestion quality

Developers building Claude-powered code editors or IDE plugins

Requires

LSP server with textDocument/completion capability (most modern LSP servers support this)

File URI and cursor position (line and character) in the target file

LSP server must have the file indexed (typically requires the file to be opened via didOpen notification)

Limitations

Completion quality depends entirely on the underlying LSP server's implementation — some LSP servers provide richer metadata than others

No filtering or ranking of completions by relevance — returns raw LSP completion list, requiring client-side ranking logic

Requires file to be open and indexed by the LSP server — completions for unsaved or newly created files may be incomplete

What makes it unique

vs alternatives

document and workspace synchronization with lsp didopen, didchange, didclose notifications

Medium confidence

Solves for

Best for

Interactive code editing workflows where Claude modifies code and needs real-time analysis

Code generation systems that need to validate generated code immediately

Developers building Claude-powered code editors with live analysis

Requires

LSP server with document synchronization support (all LSP servers support this)

MCP client that can track file changes and send notifications

File URI and content for each file being synchronized

Limitations

Synchronization overhead — each file change requires an LSP notification, which can impact performance with rapid edits

No built-in conflict resolution — if multiple clients modify the same file, synchronization state may become inconsistent

LSP server may have stale state if notifications are lost or reordered — requires careful message ordering

What makes it unique

vs alternatives

Enables real-time LSP analysis on in-memory file changes without requiring disk I/O, compared to approaches that require saving files to disk before analysis.

multi-language server orchestration and capability negotiation

Medium confidence

Solves for

Best for

Polyglot development teams working with multiple languages in a single codebase

Monorepo environments with code in multiple languages

Developers building universal code intelligence tools

Requires

Multiple LSP servers installed and configured (one per language)

File type to language mapping (file extension or language ID)

Configuration specifying which LSP server to use for each language

Limitations

Complexity increases with each additional LSP server — managing multiple server connections adds operational overhead

Resource consumption scales with number of servers — each LSP server consumes memory and CPU, which can be problematic on resource-constrained systems

No built-in load balancing or failover — if one LSP server crashes, that language becomes unavailable

What makes it unique

vs alternatives

diagnostic collection and code quality analysis via lsp textdocument/publishdiagnostics

Medium confidence

Solves for

Best for

Code quality automation workflows that need to understand existing issues before suggesting changes

AI-assisted debugging where Claude needs to see compiler/linter errors

Refactoring agents that must validate changes against the language server's analysis

Requires

LSP server with diagnostic support (most LSP servers implement this)

File must be opened in the LSP server (via didOpen notification) to receive diagnostics

MCP client must maintain a persistent connection to receive publishDiagnostics notifications

Limitations

Diagnostics are only available after the LSP server has analyzed the file — newly opened files may have stale or missing diagnostics until the server completes its analysis pass

No real-time diagnostic updates if the LSP server is slow or overloaded — diagnostic freshness depends on server performance

Diagnostic interpretation is language-specific — error codes and messages vary significantly across LSP servers, requiring client-side parsing for actionable insights

What makes it unique

vs alternatives

symbol definition and reference navigation via lsp textdocument/definition and textdocument/references

Medium confidence

Solves for

Best for

Code refactoring agents that need to understand symbol usage across a codebase

Developers building code navigation features in Claude-powered IDEs

Codebase analysis workflows that require understanding symbol relationships

Requires

LSP server with textDocument/definition and textDocument/references capability

File URI and cursor position (line and character) pointing to the symbol

LSP server must have indexed the codebase (typically requires opening files or running a workspace initialization)

Limitations

Definition resolution depends on LSP server's indexing — may fail for dynamically generated code or symbols from external packages not in the workspace

Reference finding can be slow on large codebases — some LSP servers may timeout or return incomplete results for heavily-used symbols

No built-in filtering of results — returns all references including comments and strings, requiring client-side filtering for actionable results

What makes it unique

vs alternatives

hover information and type inspection via lsp textdocument/hover

Medium confidence

Solves for

Best for

Code generation workflows where Claude needs to understand symbol types before suggesting usage

Interactive code exploration where Claude explains code to users

Type-aware code completion and suggestion systems

Requires

LSP server with textDocument/hover capability

File URI and cursor position (line and character) pointing to the symbol

LSP server must have indexed the file and its dependencies

Limitations

Hover information quality varies by LSP server — some servers provide rich markdown documentation while others return minimal type information

No caching of hover results — repeated queries for the same symbol will re-query the LSP server

Hover information is position-dependent — the same symbol may have different hover information in different contexts (e.g., overloaded functions)

What makes it unique

vs alternatives

workspace symbol search via lsp workspace/symbol

Medium confidence

Solves for

Search for a function or class by name across the entire codebaseDiscover available APIs and exported symbols in a workspaceUnderstand codebase structure by exploring symbol hierarchies

Best for

Code generation agents that need to discover available functions and classes to use

Codebase exploration workflows where Claude needs to understand what's available

Refactoring tools that need to find all instances of a symbol across the workspace

Requires

LSP server with workspace/symbol capability

Workspace initialized with LSP server (typically requires opening a folder or project root)

Search query string (symbol name or partial name)

Limitations

Search performance degrades with large workspaces — some LSP servers may timeout or return truncated results for broad queries

Symbol search is typically fuzzy and may return many false positives — requires client-side filtering and ranking

Results depend on LSP server's indexing completeness — may miss symbols from unopened files or excluded directories

What makes it unique

vs alternatives

code formatting and style normalization via lsp textdocument/formatting

Medium confidence

Solves for

Best for

Code generation workflows where Claude needs to format generated code before returning it

Style normalization tasks where code must conform to project standards

Developers building Claude-powered code editors with formatting support

Requires

LSP server with textDocument/formatting capability

File URI and optional range (if formatting only a selection)

LSP server must have a formatter configured (e.g., prettier for JavaScript, black for Python)

Limitations

Formatting quality depends on the LSP server's formatter integration — some LSP servers may not have formatters configured

Formatting can be slow on large files — some formatters may timeout or return incomplete results

No preview of formatting changes — must apply TextEdits to see the result

What makes it unique

vs alternatives

Applies the project's actual configured formatter (prettier, black, rustfmt) rather than a generic formatter, ensuring generated code matches the project's style conventions exactly.

rename refactoring with cross-file impact analysis via lsp textdocument/rename

Medium confidence

Solves for

Best for

Refactoring agents that need to rename symbols safely across large codebases

Code transformation workflows where consistency is critical

Developers building Claude-powered refactoring tools

Requires

LSP server with textDocument/rename capability

File URI and cursor position (line and character) pointing to the symbol to rename

New name for the symbol

Limitations

Rename operations can be slow on large codebases — some LSP servers may timeout when computing all affected files

Rename may fail if the new name conflicts with existing symbols — requires client-side validation

No preview of rename changes — must inspect the WorkspaceEdit to understand the impact

What makes it unique

Leverages LSP's semantic understanding to compute rename impact across the entire workspace, ensuring all references are updated consistently. Returns a WorkspaceEdit that can be applied atomically.

vs alternatives

code action and quick fix suggestions via lsp textdocument/codeaction

Medium confidence

Solves for

Best for

Code quality automation where Claude needs to apply LSP-suggested fixes

Refactoring workflows that leverage language-specific refactoring actions

Error resolution agents that automatically fix common issues

Requires

LSP server with textDocument/codeAction capability

File URI and range (start and end positions) to query for code actions

Optional context (diagnostics at the range, code action kind filter)

Limitations

Code action availability depends on the LSP server's implementation — not all LSP servers provide code actions for all error types

Code actions may have side effects or unintended consequences — requires careful review before applying

No built-in ranking or filtering of code actions — returns all available actions, requiring client-side selection logic

What makes it unique

vs alternatives

semantic token highlighting and syntax analysis via lsp textdocument/semantictokens

Medium confidence

Solves for

Best for

Code analysis workflows that need semantic understanding beyond syntax

Developers building semantic-aware code editors or analysis tools

Code generation agents that need to understand code structure semantically

Requires

LSP server with textDocument/semanticTokens capability

File URI and optional range (if querying only a portion of the file)

LSP server must have indexed the file

Limitations

Semantic token support varies by LSP server — not all LSP servers implement this capability

Semantic token computation can be expensive on large files — may impact performance

Token information is position-dependent and may change as code is edited — requires re-querying after edits

What makes it unique

Exposes LSP's semantic token protocol which provides token-level semantic information (type, modifiers) beyond simple syntax highlighting. Enables fine-grained semantic analysis of code structure.

vs alternatives

Capabilities are decomposed by AI analysis. Each maps to specific user intents and improves with match feedback.

Alternatives to cclsp

IntelliCode50Extension

AI-assisted development

Compare →

GitHub Copilot Chat53Extension

AI chat features powered by Copilot

Compare →

GitHub Copilot52Extension

Your AI pair programmer

Compare →

Claude Code for VS Code52Extension

Claude Code for VS Code: Harness the power of Claude Code without leaving your IDE

Compare →

cclsp

Capabilities12 decomposed

lsp-to-mcp protocol bridging with multi-language server support

code completion and intellisense via lsp textdocument/completion

document and workspace synchronization with lsp didopen, didchange, didclose notifications

multi-language server orchestration and capability negotiation

diagnostic collection and code quality analysis via lsp textdocument/publishdiagnostics

symbol definition and reference navigation via lsp textdocument/definition and textdocument/references

hover information and type inspection via lsp textdocument/hover

workspace symbol search via lsp workspace/symbol

code formatting and style normalization via lsp textdocument/formatting

rename refactoring with cross-file impact analysis via lsp textdocument/rename

code action and quick fix suggestions via lsp textdocument/codeaction

semantic token highlighting and syntax analysis via lsp textdocument/semantictokens

Related Artifactssharing capabilities

Language Server

cclsp

Windmill

@theia/ai-mcp-server

Zed

octocode-mcp

Best For

Known Limitations

Requirements

Input / Output

UnfragileRank

Package Details

About

Categories

Alternatives to cclsp

Are you the builder of cclsp?

Get the weekly brief

Data Sources

cclsp

Capabilities12 decomposed

lsp-to-mcp protocol bridging with multi-language server support

code completion and intellisense via lsp textdocument/completion

document and workspace synchronization with lsp didopen, didchange, didclose notifications

multi-language server orchestration and capability negotiation

diagnostic collection and code quality analysis via lsp textdocument/publishdiagnostics

symbol definition and reference navigation via lsp textdocument/definition and textdocument/references

hover information and type inspection via lsp textdocument/hover

workspace symbol search via lsp workspace/symbol

code formatting and style normalization via lsp textdocument/formatting

rename refactoring with cross-file impact analysis via lsp textdocument/rename

code action and quick fix suggestions via lsp textdocument/codeaction

semantic token highlighting and syntax analysis via lsp textdocument/semantictokens

Related Artifactssharing capabilities

Language Server

cclsp

Windmill

@theia/ai-mcp-server

Zed

octocode-mcp

Best For

Known Limitations

Requirements

Input / Output

UnfragileRank

Package Details

About

Categories

Alternatives to cclsp

Are you the builder of cclsp?

Get the weekly brief

Data Sources