microsoft/language-server-protocol

★ 12,811HTMLAudience · developerComplexity · 1/5Setup · easy

Mindmap

mindmap
  root((LSP))
    What it does
      Editor integration standard
      Write once run anywhere
    Features covered
      Autocomplete
      Error highlighting
      Go to definition
      Rename refactoring
    Who uses it
      Editor teams
      Language tool authors
    This repo
      Specification only
      Protocol website
      Extension proposals

mindmap root((LSP)) What it does Editor integration standard Write once run anywhere Features covered Autocomplete Error highlighting Go to definition Rename refactoring Who uses it Editor teams Language tool authors This repo Specification only Protocol website Extension proposals

Click or tap to explore — scroll the page freely

Things people build with this

USE CASE 1

Read the protocol specification to understand how to build a language server for a new programming language that works in VS Code, Neovim, and other editors.

USE CASE 2

Browse the list of existing language server implementations to find one for your language of choice.

USE CASE 3

Propose an extension to the protocol by submitting a pull request to the specification repository.

USE CASE 4

Use the protocol website's documentation to understand what messages are supported when debugging editor integrations.

Tech stack

HTML

Getting it running

Difficulty · easy Time to first run · 5min

This is a specification document, not software, no installation needed, read the spec or website directly.

In plain English

This repository is the home of the Language Server Protocol, a standard created by Microsoft that defines how code editors communicate with programming language tools. Before this standard existed, every editor (like VS Code, Vim, or Emacs) had to build its own custom integration for every programming language it wanted to support. That meant a lot of repeated work: if you wanted Go support in five different editors, someone had to write five separate plugins. The Language Server Protocol solves this by defining a shared communication format. A language tool, called a language server, implements features like autocomplete, error highlighting, go-to-definition, and rename refactoring once, using this protocol. Any editor that also speaks the protocol can then use that tool directly, with no additional custom code. This is why VS Code, Neovim, and many other editors can all support dozens of languages without each editor team building everything from scratch. This particular repository holds the specification document itself, not a software library or implementation. It defines what messages can be sent, what format they use, and what each one means. The repo also serves the protocol's website, which includes a more readable version of the specification and a list of known language server implementations for various programming languages. Contributions to the specification, including proposed extensions, are accepted through GitHub pull requests.

Copy-paste prompts

Prompt 1

I'm building a language server for a custom scripting language. Using the Language Server Protocol specification, what messages do I need to implement to support autocomplete, hover documentation, and go-to-definition in VS Code?

Prompt 2

Explain the Language Server Protocol initialization handshake: what messages are exchanged between the editor and the language server when a user opens a file, and what capabilities should my server declare?

Prompt 3

I want to add a custom code action to my LSP language server. Walk me through the textDocument/codeAction request and response format from the spec.

Prompt 4

What is the difference between textDocument/publishDiagnostics and textDocument/diagnostic in the Language Server Protocol, and when should I use each?

Open on GitHub → Explain another repo

← microsoft on gitmyhub — every repo by this author, as a profile.

Verify against the repo before relying on details.