目前大型語言模型 ( LLM ) 選擇非常多，不只是最為人所知的 ChatGPT，還有像是 Claude 、Gemini、Mistral、Meta AI 等等。

一般狀況下使用的情境都能用自然語言溝通就好，像是問一些知識，請 LLM 生一些文案，翻譯或是改寫東西，或是當成計算機都可以，模型會直接回覆，也只需要依靠模型本身知識就好了。

但如果今天的情境需要用到對接外部服務，比如說你想要看某一個網站內登入之後的資料，你直接貼那個網址給 LLM 看並請他幫忙整理，是沒有辦法可以直接做到的。

這時候比較好的做法就會利用到 MCP。

MCP 的核心概念

MCP 全名是 Model Context Protocol。

是一個協議而不是工具或是 API gateway，在 2024 年 11 月時由 美國公司 Anthropic 所推出，一套定義了標準化方式讓 AI 可以對接不同工具。

Anthropic 這家公司就是現在鼎鼎大名的 Claude 開發商，現階段 OpenAI 及 Google DeepMind 都已經採用 MCP 來作為連結模型跟數據源的標準方式。

來源在此：https://en.wikipedia.org/wiki/Model_Context_Protocol?utm_source=chatgpt.com

需要統一的原因猶如開頭所講 LLM 的種類現在非常的多，而不同 LLM 雖然功能都差不多，但是操作方法不一樣，需要的「prompt 格式」也可能不相同。

可以這樣思考，如果今天你有一個 AI 的 APP，你想要 LLM 去讀取 Ggoogle Drive 的檔案，而模型的選擇通常都是開發讓使用者可以自己選，那就會需要為了每一個模型去寫一份「對接邏輯」。

今天如果要從 GPT 換成 Claude，就會需要重寫很多是配邏輯，另外一但模型更新的話，可能格式也會跟著改，那就代表你還要改程式。

非常麻煩，所以 MCP 就是在解決這個問題，給不同的 LLM 一個統一的「交通規則」，讓開髮者可以透過一種格式就能控制多個模型，去降低切換跟耦合的成本。

協議的原理是什麼運作的？

首先要先了解這個「交通規則」是為了確保那些事情。

  1. 模型收到任務時，有個明確的結構化描述。

  2. 工具收到指令時，可以精準執行不靠亂猜。

  3. 輸入輸出有統一個是，不會因為模型不一樣而混亂。

理論上要基於以上三點。

原理則是基於 Client-Server 架構 + JSON-RPC 來運作。

Client–Server 架構

簡單來說可以當作分工合作的概念。

  • Client： 客戶端，負責提出需求。

  • Server： 伺服器，負責執行任務並回應。

用現實生活來比喻的話就像是去餐廳點餐，小明跟服務生點餐要了一杯咖啡，服務生收到指令後，去廚房做咖啡再回送給小明。

這邊小明代表的是 Client，服務生是 Sever。

而在 MCP 裡面的話：

  • Client = LLM 應用，像是 Cursor、Claude、Agent Framework)

  • Server = MCP Server( 負責去掉用外部工具、API）

主要的好處是分離開邏輯，讓 LLM 負責理解需求，Server 負責執行，各司其職：

  • Client 端不用知道工具的細節（像是小明不用知道咖啡怎麼做的）

  • Server 端可以控制安全性，比如不讓某些 API 被使用（服務生可以不讓其他人知道咖啡秘方)

JSON-RPC

其實就只是一種用 JSON 語法的任務請求格式。

PRC 的全名是 Remote Procedure Call，中文是遠端呼叫程序，用意是讓你可以在呼叫本地函數一樣去呼叫遠端的服務。

而 JSON-RPC 就是用 JSON 來描述要呼叫哪一個功能，帶什麼參數，預期獲得什麼解決。

寫起來會像是這樣：

1
2
3
4
5
6
7
8
{
  "jsonrpc": "2.0",
  "method": "figma.get_frames",
  "params": {
    "projectId": "abc123"
  },
  "id": 1
}

而 MCP 用 JSON-PRC 的好處其實前面就有提到了：

  • 讓語法統一，也就是不同的工具、模型都使用同一種格式。

  • 更好解析(至少比自然語言好處理)。

自己可以怎麼樣去使用它？只能靠現有服務？

現在我覺得算是運用蠻頻繁的，至少在我日常開發需求上。

最主要也最簡單其實就可以去使用有支援 MCP 的工具，比如說我個人常用的 Cursor，就已經是 MCP 的實際應用工具。

其他的也有像是 CrewAI / Langroid / Autogen 或是 Claude 都有支援 MCP。

或者也可以考慮自己架一個 MCP 的 server。

可以參考這篇，我覺得寫得不錯：https://www.explainthis.io/zh-hant/ai/cursor-guide/4-6-developing-mcp-server。

裡面有提到如何開發 GitHub MCP 伺服器，以及跟 Cursor 做搭配。

運作流程會像是：

  1. Cursor 的 MCP 客戶端呼叫 GitHub MCP 伺服器，傳入參數。

  2. 伺服器驗證參數並呼叫 GitHub API。

  3. API 回傳結果後，伺服器格式化結果並傳回 Cursor。

  4. Cursor 顯示結果給使用者。

可以參考開源。repo，自架一個 MCP server， 並且串接自己的工具或是資料。

我自己常用到的應用是讓 Cursor 搭配 MCP 去看 figma 上的設計稿，幫忙直接切版出頁面，或是搭配 Github 去自動發 PR 出去。

小結

有個要注意的地方是 MCP 本質上是沒有「執行權」，他幫助的像是描述格式，執行的部分仍然是像是 Cursor、Agent 框架這些工具來去觸發。

MCP 讓「人 → LLM」的溝通變得清晰，而 LLM 再交棒給工具來執行具體動作。

沒有 MCP 一樣可以做事情，差異只是每家 AI 公司跟服務方都要一對一溝通，格式與規則各搞各的，而有了大家用同一套「AI 交通規則」，不需要重複開發，方便很多，目前看起來也已經變成主流的趨勢。