如果你已經在用 Cursor 或 Claude Desktop，大機率見過 MCP（Model Context Protocol） 設定項：一行 npx 命令，Agent 就能讀倉庫、查資料庫、搜網頁。2026 年的問題是——該裝哪幾個？
社群 Server 數量激增，質量參差不齊：有的維護活躍、許可權清晰；有的長期無人更新、預設暴露整個磁碟。本文不按 star 數簡單排序，而是從穩定性、安全邊界、Host 相容性、工具描述質量、實戰價值五個維度評測，給出分場景排名與避坑清單。排名會隨生態變化調整，文內註明評測基準日期：2026 年 8 月。
評測方法論
同一 Server 在「個人寫指令碼」和「企業合規環境」下的評價可能完全相反。我們採用加權評分（滿分 5），再按場景給出推薦等級：S（必備）、A（強烈推薦）、B（按需）、C（觀望）。
| 維度 | 權重 | 考察點 |
|---|---|---|
| 穩定性 | 25% | 近 6 個月提交頻率、Issue 響應、Breaking change 是否檔案化 |
| 安全邊界 | 25% | 目錄/API 白名單、環境變數傳金鑰、預設許可權是否過大 |
| Host 相容性 | 20% | stdio 支援、Cursor / Claude Desktop / VS Code 實測可連 |
| 工具 Schema 質量 | 15% | 引數 description 是否清晰、減少模型誤呼叫 |
| 實戰價值 | 15% | 是否解決高頻任務、與 Function Calling 相比是否值得單獨裝 |
說明：商業 SaaS 類 Server（Notion、Linear 等）還取決於你的訂閱與 API 配額；下文評分假設已具備合法 API Key。
綜合推薦 Top 10
以下面向日常開發 + Agent 程式設計的通用組合，覆蓋 80% 個人與小團隊場景。企業使用者請同步閱讀後文「許可權最佳實踐」。
| 排名 | MCP Server | 型別 | 等級 | 一句話理由 |
|---|---|---|---|---|
| 1 | @modelcontextprotocol/server-filesystem | 檔案系統 | S | 官方維護，讀寫在白名單目錄內，Agent 操作程式碼庫的基礎 |
| 2 | GitHub MCP（官方 github-mcp-server） | 程式碼託管 | S | Issue、PR、倉庫搜尋一站式，研發 Agent 幾乎必備 |
| 3 | @modelcontextprotocol/server-fetch | HTTP | A | 拉取檔案與 API 響應，補全模型訓練截止後的資訊 |
| 4 | Brave Search / Tavily 等搜尋 MCP | 搜尋 | A | 可控的網路檢索，比讓模型「假裝搜尋」可靠得多 |
| 5 | PostgreSQL / SQLite MCP | 資料庫 | A | 只讀分析場景極強；寫操作務必限權 |
| 6 | @modelcontextprotocol/server-memory | 記憶 | A | 跨會話輕量知識圖譜，適合個人偏好與專案備忘 |
| 7 | Puppeteer / Playwright MCP | 瀏覽器 | B+ | 端到端驗證與抓取動態頁；資源消耗大，按需啟用 |
| 8 | Slack MCP | 協作 | B+ | 把 Agent 產出推到頻道，適合 on-call 與評審通知 |
| 9 | Sentry MCP | 可觀測 | B | 用自然語言查錯誤棧與 Release，縮短排障路徑 |
| 10 | Docker MCP | 容器 | B | 查映象、管容器，本機全棧開發時省力 |
Starter 套裝（3 個就夠起步）：Filesystem + GitHub + Fetch。需要查最新技術檔案時再加搜尋類；需要分析業務資料時再加 Postgres（只讀賬號）。
開發協作類
1. Filesystem MCP — 評分 4.8 / 5（S）
能力：在設定的根目錄內讀取、寫入、列出檔案，部分實現支援目錄樹搜尋。
優點：官方 SDK 示例最完整；與 Cursor 等 IDE 的「專案根目錄」概念天然契合；工具 Schema 簡潔，誤呼叫率低。
注意：切勿把 / 或使用者主目錄設為 root；生產 CI 裡應禁用寫工具或單獨只讀例項。
{
"mcpServers": {
"filesystem": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-filesystem", "/path/to/your/project"]
}
}
}2. GitHub MCP — 評分 4.7 / 5（S）
能力：搜尋倉庫與程式碼、管理 Issue/PR、讀檔案內容、建立分支等（隨版本擴充套件）。
優點：把「查倉庫 + 提 PR」從瀏覽器搬到對話流；工具命名與 GitHub API 概念一致，模型容易理解。
注意：Personal Access Token 用 fine-grained，僅授予必要倉庫與只讀 scope；寫操作（merge、delete）在自動化場景要加人工確認。
3. Git MCP（本機倉庫）— 評分 4.3 / 5（A）
與 GitHub MCP 互補：在未 push 的本機倉庫上執行 status、diff、log、commit。適合「先本機理清變更再決定是否推送」的工作流。許可權仍應限制在單一 repo 路徑。
資料與基礎設施類
PostgreSQL MCP — 評分 4.5 / 5（A）
Agent 用自然語言生成 SQL，經 Server 執行後返回 JSON 行集，是資料分析類 Agent 的利器。務必：
- 使用只讀資料庫角色，禁止
DROP/UPDATE除非有審批流 - 限制可訪問的 schema
- 對返回行數設上限，避免大結果集撐爆上下文
返回的 JSON 陣列建議用 JSON Schema 約束欄位型別，再交給下游報表；開發階段可在 JSON 工具箱本機校驗樣例輸出。
SQLite MCP — 評分 4.2 / 5（A）
適合本機原型、嵌入式分析與單檔案資料集。比 Postgres 部署更輕，但同樣要限制資料庫檔案路徑，防止 Agent 讀到無關 .db 檔案。
Docker MCP — 評分 4.0 / 5（B+）
列出容器、檢視日誌、檢查映象。對全棧開發者友好；在共享機器上應限制 Docker socket 訪問，避免 Agent 啟動特權容器。
Kubernetes MCP — 評分 3.8 / 5（B，按需）
適合已有 K8s 運維經驗的團隊。工具能力強，但叢集誤操作代價高；建議只讀 RBAC + 指定 namespace，並與現有 GitOps 流程並存而非替代。
搜尋與資訊獲取類
Fetch MCP — 評分 4.6 / 5（A）
按 URL 拉取 HTML/Markdown/純文字，是「讀官方檔案、讀部落格」的最低成本方案。與全功能瀏覽器 MCP 相比更省資源，且攻擊面更小（不執行 JS）。
建議配合 URL 白名單或域名過濾，禁止訪問內網後設資料地址（如 169.254.169.254）。
Brave Search / Tavily MCP — 評分 4.4 / 5（A）
當不知道 URL、需要「搜一下最新版本號/報錯資訊」時，搜尋 MCP 比 Fetch 更合適。Brave 側重隱私與 API 簡潔；Tavily 面向 RAG 場景，返回結構化摘要。二者選一即可，避免重複佔用工具槽位。
Puppeteer / Playwright MCP — 評分 4.0 / 5（B+）
需要登入態、點選按鈕或渲染 SPA 時才有明顯優勢。缺點：慢、吃記憶體、截圖易洩露敏感資訊。推薦作為按需掛載的 Server，非常駐。
辦公與協作類
Slack MCP — 評分 4.1 / 5（B+）
發訊息、搜頻道、讀執行緒。適合把 Agent 生成的釋出說明、Review 摘要推到團隊頻道。Token 用 Bot scope 最小化，禁止預設 chat:write 到全 workspace 除非必要。
Notion MCP — 評分 3.9 / 5（B）
讀寫頁面與資料庫，適合知識庫型 Agent。API 限速與塊結構複雜，模型偶爾構造錯誤 payload；適合人工複核後寫入的場景。
Linear / Jira MCP — 評分 3.8 / 5（B）
建立與查詢工單，銜接「從對話到任務系統」。研發流程若已深度繫結其中一家，值得裝；否則優先順序低於 GitHub Issue。
Google Drive / Gmail MCP — 評分 3.5 / 5（C+，謹慎）
能力誘人，但 OAuth 範圍大、誤發郵件或誤分享檔案風險高。僅建議在強審計、沙箱賬號下試用。
可觀測與運維類
Sentry MCP — 評分 4.0 / 5（B+）
按專案、Release、時間範圍查詢 Issue 與事件詳情。on-call 時用對話快速定位「上週上線後新增的 N+1 錯誤」很省時。只讀 API Key 即可覆蓋大多數查詢場景。
Datadog / Grafana MCP — 評分 3.7 / 5（B）
查指標、日誌與 Dashboard。適合已有可觀測棧的團隊；查詢 DSL 複雜，建議在工具描述裡寫清示例查詢，降低模型瞎填引數的機率。
AWS / Cloudflare 檔案類 MCP — 評分 3.6 / 5（B）
偏「檔案檢索 + 最佳實踐問答」，不直接改雲資源，相對安全。真正執行 terraform apply 類操作應走 CI，而非 Agent 直連線生產賬號。
設定與許可權最佳實踐
- 最小許可權：每個 Server 獨立 Token；資料庫只讀；檔案系統限定專案根目錄。
- 環境變數：金鑰放
env塊，不要寫進可提交的 JSON 設定檔案。 - 工具數量：單會話可見工具建議控制在 15 個以內；過多時 Host 可分組或按任務動態載入 Server。
- 審計：記錄
tool_calls名稱、引數摘要與執行結果，便於覆盤誤操作。 - Schema 自檢：自建 MCP 時，工具引數的 JSON Schema 應在 CI 中校驗；樣例輸入輸出可用 JSON 工具箱本機驗證。
- 傳輸方式：個人本機用 stdio；團隊共享服務用遠端 SSE 並加認證，勿把無鑑權 SSE 埠暴露公網。
| 角色 | 推薦組合 |
|---|---|
| 前端 / 全棧開發者 | Filesystem + GitHub + Fetch +（可選）Playwright |
| 後端 / 資料工程師 | Filesystem + GitHub + Postgres（只讀）+ Docker |
| 技術負責人 / on-call | GitHub + Sentry + Slack + Fetch |
| 產品經理 / 知識工作者 | Notion + Slack + 搜尋 MCP |
不推薦或需謹慎的場景
- 來源不明的「萬能 MCP 聚合包」：可能夾帶未宣告的檔案訪問或外聯，無法審計。
- 對生產庫開放寫 SQL 的 Database MCP：一次幻覺可能刪表；變更應走遷移指令碼 + CI。
- 預設掛載整盤 Filesystem：Agent 可能讀到
.ssh、.env等敏感檔案。 - 同時裝 3 個以上功能重疊的搜尋/瀏覽器 Server：增加誤選工具機率，浪費上下文。
- 在無沙箱環境用 Shell/Terminal MCP 執行任意命令：等同於把 shell 交給模型；若必須用，限制使用者與命令白名單。
2026 年 MCP 已捐贈至 Agentic AI Foundation，生態會更規範，但安全責任仍在設定者與部署者——排名再高，錯誤許可權設定也會釀成事故。
常見問題 FAQ
MCP Server 和普通 REST API 有什麼區別？
REST API 面向人類或程式直接呼叫；MCP Server 面向 Agent Host，提供工具發現、Schema 描述、資源訂閱與統一授權。同一業務能力可以既有 REST 又有 MCP 包裝，但 Agent 側優先走 MCP 以降低整合成本。
一次應該裝多少個 MCP Server？
建議從 2～4 個高頻 Server 起步（如檔案系統 + Git + 搜尋），確認工作流穩定後再擴充套件。工具過多會佔用上下文、增加誤呼叫機率，也放大許可權風險。
stdio 和 SSE 傳輸怎麼選？
本機 IDE（Cursor、Claude Desktop）優先 stdio，設定簡單、程式隔離好。遠端或多客戶端共享服務時用 SSE/HTTP，便於部署與鑑權，但需注意網路安全與 Token 管理。
如何評估第三方 MCP 是否安全？
檢查：是否開源可審計、許可權是否最小化、是否把金鑰寫入環境變數而非設定檔案明文、是否只暴露必要目錄或 API scope、維護者信譽與更新頻率。生產環境避免安裝來源不明的 npx 一鍵包。
應該自建 MCP 還是先用官方 Server？
通用能力（檔案、Git、Postgres、Fetch）先用 modelcontextprotocol 官方或大廠維護的 Server；只有內部系統、特殊合規或官方無覆蓋時再自建，並複用官方 SDK。
MCP 工具返回的 JSON 如何校驗？
為工具輸出定義 JSON Schema，在 Host 側或流水線中用校驗器驗證後再交給下游。開發階段可用 JSON 工具箱在瀏覽器本機校驗 Schema 與樣例資料。
總結
2026 年最值得裝的 MCP Server 並沒有「唯一正確答案」，但有清晰的優先順序：先把官方 Filesystem、GitHub、Fetch 打牢，再按角色疊加資料庫、搜尋、協作與可觀測類 Server。評測時永遠把安全邊界放在功能豐富度之前。
若你正在搭建 Agent 基礎設施，建議同時閱讀本站《AI Agent 與 JSON Schema、Function Calling、MCP 技術演進》一文，理解 MCP 在整體棧中的位置；工具返回的 JSON 結構，則用 JSON 工具箱本機校驗後再接入流水線。