想像一下，建立一個可以在任何地方運作的 API 伺服器，就像 LSP 為程式設計師所做的那樣，MCP 會是下一個嗎？

在 2016 年之前，在 IDE 中支援程式語言非常麻煩。

每個編輯器都必須為其想要支援的每種語言建立自己的一套工具。

語法高亮、自動完成、程式碼檢查，它們都是客製化的。

這導致了體驗的碎片化。

像 JavaScript 這樣的語言在一個編輯器中可能感覺很順暢，但在另一個編輯器中則不完整。

如果你使用像 VIM 這樣的基於終端的編輯器，

你通常會發現工具非常有限，或者根本沒有。

當 @Microsoft 引入 Language Server Protocol (LSP) 時，這種情況發生了改變。

LSP 建立了一種標準的溝通方式，而不是讓編輯器和語言從頭開始建立整合。

現在，語言可以提供單一的 LSP 伺服器，

任何具有 LSP 客戶端的編輯器都可以連接。

因此，你只需要建立一個 Go LSP 伺服器，它就可以在任何地方運作，而不必建立一個「VSCode 的 Go 外掛程式」和一個「Sublime 的 Go 外掛程式」。對於開發人員來說，這意味著在不同的編輯器中，功能更加一致。

對於語言維護者來說，這簡化了支援新工具的工作。

對於編輯器來說，這在一夜之間解鎖了長長的一串語言列表。

今天，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，我們將向你發送指南。