Enter your search text in the box above

Select a result to preview

LSP and the X-Protocol Family

#resources #resources/programming #resources/programming/architecture #resources/programming/dev-tools

LSP and the X-Protocol Family

A lineage of stable wire protocols that decouple editors/IDEs from language-specific or domain-specific backends. LSP (Language Server Protocol) is the canonical example, the one that proved the pattern. Since LSP shipped (2016), the same shape has been replicated for debuggers (DAP), build tools (BSP), AI agents (MCP, ACP), and others.

The collective term isn't formally established; "X-Protocol family" or "LSP-style protocols" works. Whatever the name, the pattern is one of the most successful architectural ideas in dev tooling history.

The M × N → M + N collapse

Pre-LSP: every editor needs custom integration with every language's compiler/analyser. M editors × N languages = M·N integrations. Adding a new editor means re-implementing N language integrations. Adding a new language means N editor integrations.

Post-LSP: every editor speaks LSP; every language ships an LSP server. M + N. New editor needs only an LSP client; new language needs only one LSP server. The combinatoric explosion collapses.

This is the killer insight. Once one party in the equation gets standardised, the other can scale linearly.

LSP — Language Server Protocol

Microsoft, announced June 27 2016. From the LSP Protocol History: VS Code had absorbed two language servers and the team wanted one common protocol. They started from the TypeScript server protocol, generalised, switched wire format to JSON-RPC, and standardised in collaboration with Red Hat and Codenvy.

What LSP provides:

The transport: JSON-RPC, framed by Content-Length: N\r\n\r\n headers, over stdio (or TCP, for remote scenarios).

Adoption was rapid. Within five years, every major editor (VS Code, Vim/Neovim, Emacs, Sublime, Helix, JetBrains' IDEs partially) had LSP clients. Every language with serious tooling shipped an LSP server (rust-analyzer, pyright, gopls, typescript-language-server, ...).

LSP is one of the rare standards that succeeded across editor wars. Microsoft built the protocol AND the canonical client (VS Code) AND multiple language servers — controlling all three sides made adoption easy. After ecosystem buy-in, Microsoft's control matters less; the protocol is now community-stewarded enough that VS Code being the dominant editor doesn't lock the protocol.

DAP — Debug Adapter Protocol

Same Microsoft lineage, slightly later (the DAP website spun out in 2018). Same shape applied to debuggers:

DAP-the-protocol is JSON-shaped, slightly different from strict JSON-RPC (uses seq + request_seq for correlation, has explicit event type). For most purposes treat it as JSON-RPC family.

Adoption: VS Code, nvim-dap, JetBrains (partially), Helix. Server side: codelldb, debugpy, dlv-dap, js-debug, lldb-dap, netcoredbg.

Lazydap is built on top of DAP. See Debug Adapter Protocol (DAP) for depth.

BSP — Build Server Protocol

Scala Center + JetBrains, v1.0.0 June 2018. From the announcement: "BSP is inspired by LSP… LSP abstracts over the language whereas BSP abstracts over the build tool."

Authored by Jorge Vicente Cantero, Ólafur Páll Geirsson (Scala Center) and Justin Kaeser (JetBrains). The pattern: editors talk to build tools (sbt, Bazel, Mill) via a common BSP protocol; the editor doesn't need to know the build tool's specifics.

Adoption: real but narrower than LSP. JetBrains and Metals (Scala) on the client side; Bazel, sbt, Mill on the server side. Hasn't crossed into broad-language adoption the way LSP has.

MCP — Model Context Protocol

Anthropic, November 2024. Created by David Soria Parra and Justin Spahr-Summers. The agent-era restatement of the X-Protocol pattern:

Wire: JSON-RPC over stdio (or HTTP+SSE). Capability negotiation. Tools describe themselves with names + descriptions + input schemas; LLM hosts list them and choose what to call.

Adoption was unusually fast. Within a year of launch: Microsoft, Google, OpenAI all officially adopted MCP. C# SDK partnered with Microsoft. Hundreds of MCP servers in the wild for popular APIs (GitHub, Slack, Postgres, ...).

MCP is now the de facto integration layer for AI agents. Whatever Anthropic's commercial fate, the protocol seems durable.

ACP — Agent Client Protocol

Zed, 2025. Open-source (Apache) at zed-industries/agent-client-protocol. Standardises editor ↔ coding agent the way LSP standardised editor ↔ language server.

The use case: you have a coding agent (Claude Code, Gemini CLI, Goose, OpenCode) running in your editor. The editor needs to display the agent's reasoning, accept its file edits, prompt for confirmations, etc. ACP defines that interface.

Adoption: Reference impl is Gemini CLI; supported by Claude Code (via SDK adapter), Goose, OpenCode, Kiro on the agent side; Zed, JetBrains, Neovim on the editor side. ACP Registry launched 2025. One of the few real LSP-shaped successes outside Microsoft's orbit.

This is "LSP for AI coding agents" — same idea, latest application.

Common shape across the family

Every member of the family shares:

If you're designing a new protocol of this shape, start by reading the LSP and MCP specs side by side. The common structural decisions are nearly identical; the domain-specific bits are what matter.

Why this pattern keeps replicating

Because the M × N problem keeps appearing in new contexts:

Whenever you see two ecosystems each with multiple members that need to integrate with each other, the X-Protocol pattern is the obvious solution. Anyone building in such a space should default to "design the standard protocol" before "build the integration."

Why mxr and lazydap matter to this pattern

Mxr is "LSP-style architecture for email clients." Lazydap is "DAP-style architecture for debugger CLIs." Neither IS one of these protocols, but both adopt the structural discipline:

When designing your own headless tool, the LSP / DAP / MCP / ACP specs are the canonical references for "how to do this well." The mistakes are documented in their issue trackers; the lessons are in their evolution.

Common pitfalls

See also