MCP 一年半：開源協議的承諾，和開發者實際踩到的三個洞

重點一：Model Context Protocol（MCP） 在 2024 年 11 月由 Anthropic 推出，核心只有三個原語：tools（可呼叫的函式）、resources（可讀取的資料）、prompts（互動樣板）。本地走 stdio 傳輸，遠端走 HTTP/SSE。

重點二：MCP 規格把 auth 留給實作者決定——這是設計選擇，不是疏漏。一個符合規格的 server 可以完全沒有認證，在本地開發中不構成問題，在遠端或多人部署中是需要主動處理的工程斷點。

重點三：Anthropic 在 2026 年 5 月收購 Stainless 的官方理由是「SDK 與 MCP server tooling」；Stainless 同日宣布 wind down 所有 hosted products。這個收購說明 MCP server 生成與維護是 Anthropic 認為需要解決的薄弱點。

先看一個 2026 年再典型不過的場景：一個開發者花兩天時間，替公司的 Notion 工作區建好一個 MCP server，讓 Claude 可以直接讀寫內部文件資料庫。

本地測試一切正常。Claude Desktop 連上去，叫它找上週的會議紀錄，幾秒內拿到了。

接下來他想讓四個同事也能用，不想讓大家各自在自己的電腦跑一個 server 行程。這時候他才發現，他其實只走了一半的路。要部署成遠端服務，他需要處理 auth——但 MCP 規格沒有告訴他該怎麼做。他的同事用的 IDE 對 MCP client 的支援程度也各不相同。這個 server 如果需要更新，就是他的事。

這個場景裡沒有一步是意外。auth、client 支援、維護責任——三個斷點全都源自 MCP 規格刻意不涵蓋的範圍，在本地開發中幾乎不可見，到了多人部署才會浮現。

MCP 解決的是連接標準問題，沒解決的是連接品質問題——這兩件事是不同的賭注。

---

MCP 承諾的是什麼：三個原語，讓 AI 工具說同一種語言

Model Context Protocol 在 2024 年 11 月 25 日由 Anthropic 推出，設計目標直接：給 AI 工具一條標準管道，讓它們能連到外部資料與系統，不用每個工具各自發明一套整合方式。

規格的核心只有三個原語：

• tools：AI 可以呼叫的函式（查資料庫、呼叫外部 API、執行指令）
• resources：AI 可以讀取的資料（檔案、文件、資料流）
• prompts：預先定義的互動樣板（使用者可以觸發的工作流程）

傳輸層用 JSON-RPC 2.0。MCP 規格定義了兩種傳輸機制：本地走 stdio（server 跑在本機，client 透過標準輸入輸出通訊），遠端走 HTTP with Server-Sent Events（SSE）（server 部署成 HTTP 端點，適合多人或跨裝置存取）。

規格很乾淨——讀一遍就知道 server 要實作什麼，client 要期待什麼。開源、有官方 reference server、有明確的協議邊界，這是 MCP 核心設計帶來的直接好處。

麻煩不在規格本身，在規格刻意不涵蓋的地方。

---

本地到遠端：同一個 server，兩種截然不同的部署現實

一個 MCP server 在本地端跑的時候，auth 問題幾乎不存在。

stdio transport 的邊界天然清楚：只有本機行程才能對接 server，外部無法直接存取。你不需要特別決定誰有沒有連接權限——作業系統的行程隔離先天就幫你隔絕了外部連接的風險。

換到遠端部署，情況完全不同。

當你把 MCP server 部署成一個 HTTP/SSE 端點，這個端點理論上可以從任何有網路的地方連過來。你需要決定：要不要驗證請求方身份？怎麼驗證？API key、OAuth token、或完全不驗證？

MCP 的核心規格沒有規定這些——這是刻意設計的留白。協議只管「傳輸格式和原語定義」，auth 交給 server 和 client 實作者自行決定。

換句話說，一個「符合 MCP 規格」的 server 可以是任何東西：OAuth 2.0 全套、僅靠 API key header 保護、或完全沒有認證。符合規格不代表生產環境安全，這兩件事是分開的。

---

Auth 刻意留白：MCP 把認證交給你決定，原因是什麼

為什麼不把 auth 寫進規格？

從協議設計角度看，這是一個有道理的選擇。不同部署情境的 auth 需求差異很大：

部署情境	實際需求
本地 IDE plugin（個人用）	不需要 auth
企業內部工具（SSO 環境）	公司 SSO 或內部 token
開放 API 服務	OAuth 2.0 或 API key
本地多人共享（開發環境）	IP whitelist 或基本驗證

如果把任一種 auth 方案寫死進協議，大量合法的使用情境反而會很難支援。MCP 選擇的做法是：規格定義介面，部署決定安全邊界。

這在原則上是合理的。但有一個實際後果：大量社群維護的 MCP server 預設只有 stdio transport，完全沒有為遠端部署設計 auth 機制。因為設計者預設的使用情境就是本地端。

這些 server 沒有設計錯誤，它們的使用說明書也寫著「本地使用」。但當開發者把它們挪作遠端部署素材時，常常就跳過了這一行。

MCP 官方文件建議遠端部署使用 OAuth 2.0 或等效機制。但這是建議，不是強制。在選用任何 MCP server 做遠端部署前，auth 機制需要你自己確認。

---

為什麼 Anthropic 收購 Stainless：官方理由直接點名 MCP server tooling

2026 年 5 月 18 日，Anthropic 宣布收購 Stainless。

Stainless 做的事情是：把 OpenAPI 規格文件轉成可用的 SDK 和 MCP server。它有一個 MCP portal，讓開發者能從一份 API 規格直接生成可用的 MCP server 設定。

Anthropic 的收購官方理由很直接：Stainless 從 Claude API 早期以來就生成了所有官方 SDK；收購後要把這個能力整合進 Claude Platform，特別是 SDK 和 MCP server tooling 這一層。

同日，Stainless 對現有客戶發出通知：所有 hosted products 逐步關閉，SDK generator 即日起不接受新註冊、新專案與新 SDK；既有客戶保留已生成 SDK 的修改與延伸權利。

這個收購動作說明了什麼？

如果「從 OpenAPI spec 生成一個可用的 MCP server」是一個已解決的工程問題，Anthropic 不需要買一家公司來做這件事。這個收購的存在，是 Anthropic 在企業決策層面判斷：MCP server 生成這段路對開發者來說還不夠順，需要一個集中方案。

白話講：MCP 的「標準存在了」，但「從規格到可用 server」這段中間的工程路徑，在 2026 年 5 月的時間點，Anthropic 認為生態系還沒有把它解決好。

---

導入前怎麼判斷：先回答這 3 個問題，再投入工程時間

對正在考慮把 MCP 用進工作流程的開發者，這 3 個問題可以快速定位你實際面對的情況：

1. 你的目標 AI 工具有沒有完整的 MCP client 支援？

不是所有 AI 工具都實作了 MCP client，也不是所有的實作品質都一致。Claude Desktop 是目前官方支援最完整的 MCP client；其他 IDE 和 agent 環境需要個別確認支援程度。

在開始建 server 之前，先確認你打算讓誰連這個 server——以及那個 client 有沒有你需要的功能。

2. 你需要的 MCP server 有沒有 auth？這個 auth 適合你的部署情境嗎？

本地端（stdio）使用：auth 不是立即的問題，先專注功能。

遠端或多人部署（HTTP/SSE）：在採用任何 server 之前，先確認它的 auth 機制（OAuth 2.0、API key、或沒有）和你的安全需求是否匹配。社群維護的 server 預設常常沒有遠端 auth，這需要你自己補。

3. 這個 MCP server 由誰維護？它停更或壞了，你的計畫是什麼？

官方 server（Anthropic 或一線合作夥伴維護）通常有合理的更新保證。

社群維護的版本品質和更新頻率差異大。自己建的 server 完全依賴你的工程時間支撐。

在正式環境採用任何 MCP server 之前，先把維護責任釐清。

---

MCP 一年半走過的路是真實的——從一個協議公告，到大多數認真的 agent 開發者都知道它、不少人已經在用它。

但「知道它是什麼」和「在正式環境用好它」之間，還有上面這三個核查要做完。

規格乾淨，是 MCP 的優點；規格不包含 auth、不保證 server 品質、不強制 client 完整性，是這個協議刻意的設計邊界。這個邊界本身沒問題——把它弄清楚，才是真的做完了採用前的功課。

資料來源：Anthropic Model Context Protocol 官方公告（2024 年 11 月）、Model Context Protocol 規格文件（modelcontextprotocol.io）、MCP GitHub 組織（github.com/modelcontextprotocol）、Anthropic 收購 Stainless 官方公告（2026 年 5 月）。

林子睿（編輯：廖玄同），《MCP 一年半：開源協議的承諾，和開發者實際踩到的三個洞》，矽基前沿 [Si]gnals，2026-06-10。https://signals.tw/articles/mcp-eighteen-months-developer-reality/