LSP stands for Language Server Protocol, a set of rules that lets a text editor ask a separate program questions about the code on screen: where a function is defined, what type a variable holds, which lines contain errors. The editor acts as the client. The separate program, which understands one programming language deeply, is the language server. Between them runs JSON-RPC, a lightweight message format that wraps every question and answer in a JSON object. The protocol exists because before it arrived, each editor needed a bespoke integration for each language, and the work grew as the product of the two numbers rather than their sum.

That arithmetic is the whole argument. A 2025 paper in the Journal of Systems and Software by Federico Bruzzone, Walter Cazzola and Luca Favalli states the reduction formally: supporting L languages across E editors costs L times E integrations without a shared protocol and L plus E with one. Advertising technology has no reason to care about code completion. It has reason to care about LSP, because the Model Context Protocol now sitting underneath most agentic advertising tooling was modelled on it, and inherited its structure, its transport and several of its unresolved problems.

How the protocol works

The base protocol is deliberately unremarkable. Each message carries a header part and a content part separated by a carriage return and line feed, an arrangement the specification calls comparable to HTTP. The header carries a Content-Length field giving the byte count of what follows. The content part is a JSON-RPC 2.0 payload. Three message shapes exist: a request, which must receive a response; a response, carrying either a result or an error; and a notification, which expects nothing back.

Transport is left open. Most servers run as a child process of the editor and communicate over standard input and output, which is why a language server is usually invisible in use. Named pipes and TCP sockets are equally valid.

The session opens with an initialize request carrying a ClientCapabilities object describing what the editor can handle. The server replies with ServerCapabilities describing what it offers, and the client confirms with an initialized notification. Nothing else may be sent until that exchange completes. Capabilities keep the protocol compatible across versions: a server that cannot answer workspace symbol queries omits the flag, and a client receiving capabilities it does not recognise is instructed to ignore them rather than fail. Dynamic registration lets either side add capabilities mid-session.

What the protocol carries

Once open, the client streams document state to the server through notifications. The textDocument/didOpen notification hands over the full text of a file and its version number. Later edits arrive as textDocument/didChange, either as complete replacements or as incremental ranges, negotiated at initialization. The server, not the file system, becomes the authority on what the document currently contains.

Feature requests then flow both ways. From client to server: textDocument/completion for suggestions, hover for type information, definition and references for navigation, rename for safe refactoring, codeAction for quick fixes, documentSymbol for file structure, and formatting. From server to client: textDocument/publishDiagnostics, a notification pushing errors and warnings unasked, which is how underlines appear while typing rather than after saving.

Positions are expressed as a zero-based line number and a character offset within that line, and the offset unit matters more than it sounds. Until version 3.17, offsets were counted in UTF-16 code units, so a character outside the basic multilingual plane counts as two. Since 3.17 the client advertises an array of encodings through general.positionEncodings and the server picks one, but UTF-16 remains the only mandatory option and the default when nothing is stated.

Two utility messages round out the base protocol: a cancel request, letting a client abandon an in-flight query when the cursor moves, and a progress notification for long operations.

Origin and evolution

The protocol came out of Microsoft's work on Visual Studio Code. Erich Gamma, a Microsoft distinguished engineer, described the trigger in the announcement press release: the team defined a common protocol only after integrating the OmniSharp server for C# and a TypeScript server into VS Code by two separate ad hoc mechanisms. Having done the job twice, a shared contract looked cheaper than a third.

Codenvy, Microsoft and Red Hat announced the collaboration on 27 June 2016 in San Francisco, during DevNation at Red Hat Summit. The specification went onto GitHub under Creative Commons and MIT licences. Tyler Jewell, then Codenvy chief executive and Eclipse Che project lead, framed the problem as lock-in, saying most programming languages had historically been optimised for a single tool, which limited both the editors developers could use and the audience language providers could reach. Eclipse Che and VS Code shipped support at launch, with JSON, C++ and PowerShell servers available and C#, Xtext, R, JavaFX and CSS promised for later that year. Red Hat open sourced a standalone Java language server and proposed donating it to the Eclipse Foundation.

Version numbering moved in increments. Version 3.16 added semantic tokens, call hierarchy, linked editing, monikers and file operation events. Version 3.17 added type hierarchy, inline values, inlay hints, notebook document support, negotiated position encoding and a machine-readable meta model describing the protocol itself. Version 3.18 is where the documentation contradicts itself: the landing page calls 3.18 the latest version, the specification navigation labels 3.17 current and 3.18 upcoming, and the 3.18 document says it is under development.

Why it matters for the marketing community

The connection runs through the Model Context Protocol. The MCP specification published on 25 November 2025 states directly that MCP takes some inspiration from the Language Server Protocol, and that it standardises integration of context and tools into AI applications the way LSP standardised language support across development tools. The borrowings are structural: JSON-RPC 2.0 messages, capability negotiation at connection time, and a server written once that any compliant client can consume.

That inherited design is now load-bearing in advertising. Google's Ads API team released an open-source MCP server on 7 October 2025, read-only, after an experimental Google Analytics server in July. Amazon Ads followed in November 2025, Meta opened its ads MCP server to any developer in July 2026, and X shipped a server exposing 23 tools, ten of them able to write to live accounts. The pattern reached research vendors, with Cint compressing a 20-market study setupinto a single run, and analytics tools such as SISTRIX moving from API keys to OAuth. Yahoo DSP exposes audience metadata over MCP to external agents.

The protocol layer also became a governance question. Google's revised developer policies of 31 August 2026 name MCP servers explicitly among the intermediate layers now prohibited as programmatic proxies, a definition set out in PPC Land's explainer on the term. Cloudflare, meanwhile, began classifying MCP traffic using a protocol version header so enterprises can block calls that bypass approved gateways.

Limitations and disputes

The UTF-16 default is the most cited design regret. The clangd project, which maintains the C and C++ language server for LLVM, calls the choice a legacy of VS Code's JavaScript implementation and shipped a non-standard UTF-8 extension for years before deprecating it in favour of the 3.17 negotiation.

Extensions are the deeper structural tension. The protocol covers what most editors have in common, so anything more specialised leaves the specification. Servers reach for custom commands or vendor-prefixed methods, and each one reintroduces the coupling the protocol was built to remove. Bruzzone and colleagues note that overlapping implementations of linguistic components remain an issue almost ten years on, and that the standard does not encode project dependency graphs at all. A version-labelling problem sits alongside it: as of September 2026 the same specification is described as current and as under development on adjacent pages of one site.

Disambiguation

Model Context Protocol. MCP connects language models to tools and data. It borrowed LSP's transport and negotiation model but targets a different client population, and has diverged: MCP removed sessions in a 2026 revision, where LSP's stateful initialize handshake remains mandatory.

Language Server Index Format. LSIF, published alongside LSP by the same team, stores precomputed navigation data as a graph so code intelligence works in a web interface without a running server. LSP answers live questions, LSIF questions asked of a snapshot.

Layered Service Provider. An unrelated Windows networking component inserted into the Winsock stack.

Language service provider. In localisation, an LSP is a translation vendor. Marketing teams commissioning multilingual campaigns meet this meaning more often than the protocol.

Recent developments

The most consequential recent change is that AI coding agents became LSP clients. Anthropic added a language server tool to Claude Code in version 2.0.74 in December 2025, initially behind an environment flag and later documented in the changelog, giving the agent go-to-definition, find-references, document symbol, hover and diagnostics operations. Community marketplaces now distribute servers for more than twenty languages against it.

The reason is accuracy rather than convenience. According to benchmarks published by CircleCI in June 2026, a smaller model relying on text search alone found nine of eleven references to one symbol and 249 of 260 to another, while the same model using a language server found every reference on every task.

That closes a loop. LSP was built so tools could ask a language server what code means. Agents now ask the same question through the same protocol, while the tools they use to buy advertising speak a protocol modelled on it. Explaining interoperability covers how competing agentic standards are converging, and the IAB Tech Lab's ARTF specification shows what happens when a third protocol is layered on both.

Timeline

  • June 2016: Microsoft, Red Hat and Codenvy announce the Language Server Protocol at DevNation in San Francisco on 27 June, publishing the specification on GitHub under Creative Commons and MIT licences.
  • August 2016: The Eclipse Foundation receives the JDT Language Server project proposal, bringing Java support to the protocol.
  • December 2020: Version 3.16 adds semantic tokens, call hierarchy, linked editing, monikers and file operation events.
  • May 2022: Version 3.17 adds type hierarchy, inline values, inlay hints, notebook document support, a machine-readable meta model and negotiated position encoding.
  • 25 November 2024: Anthropic introduces the Model Context Protocol, citing LSP as a design influence.
  • 7 October 2025: Google releases an open-source MCP server for the Google Ads API.
  • December 2025: Claude Code version 2.0.74 adds a language server tool, making an AI coding agent an LSP client.
  • 13 November 2025: Amazon Ads opens a closed beta of its own MCP server.
  • 29 April 2026: Meta launches Ads AI Connectors with write access to campaign creation.
  • June 2026: CircleCI publishes benchmarks comparing language server queries against text search for coding agents.
  • 16 July 2026: Meta opens its ads MCP server to any developer holding a Meta app.
  • 24 August 2026: X ships an Ads MCP server exposing 23 tools, ten of them capable of writing to live accounts.
  • 31 August 2026: Google prohibits programmatic proxies, naming MCP servers among the intermediate layers covered.
  • September 2026: LSP 3.18 remains labelled both as the latest version and as under development on Microsoft's specification site.

Summary

Who: Microsoft defined the protocol out of the Visual Studio Code team under Erich Gamma, and announced it jointly with Red Hat and Codenvy. Editor vendors implement the client side, language communities implement servers, and AI coding agents have since joined as clients.

What: An open specification for JSON-RPC 2.0 messages exchanged between a development tool and a language server that supplies code intelligence, using capability negotiation so that partial implementations interoperate rather than break.

When: Announced 27 June 2016. Version 3.16 landed in 2020, version 3.17 in 2022, and version 3.18 remains ambiguously labelled as of September 2026.

Where: In editors and IDEs including VS Code, Eclipse, Neovim and JetBrains products, and increasingly inside AI coding agents that query language servers directly.

Why: Building language support separately for every editor scales as a product rather than a sum. LSP collapsed that cost, and the same argument, applied to language models and their tools, produced the Model Context Protocol now carrying advertising automation.