I was deeply involved with the Language Server Protocol (LSP) from its earliest days at Red Hat, one of the instrumental organizations in driving LSP adoption. During that time, I contributed to several key implementations, including the second-ever language server—the Java Language Server—and the widely adopted YAML Language Server. These projects became benchmarks for reliability and widespread adoption in developer communities.
Why MCP Matters
Given my experience with LSP, I’m enthusiastic about the growing interest in the Model Context Protocol (MCP). However, I am concerned that the valuable lessons learned from LSP are not being effectively applied to MCP.
When LSP emerged, it transformed programming language tooling. Specifically, it allowed language experts to implement sophisticated, language-specific intelligence consistently across different IDEs and editors. LSP created an abstraction enabling the same compiler development teams to directly support any IDE or editor.
MCP provides an analogous abstraction between AI tools and agents and their computing environments. However, the type of abstraction provided by LSP—deep, specialized programming language expertise—is significantly more complex to integrate and replicate compared to the API interactions primarily targeted by MCP. This difference currently makes MCP’s value proposition lower than that of LSP, which raises ongoing questions about whether MCP provides substantial value beyond existing APIs.
Critical Risks with Current MCP Implementations
Unfortunately, MCP carries forward several critical shortcomings that were also issues with LSP. One significant oversight with LSP was the lack of standardized packaging. Visual Studio Code—the hero product driving LSP adoption—provided its own method for packaging extensions, but this approach was not easily transferable to other platforms. The absence of standardized, secure packaging made LSP implementations vulnerable to supply chain attacks. Even VS Code’s extension packaging was not originally designed with supply chain security in mind, proving vulnerable at times.
The risk is even greater with MCP due to its broader potential access and integration to critical systems. Organizations face significant security risks if they adopt MCP directly from third-party sources without a robust packaging solution that includes secure attestations and digital signatures.
Additionally, LSP is defined to operate on single-user desktop environments without built-in multi-tenancy, a feature that simplifies implementation, but limits use in cloud environments. This lack of multi-tenancy poses a much larger challenge for MCP, as MCP implementations are more likely to run in multi-tenant environments requiring robust authentication and authorization.
Without addressing these critical issues related to packaging, secure supply chains, multi-tenancy, authentication, and authorization, the overall value and viability of MCP will continue to be questioned.
At Jozu, we are uniquely positioned to address these critical MCP adoption challenges. With extensive experience gained from pioneering work on LSP and our development of KitOps—a proven open-source solution trusted by enterprises for securely packaging and deploying AI/ML workloads—we are prepared to solve MCP’s most pressing security and packaging issues. Partnering with us will help your organization significantly reduce exposure to supply chain risks while accelerating secure MCP adoption.
Your Opportunity: Become a Design Partner
We’re currently seeking a limited number of design partners to join us in shaping the future of MCP. As a design partner, you’ll gain exclusive access to our solution, have direct influence on product direction, and receive expert guidance on securely implementing MCP in your organization.
Spots are limited—contact today to secure your position.
Top comments (0)