DevPawDEVPAW · GROUND-UP DEV NOTES
搜尋
選單
ZH-HANT
한국어English日本語繁體中文EspañolPortuguês简体中文
AI 程式開發與代理

[MCP·Skill #1] 什麼是 MCP 伺服器？從連線方式到安全性注意事項

使用 ChatGPT 或 Claude 時，總會有些不盡人意的時刻。模型很聰明，卻看不到我的資料庫，也讀不了公司內部 Wiki。

閱讀 6 分鐘
[MCP·Skill #1] 什麼是 MCP 伺服器？從連線方式到安全性注意事項 封面圖

使用 ChatGPT 或 Claude 時，總會有些不盡人意的時刻。模型很聰明，卻看不到我的資料庫，也讀不了公司內部 Wiki。

因此，大家開始直接串接 API。但不同模型和工具的整合方式各不相同，組合越多，整合程式碼就會呈指數成長。

MCP（Model Context Protocol）就是為了解決這個問題而出現的標準。簡單說，它是將外部工具與資料接入 AI 模型的通用規格，常被稱為「AI 界的 USB-C」。

本文將整理 MCP 究竟解決了什麼問題、導入前後的整合工作有何差異、內部結構與 function calling 的不同，以及現在值得立即接上的代表性伺服器。

先來看看重點摘要。

  1. MCP 是連接 AI 與外部工具的開放標準協定（Anthropic 於 2024 年 11 月公開）。
  2. 直接整合需要數百行程式碼的工作，有了 MCP 伺服器後只要幾行設定即可完成。
  3. 它不是取代 function calling，而是在其上方標準化並重複使用工具的一層。
  4. OpenAI 與 Google 也採用後，MCP 實際上已成為業界標準，伺服器生態系正快速成長。

MCP 解決的問題：M×N 整合地獄

先看看 MCP 出現以前的情況。

如果有 M 個 AI 應用程式，以及 N 個想連接的工具，就需要 M×N 份整合程式碼。Claude、ChatGPT、Cursor 的 GitHub 整合都必須分別製作。

MCP 在兩者之間加入標準規格。工具端只要製作一次 MCP 伺服器，AI 應用程式端只要實作一次 MCP 用戶端即可。M×N 變成 M+N。

想想 USB-C 出現前，每台裝置都要攜帶不同充電線的日子就很清楚了。MCP 統一的就是這套線材規格。

不過只看 M+N 之類的公式，可能還是很難感受差異。實際用兩種方式製作同一項功能，差別就會很明顯。

同一項功能：導入前後比較

假設要製作一個「查詢 GitHub Issue 並回答問題的 AI」。

在 MCP 之前，以下工作全都得由自己負責。

  1. 定義工具結構描述：直接以 JSON 結構描述撰寫「list_issues 接收 owner、repo、state」。
  2. 撰寫實際呼叫程式碼：GitHub REST API 用戶端、權杖管理、分頁處理。
  3. 實作執行迴圈：模型呼叫工具後接收結果，再回傳給模型的往返程式碼。
  4. 在每個應用程式中重複上述工作：Claude 整合一份，公司內部聊天機器人再一份。

光是查詢 Issue，加上樣板程式碼就要數百行；每增加工具，就要重複 1～3 次。

有了 MCP，只要這樣就完成。

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"]
    }
  }
}

結構描述、API 呼叫、驗證與錯誤處理都已內建於伺服器中。我只要註冊伺服器，然後說「請摘要這個儲存庫最近的錯誤 Issue」。

項目 直接整合 使用 MCP 伺服器
撰寫的程式碼 結構描述、呼叫與迴圈數百行 5 行設定
驗證與錯誤處理 自行實作 內建於伺服器
新增其他 AI 應用程式 從頭重做 重複使用相同伺服器
新增工具 修改程式碼並重新部署 只需更新伺服器

最後一列尤其重要。即使伺服器新增功能，我這邊的程式碼也完全不用變，這就是標準化的力量。

內部結構：主機、用戶端與伺服器

MCP 有三個角色。

組成元件 角色 範例
主機 使用者使用的 AI 應用程式 Claude Desktop, Cursor
用戶端 在主機內與伺服器一對一通訊 內建於主機
伺服器 公開工具與資料的程式 GitHub 伺服器、資料庫伺服器

一個主機可以啟動多個用戶端，而每個用戶端連接一個伺服器。通訊規格是 JSON-RPC 2.0；本機程序使用 stdio，遠端則使用 HTTP 串流。

主機內的用戶端與伺服器一對一連線。
主機內的用戶端與伺服器一對一連線。

伺服器公開的功能分為三類。

  • 工具（tools）：模型呼叫的函式，例如「建立 Issue」、「執行查詢」。
  • 資源（resources）：模型讀取的資料，例如檔案內容與資料庫結構描述。
  • 提示（prompts）：伺服器預先準備的提示範本。

重點在於執行階段才查詢工具清單。用戶端連接伺服器後會問「你能做什麼？」，伺服器則回傳工具清單與結構描述。這就是伺服器更新後，我的程式碼仍可維持不變的原因。

它和 function calling 有什麼不同？

讀到這裡，你可能會想：「這不是早就能用 function calling 做到了嗎？」

兩者位於不同層。function calling 是與模型對話的規約，也就是「模型，這些函式可用，需要時請以呼叫格式回覆」的約定。函式如何實作、從哪裡取得，完全由開發者負責。

MCP 是發布與重複使用這些函式的規約。它把工具實作、驗證與文件包成伺服器套件，讓任何 AI 應用程式都能接上使用。

如果說 function calling 是「函式呼叫語法」，MCP 就是「容納函式的函式庫生態系」。實際上，MCP 用戶端在內部仍直接使用 function calling。兩者不是替代關係，而是上下層關係。

因此，「function calling 和 MCP 該用哪個？」本身不是成立的問題。只在單一應用程式使用幾個函式時，直接實作 function calling 就足夠；若要在多個應用程式中重複使用，或採用他人製作的工具，就該用 MCP。

現在值得立即接上的代表性伺服器

生態系成長快速，常見工具大多已經有對應伺服器。這裡挑出五個反應良好的選項。

伺服器 可以做什麼
Playwright AI 直接操作瀏覽器：點擊、輸入、截圖
Figma 讀取設計稿並轉換成前端程式碼
Notion 搜尋與整理文件、會議記錄，並建立頁面
GitHub 查詢與建立 Issue、PR，並搜尋程式碼
Supabase(Postgres) 以自然語言查詢資料庫並掌握結構描述

如果只能選一個，我會選 Playwright。接上後試著說：「進入這個網站，填寫註冊表單並截圖。」看到 AI 開啟瀏覽器、實際點擊並輸入後，就不必再解釋工具連線為何會改變遊戲規則。它也能立即用於 E2E 測試自動化與重複性的網頁工作。

對前端開發者來說，Figma 也很有感。過去需要看著設計稿手動轉寫標記的工作，會變成對能直接讀取設計稿的 AI 說：「把這個框架做成 React 元件。」

只要在設定檔中加入幾行，就能完成連線。
只要在設定檔中加入幾行，就能完成連線。

注意事項與限制

它不是萬靈丹。以下也整理實務上可能遇到的問題。

首先是安全性。MCP 伺服器是授予模型執行權限的通道，因此接上不可信的伺服器，可能因提示注入而造成資料外洩。最安全的做法是只使用官方登錄庫或經驗證的伺服器。

還有上下文成本。連接越多伺服器，工具定義就越會佔用上下文視窗，反而可能降低模型效能。就像表格中所示，只連接目前需要的工具會更好。

收尾

MCP 不是讓「模型變得更聰明」的技術，而是將「模型能伸手觸及的範圍」標準化。把直接整合需要數百行程式碼的工作變成幾行設定，以及建立能直接接上他人製作工具的生態系，這兩點就是核心。

下一篇文章將整理經常與 MCP 比較的 Claude Code Skill，以及子代理程式各自扮演的角色。

延伸閱讀