4-2 MCP 是什麼? 在解決什麼問題?

在上一個單元，我們討論了 AI 代理的相關內容。在這個單元，我們將回到本章的主軸，進一步探討 MCP 是什麼、它解決了什麼樣的問題，以及為什麼我們需要 MCP 這樣的工具。以 Cursor 為例，我們將深入說明其應用。

什麼是 Model Context Protocol (MCP)?

如果我們把 MCP 的三個字分別拆開來看，他們分別代表：

• Model 模型，也就是大家熟知的 AI 模型，例如 GPT 模型、Claude 模型
• Context 脈絡，也就是提供給模型的額外資料
• Protocol 協定，也就是一個通用的標準

而把這三個字連在一起，MCP 就是指讓模型能夠輕易對接到外部資料的一種協定。相信這時你可能會問，MCP 是能讓模型對接外部資料的協定，不過為什麼需要讓模型能對接到外部資料?

在《AI 代理是什麼?》一文中有談到， AI 代理的核心要件之一是工具，而對接到外部資料意味著能讓 AI 去操作外部工具。之所以這麼說，是因為軟體程式在做的事情就是操作資料，例如多數人都很熟悉的 CRUD 就是對資料的操作。

舉例來說，假如今天用 AI 代理在 Cursor 或 Windsurf 這類的 AI 驅動 IDE 寫完程式碼，想要直接發一個 Pull Request 到 GitHub 上，在過去是做不到的，因為即使 AI 代理非常聰明，但沒有對接到外部的工具，也無法完成這類的任務。所以開發者需要自己打開 GitHub，然後點擊發 Pull Request，然後手動把 AI 生成好的 PR 相關描述，加到 GitHub 的 PR 當中。

不過當有了 MCP 後，這些手動的流程都能夠被 AI 做掉。因為換個角度來談，在 GitHub 發 PR 這件事，其實就是在 GitHub 的某個程式碼庫中，新增一筆 PR 相關的資料。因此，當把這類 AI IDE 透過 MCP 伺服器對接到 GitHub，在 AI 代理寫完程式碼後，就可以直接完成新增一個 PR 的操作。

為什麼需要 MCP?

讀完上面的段落，讀者們可能會有個疑問「上面這段描述，不就是讓 AI 模型呼叫 GitHub 中用來發送 PR 的 API 嗎? 這樣 MCP 在這邊的做用是什麼?」。如果你有這個疑問，說明你的理解沒有錯，以上面談到「讓 AI 代理直接發 PR」這個例子，AI 代理做的事情就是透過 GitHub 的 API 來發送 PR。

只是為什麼又需要多一層 MCP 呢? 要回答這個問題，或許可以反過來問，如果沒有 MCP 的話，AI 模型要怎麼知道如何呼叫 GitHub 的 API? 事實上，AI 很可能不知道，假如你直接問 AI 模型「如何呼叫 GitHub 的 API 來發 PR?」，AI 模型的回答可能是基於訓練資料 (所以可能過時)，又或者 AI 可能會有幻覺的回答。

因此，要避免模型用過時的方式，或者用幻覺的方式來呼叫某個外部的 API，過去在業界有個做法叫函式呼叫 (function calling)，是由開發者直接定義好某個函式 (或者某個 API)，然後定義好如何呼叫該函式 (或呼叫該 API)，然後再傳入相對應的格式後，讓模型去呼叫該函式 (或 API)。

在看完函式呼叫，相信讀者可能會問，既然已經有函式呼叫這種方式可以呼叫外部 API，為什麼又需要 MCP 呢? 兩者之間有什麼不同?

重點在標準化

這兩種方式的一大區別在於，MCP 是從協定的角度出發，但函式呼叫則是讓開發者可以靈活地自由定義，不同的開發者可以自由定義函式以及如何呼叫。靈活聽起來似乎很不錯，但是當不同開發者定義的方式不同，就會遇到「無法通用」這個問題。從軟體設計的角度來看，當無法通用的問題在於普及度會困難，且不同的開發者可能會需要重新造相似的輪子。

這種因為缺乏標準，導致重複造輪子且互不通用的狀況，在軟體工程的歷史上出現過非常多次。事實上，在 Anthropic 最開始把 MCP 開源時，有提到希望讓 MCP 成為 USB-C 一樣的存在。就如同 USB-C 這個標準形式，讓每一個裝置都能夠透過 USB-C 來連接，不會因為換了裝置後就不能繼續用同樣的接頭。

雖然 MCP 由 Anthropic 提出，但 OpenAI 也宣布支援

以 USB-C 為例來說，先前蘋果獨樹一格用自己的 Lightning 接頭，讓很多人忘記帶充電線時，假如週遭的其他人都是用 USB-C，就變得沒辦法借別人的充電線來充電。但後來蘋果也統一成 USB-C 後，這個問題就不復存在，只要有 USB-C，不管是用哪牌的裝置，都能夠共享。

而 MCP 的存在也是同樣的道理，能讓 AI 應用輕易轉換、搭配不同模型；同時也能讓模型輕易對接到不同的資料來源與工具。因此，如果要總結「為什麼需要 MCP」，最核心的點，就是提供一個標準化的接頭，透過標準化能讓開發 AI 應用的人，能夠更輕易地把 AI 模型與外部資料與工具接在一起。

有了統一標準，開發者不需要為每種模型重寫介面，這降低了開發成本，讓更多工具能快速與 AI 整合。

總的來說，MCP （Model Context Protocol) 是一個統一的協定，讓不同的 AI 模型和應用能夠輕鬆對接到外部資料和工具。它解決了函數呼叫各家表述的問題，節省開發時間，並促進更多工具與 AI 的整合，這也是 MCP 在社群中如此受歡迎的原因。

MCP 具體可以如何被應用

在了解完 MCP 是什麼、為什麼需要 MCP 後，讓我們接著從 Cursor 中具體可以如何搭配 MCP，來理解 MCP 的具體價值。

在上一個單元我們有提到的 AI 代理。AI 代理需要與不同的工具對接，才能真正發揮其最大效益。以 Cursor 為例，如果我們僅用它來撰寫程式碼或進行測試，這樣的效果其實是有限的。雖然在第三章節中，我們介紹了許多實際應用的案例，但如果你仔細檢視工程師的整個工作流程，會發現仍有許多繁瑣的工作可以被自動化，而這些工作正是 AI 能夠幫助解決的。

要實現這些工作的自動化，AI 必須能夠與各種工具對接。假如你希望 Cursor 根據某個需求自動實現某個函數及其相關測試，你仍然需要手動將需求複製並貼到 Cursor 的對話框中。但如果我們希望省去這個手動步驟，一個理想的方式是讓 Cursor 直接與專案管理工具對接，例如 Linear 或 Jira。這樣，Cursor 就能自動從 Jira 中抓取相關規格或需求描述。只要打通這個流程，我們甚至不需要手動輸入需求，只需告訴 Cursor「根據 Jira 的某張 ticket 來實作功能」，即可完成任務。

再舉另一個例子，當我們提供功能描述和規格後，Cursor 可以根據這些內容自動撰寫端到端的測試案例。如果我們進一步將 Cursor 與 Playwright 這樣的端到端測試工具對接，Cursor 不僅能撰寫測試案例，還能透過 Playwright 直接開啟瀏覽器，根據自己生成的測試案例逐步執行測試並完成程式碼。

此外，如上面談到的，如果我們將 Cursor 與 GitHub 對接，事情會變得更簡單：Cursor 生成 PR 描述後，可以直接透過 GitHub 的 API 發送 PR 到 GitHub，無需手動複製貼上。

從這些例子可以看出，當 AI 代理能夠與其他工具對接時，在軟體開發的生命週期中，工程師需要處理的工作會大幅減少。那些通常被認為繁瑣的任務，都可以透過工具的整合，由 AI 代理自動完成。

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