MCP 不是接工具，
是重寫軟體邊界

Every 訪談 Stainless 創辦人 Alex Rattray。這集的重點不是「每個網站都加一個 MCP server」這句口號，而是 AI 要真正使用網路服務時，工具名稱、API 設計、權限範圍與安全責任都會被重新打開。

來源：Every YouTube 頻道，2026 年 5 月 20 日發布

SCROLL
PART 1 ｜ AI 原生的網路入口

MCP 想解的問題，
不是再多一個外掛商店

Alex Rattray 的公司 Stainless 長期替 OpenAI、Anthropic 等公司建立 API 與 SDK。Dan Shipper 問他的其實是下一層問題：如果 AI agent 要替人退貨、查資料、建立任務、更新 CRM，它不能只讀網頁。它需要一種能理解、能呼叫、能被限制的軟體介面。

MCP，也就是 Model Context Protocol，把網站或服務包成模型能使用的工具。理想狀態下，AI 不只是「看見」你的服務，而是能用正確動作完成工作。這也是為什麼 Alex 說，接下來十年會贏的軟體公司，會是懂得把自己的能力設計成 AI 能安全使用的公司。

MCP 的真正價值，不在於把所有按鈕暴露給模型，而在於把軟體能力整理成清楚、有限、可授權、可維護的動作。

這也讓 MCP 和傳統 API 不完全一樣。API 主要服務工程師，MCP 服務的是語言模型。工程師可以讀文件、推敲參數、處理錯誤。模型需要工具本身有足夠語義，否則它會在模糊描述、太多選項和錯誤權限裡迷路。

PART 2 ｜ 工具太少與工具太多

一個 MCP server 有幾十個工具，
可能已經設計錯了

這集最實用的提醒是工具數量的取捨。工具太少，模型拿不到正確能力，只能用很粗的動作硬做。工具太多，每個工具的用途又不夠清楚，模型就會把上下文塞滿，還可能選錯工具。

Alex 的判斷是，MCP 工具應該為使用情境設計，而不是把既有 API 端點一比一搬出來。人類工程師能理解一組底層 API 如何組合；模型更需要明確語意，例如「替某位客戶退款某筆商品」比「更新交易物件」更接近它要完成的任務。

從軟體到 AI 工具的四層轉換
產品能力退款、查詢、建立任務、同步資料
API 邊界哪些動作真能被系統安全執行
MCP 工具模型看得懂的名稱、描述與參數
人類意圖我要完成什麼，而不是我要呼叫哪個端點

所以 MCP 不是把文件格式換一下。它迫使軟體公司重新回答一個問題：你提供給 AI 的最小可靠動作是什麼？如果這個問題沒有答好，模型看起來連上了服務，實際上只是多了一堆可誤用的按鈕。

PART 3 ｜ 權限應該在哪裡發生

安全不能只靠少暴露幾個工具

Dan 用一個退貨例子逼出 MCP 的安全問題：如果 AI 被要求退款某一雙襪子，它會不會同時退款所有訂單？會不會做出超過使用者授權的事？很多人第一反應是「那就少暴露工具」。Alex 認為這只能部分有效。

真正的權限邊界應該回到 API 層。MCP 可以提供語義清楚的工具，但最終能做什麼、能碰哪個帳戶、能操作到什麼範圍，應該由 OAuth scopes、細緻授權與底層 API 執行規則決定。否則 MCP 只是在前面加一層好看的包裝，真正的風險仍在底下。

MCP 的三個安全焦點
🎯
工具要窄
讓模型呼叫接近任務的動作，減少模糊組合。
🔐
權限要細
用 scopes 控制帳戶、資料與操作範圍。
🧾
結果要可追蹤
重要動作需要記錄、回滾或人類確認。

這也是為什麼 MCP 不能只交給行銷或 demo 團隊。它碰到的是產品設計、平台治理、安全工程與商業責任。AI 能做越多事，軟體公司越需要清楚說出「哪些事永遠不能只靠模型決定」。

PART 4 ｜ API 不是舊世界

AI 需要 MCP，
但 MCP 仍然站在 API 上

Stainless 的位置很有代表性。它原本處理的是 API、SDK 與開發者體驗，現在開始處理 MCP servers。這不是從舊工具跳到新工具，而是同一件事往上移一層：讓軟體和軟體溝通，變成讓 AI 和軟體溝通。

Alex 的觀點不是「API 過時了」。相反地，好的 MCP 往往需要更好的 API。底層 API 如果權限粗、錯誤處理混亂、資料模型不穩，MCP 會把問題放大。模型只會更快、更頻繁地撞上原本的設計缺口。

AI 原生服務不是只加一層 MCP
底層 API能被可靠執行清楚的資料模型、錯誤狀態、授權與稽核。
SDK 與文件能被人類維護工程師仍要能理解、測試與修正系統。
MCP 工具能被模型選對名稱、描述、參數與範例都要符合實際任務。
產品體驗能被使用者信任重要操作需要確認、提示與可恢復的狀態。

這讓「AI 原生」變得更具體。不是把聊天框放到產品裡，而是讓產品每個關鍵能力都能被清楚描述、授權、呼叫、記錄。MCP 是入口，API 是地基。

PART 5 ｜ 一次性動作會變成正式軟體

AI 先幫你做一次，
下一步就是把它變成系統

訪談後段談到一個重要轉折：很多 AI 動作一開始像是一次性任務。模型替你查資料、呼叫工具、產生結果。但只要這個任務重複發生，公司就會想把它變成正式流程，加入權限、監控、回滾、測試和產品介面。

這也是 MCP 會影響軟體公司的原因。過去的自動化通常由工程團隊從內部開始。現在使用者可能先用 AI 做出一條工作路徑，再要求產品把這條路徑變安全、變穩定、變成多人可用。軟體邊界會從「產品提供什麼功能」變成「哪些 AI 動作值得產品化」。

AI 會把很多「臨時操作」推向「正式軟體」。公司若沒有設計工具邊界與權限模型，臨時操作就會變成正式風險。

因此，MCP 不是一波開發者工具熱潮而已。它是在回答 AI 如何進入既有網路。答案不會只是更多工具，而是更清楚的動作、更細的授權，以及能讓人類對結果負責的產品設計。

AI 原生網路的重點不是讓模型碰到更多按鈕，而是讓每個按鈕都有清楚目的、權限邊界與責任記錄。

Every 這集把 MCP 從協定名稱拉回產品設計：能不能被模型使用，最後取決於軟體公司如何定義安全可用的動作。

如果你要替產品設計 MCP，
第一個該先檢查什麼？

選完之後，分享你的觀點

你的觀點

想看原始訪談？

這頁整理自 Every 於 2026 年 5 月 20 日發布的 YouTube 影片。原始訪談保留 Alex Rattray 與 Dan Shipper 對 MCP、API、工具設計、OAuth scopes 與 AI 原生網路的完整討論。

閱讀完整文章 →