Klient (edytor) uruchamia serwer językowy jako osobny proces i komunikuje się z nim przez stdin/stdout (lub socket / pipe) używając JSON-RPC 2.0 z nagłówkiem Content-Length. Po inicjalizacji (initialize / initialized) klient wysyła powiadomienia o zmianach buforów (textDocument/didOpen, didChange, didClose) i żądania o funkcje semantyczne (textDocument/completion, hover, definition, references, codeAction, rename, formatting). Serwer zwraca odpowiedzi lub powiadomienia push (np. textDocument/publishDiagnostics z błędami i ostrzeżeniami). Cykle życia, capability negotiation i wersjonowanie dokumentów są częścią specyfikacji.
Przed LSP każdy edytor musiał implementować integrację z każdym językiem osobno, co dawało kombinatoryczną eksplozję N×M wtyczek o nierównej jakości. LSP redukuje to do N + M: jeden serwer językowy obsługuje wszystkie edytory, jeden klient obsługuje wszystkie języki.
Strona kliencka protokołu — uruchamia serwer językowy jako podproces, śledzi otwarte bufory i tłumaczy interakcje użytkownika na żądania LSP.
Oficjalna
Implementacja specyficzna dla języka (np. rust-analyzer, gopls, pyright). Buduje i utrzymuje semantyczny model projektu — drzewa składniowe, typy, indeksy symboli — i odpowiada na żądania klienta.
Oficjalna
Standardowy JSON-RPC 2.0 z ramkowaniem przez nagłówek Content-Length. Najczęściej używa stdio; specyfikacja dopuszcza także sockety i named pipes.
Podczas wymiany initialize / initialized klient i serwer ogłaszają jakie funkcje wspierają (np. snippetSupport, hierarchicalDocumentSymbolSupport). Pozwala protokołowi ewoluować bez łamania starszych klientów lub serwerów.
Klient i serwer muszą zgadzać się co do wersji bufora — pomieszanie kolejności textDocument/didChange skutkuje przestarzałymi diagnostykami i błędnymi pozycjami zmian.
Klient musi sprawdzać capabilities ogłoszone przez serwer w odpowiedzi initialize — zakładanie funkcji, których serwer nie wspiera, kończy się błędami JSON-RPC.
Naiwne serwery skanują cały workspace przy każdej zmianie, co przy dużych monorepo prowadzi do wielosekundowych pauz w autouzupełnianiu.
Microsoft, Red Hat i Codenvy projektują wspólny protokół na bazie wcześniejszych prac OmniSharp.
Microsoft publikuje otwartą specyfikację Language Server Protocol w czerwcu 2016, wraz z implementacjami referencyjnymi w VS Code, Eclipse Che i Visual Studio.
Wersja 3.0 ustabilizowana; Vim (coc.nvim, vim-lsp), Emacs (lsp-mode), Sublime, Atom, JetBrains uzyskują wsparcie LSP.
LSP 3.16 dodaje semantic tokens, call hierarchy i moniker support — wzbogacając informację semantyczną dostępną dla klientów.
Cursor, Aider, Continue i Claude Code wykorzystują LSP do dostarczenia LLM semantycznego kontekstu o kodzie (definicje, referencje, diagnostyka), znacząco poprawiając jakość zmian generowanych przez modele.
