想象一下构建一个可以在任何地方运行的 API 服务器，就像 LSP 为程序员所做的那样，MCP 会是下一个吗？

在 2016 年之前，在 IDE 中支持编程语言非常麻烦。

每个编辑器都必须为它想要支持的每种语言构建自己的一套工具。

语法高亮、自动补全、代码检查，所有这些都是定制构建的。

这导致了体验的碎片化。

像 JavaScript 这样的语言在某个编辑器中可能感觉很流畅，但在另一个编辑器中却不完整。

而且，如果你使用像 VIM 这样的基于终端的编辑器，

你通常只能获得有限的工具，或者根本没有。

当 @Microsoft 推出 Language Server Protocol (LSP) 时，这种情况发生了改变。

LSP 创建了一种标准的通信方式，而不是让编辑器和语言从头开始构建集成。

现在，语言可以提供一个单一的 LSP 服务器，

任何带有 LSP 客户端的编辑器都可以连接。

因此，你不需要构建一个“用于 VSCode 的 Go 插件”和一个“用于 Sublime 的 Go 插件”，

你只需要构建一个 Go LSP 服务器，它就可以在任何地方工作。对于开发者来说，这意味着在不同的编辑器中可以获得更一致的功能。

对于语言维护者来说，这简化了支持新工具的工作。

对于编辑器来说，这在一夜之间解锁了大量的语言。

今天，LSP 使语法高亮和自动补全等工具感觉无缝，

无论你使用哪种语言，或者你喜欢哪个编辑器。

这是一个简单的可视化图，显示了 pre-LSP 和 post-LSP 设置之间的区别：

今天，LSP 已经悄然改变了开发工具的工作方式。

即使是小众编程语言现在也可以在流行的编辑器中提供出色的开发者体验。

他们不需要与像 VSCode 或 Cursor 这样的 IDE 达成直接协议，

他们只需要构建一个 LSP 服务器，就可以加入了。

在开发者方面，这种转变也很重要。

我们不再根据语言支持来选择 IDE。

我们根据编辑器的优势来选择，

比如 Cursor 的界面或其 AI 功能。

也就是说，LSP 的采用并非普遍。

像 JetBrains 或 Apple 的 Xcode 这样的一些生态系统仍然偏爱他们自己的协议。

但对于大多数人来说，LSP 正在成为编辑器和语言工具连接的标准方式。

现在，在 2025 年，MCP 正在进入对话。
对我们来说，它感觉非常熟悉。

如果 LSP 的结构帮助启发了它，这并不奇怪。

这是比较：
将“编程语言”替换为像 Stripe 或 Supabase 这样的第三方 API，
并将“IDE”替换为 AI 聊天客户端，@Cursor , Claude, @OpenAI , @vercel , 或 @LangChainAI 。
这就是 MCP 的样子。

如果 MCP 取得成功，其影响可能是巨大的。
Supabase 不需要为每个 AI 客户端单独集成。

它只需要构建一个 @supabase MCP 服务器，
任何 MCP 兼容的客户端都可以连接。
这对小型团队来说也可能是一个游戏规则改变者。
他们可以在任何 AI 平台上向用户提供全功能的工具，
而无需维护五个不同的集成。

它甚至可能使集成市场变得过时。
如果体验在各个平台上都是原生的，
为什么还需要手动浏览和安装插件？

最终用户将受益最多。

无论他们使用哪种 AI 工具，他们都会获得一致的体验。

我们认为 MCP 具有真正的潜力。

并且在 @AnthropicAI 与 @State_Of_Mika 的共同领导下。
它可能成为将第三方 API 与 LLM 连接的新标准。

如果您想知道 LSP 如何解决类似的挑战，
评论 gMika，我们将向您发送指南。