4-5 為什麼企業爭相推出 MCP 伺服器?

在之前的單元中，我們分別討論了什麼是 MCP (Model Context Protocol)，以及在 Curse 當中如何使用 MCP，並且如何開發自己的 MCP。在這個單元中，我們將進一步探討為什麼企業競相推出自己的 MCP 伺服器。

回顧 MCP

首先，讓我們回顧一下 MCP 的含義：

M (Model，模型): 指的是大家熟知的人工智慧模型，例如 GPT 模型或 Claude 模型。
C (Context，脈絡): 指的是提供給模型的額外資料。
P (Protocol，協定): 指的是一個通用的標準。

MCP 的核心意義在於提供一個統一的協定，讓 AI 模型能夠與外部資料和工具進行對接。

透過 MCP，我們可以實現統一化的好處。以下圖為例，假設 GitHub 開發了自己的 MCP 伺服器，這個伺服器就能被 Claude、GPT 或 Gemini 等不同的 AI 模型所對接。同時，在圖表的右側可以看到，諸如 Curse 或 Visual Studio Code Copilot 等工具，也可以透過 GitHub 的 MCP 進一步與後端的 AI 模型連接。

這樣的架構帶來的好處是，開發者無需為不同的模型開發不同的 API 呼叫方式。從開發商或開發者的角度來看，這能節省大量的時間與精力。

MCP 最早由 Anthropic 提出，Anthropic 是 Claude 模型背後的公司。在 Anthropic 之後，各大模型商也紛紛跟進支持 MCP 協定。例如，OpenAI 和 Google 都已宣布支持 MCP。Google 的執行長甚至在推文中公開表示對 MCP 的支持。

在這樣的背景下，任何服務只要支援 MCP，就能輕鬆對接到不同的 AI 模型。這也解釋了為什麼企業競相推出自家 MCP 伺服器。

企業推出 MCP 的動機

從企業的角度來看，對接到不同 AI 模型是一個重要的競爭優勢。然而，有些人可能會擔心，隨著 AI 的發展，某些產品或服務可能被 AI 取代。以下我們以 GitHub 為例，分析為什麼企業無需擔心這一點。

GitHub 的核心服務是為工程師提供一個儲存程式碼的平台，透過 Git 進行版本控制。隨著發展，GitHub 衍生出許多其他服務，但其核心功能始終是程式碼儲存。透過 MCP，GitHub 能夠將服務與不同的 AI 模型對接，進而創造更高的價值。

具體來說，透過 MCP，GitHub 可以有的延伸價值

自動化 Pull Request：假設開發者透過 GitHub 的 MCP，在完成程式碼後，可以讓 AI 自動發起 Pull Request。
程式碼審查（Code Review）整合：當同事在 Pull Request 中留下審查意見，開發者可以透過 GitHub 的 MCP，將這些意見導入 Curse，然後請 AI 協助根據回饋修改程式碼。

在 GitHub 推出 MCP 後，其他程式碼儲存工具也開始推出自己的 MCP。如果競爭對手未跟進，他們的服務可能僅停留在程式碼儲存和版本控制的基礎功能。而 GitHub 除了這些基礎功能外，還能透過 MCP 讓開發者自動化許多工作流程。相較之下，GitHub 提供的 MCP 創造了顯著的差異化優勢。

GitHub 的核心功能是提供程式碼儲存的空間，這就像現實生活中的房間或衣櫃一樣，是不可或缺的。即使 AI 技術再進步，工程師仍然需要一個地方來儲存和管理程式碼。因此，GitHub 的核心服務不會被 AI 取代。

相反，GitHub 需要思考的是，如何在其核心價值上整合 AI 以放大價值。透過 MCP，GitHub 成功對接 AI 模型，同時保留其核心功能，這正是企業推出自家 MCP 的動機。

思考框架：是否該推出自家 MCP?

在看了 GitHub 的案例，相信讀者們會思考「該不該為自家的產品推出 MCP?」

建議讀者進一步思考以下問題：

核心需求是否不可取代：你所在的公司或團隊提供的服務，是否有一個即使 AI 出現也不會被取代的核心需求？
如何透過 AI 放大價值：在這個核心需求的基礎上，能否整合不同的 AI 模型或工具來提升價值？

如果你的答案是肯定的，且能透過 AI 放大價值，那麼推出自家 MCP 伺服器將是一個值得考慮的策略。

此系列文章為 《給工程師的 Cursor 工作流 — 透過 AI 代理全方位提升開發生產力》 搭配的教材。希望透過這系列文章，將過去協助導入 AI 工具及使用 Cursor 的經驗擴展並分享給想提升生產力的讀者。如果對課程感興趣的讀者，可以加入 E+ 成長計畫，觀看影片學習。