Language Server Protocol (LSP)

The Language Server Protocol (LSP) defines how a development tool, such as an editor or IDE, communicates with a language server that provides smart features for a programming language. The official specification site states that historically features like autocomplete, go-to-definition, and find-all-references “had to be repeated for each development tool, as each tool provides different APIs for implementing the same feature.” LSP standardizes that communication so a single language server can be reused across many tools, and a single tool can support many languages with minimal effort.

LSP was originally developed by Microsoft for Visual Studio Code. As the project’s history relates, the Visual Studio Code team found itself repeatedly re-implementing the same language smarts, and after integrating the OmniSharp server for C# and a TypeScript server into the editor, it defined a common protocol to factor that work out. On June 27, 2016, Microsoft, Red Hat, and Codenvy announced a collaboration to standardize the protocol so it could be adopted across editors and IDEs beyond VS Code, including Eclipse Che.

Technically, LSP is layered on JSON-RPC. The VS Code announcement notes that communication between editor and server “takes place over JSON-RPC” and happens many times during a typical editing session. The specification requires every message to conform to JSON-RPC 2.0 and defines three message types: requests that expect a response, responses carrying a result or error, and notifications that behave like events. Requests such as textDocument/completion, textDocument/definition, and textDocument/hover carry document positions, and the server replies with the corresponding language intelligence.

The deeper significance of LSP is the way it reframed editor tooling economics. Before LSP, supporting M languages in N editors required up to M times N separate integrations, since each editor had its own extension API and each language needed bespoke analysis. By inserting a common protocol in the middle, the problem becomes M language servers plus N editor clients, an M plus N relationship. This decoupling let language communities invest in one high-quality server and reach every editor that speaks LSP.

The protocol has gone through several versions, reaching 3.17 as documented on the specification site, adding capabilities such as semantic tokens, call hierarchy, and inlay hints over time. Its success spawned a sibling for debugging, the Debug Adapter Protocol, built on the same decoupling idea. LSP is now implemented by a wide range of editors and by language servers for nearly every mainstream programming language, making it one of the most consequential standards in modern developer tooling.