MCP 在 API 之上：模型如何發現工具，而不是背下每一個端點

過去幾十年，API 是系統與系統之間的黏著劑：定義端點、送請求、拿可預期的回應。乾淨、可版本、可鉴權——對程式呼叫程式幾乎是正確抽象。

大型語言模型出現後，呼叫模式變了。模型可能串十個端點、讀非結構化結果、再決定下一步。它需要的不只是「有權限打 HTTP」，還需要當下環境裡有什麼能力、參數長什麼樣、回傳意味著什麼。於是我們開始把整本 API 文件塞進 prompt，或為 Gmail、Notion、Jira 各寫一套膠水與教戰手冊。這有效，但不可擴展。

MCP（Model Context Protocol，模型上下文協定） 試圖提供另一層：讓模型以標準方式發現並使用工具，而不是每次整合都由開發者手把手重教。這是「Agent 系統工程」系列的第三篇——接在記憶分層與長時程執行之後，補上工具如何進到代理手裡。

先澄清：MCP 不取代 API

最常見的誤解是「MCP vs API，誰贏誰輸」。更精確的說法是：

API 仍是櫃子裡的實物與鎖；MCP 比較像給模型一張機器可讀的即時地圖：有哪些抽屜、各需要什麼形狀的鑰匙、拿出來會是什麼。地圖不能代替櫃子；但沒有地圖，模型只能靠你在 prompt 裡反覆口述。

因此：MCP 建立在 API（與其他工具實作）之上，取代的是「模型與 API 之間那層特製中介與提示詞教學」，不是取代你的後端。

為什麼 API 對模型不夠「友善」

API 假設雙方都清楚預期：文件寫了、SDK 封了、錯誤碼對過。模型卻常在標籤不全的現實裡推理——它不知道該呼叫哪個函式，直到你告訴它；你一改版本，prompt 裡的教戰手冊就過期。

客服代理若要同時碰 Gmail、Notion、Jira，傳統路徑是：

• 各寫整合與授權、分頁、限流
• 在系統提示裡寫：「建立 Jira 時打這端點、帶這些欄位……」
• 每個新工具再複製一次

有了 MCP 路徑，理想狀態是：各服務提供相容介面，模型取得工具名稱、參數、型別、描述等中繼資料，在推理中決定何時用哪個工具。你提供的是環境與能力，不是一百份客製 prompt 膠水。

核心差異可以收成一句：

API 是程式碼層級的契約；MCP 是模型與其工具環境之間的標準化協定。
何時呼叫的邏輯，得以從「寫死在應用程式裡」部分上移到「模型在約束下的推理」——前提是 schema 與權限設計得當。

對 Agent 開發者意味著什麼

1. 標準化 ≈ 互通的「HTTP 時刻」

HTTP 讓網站與客戶端用共享語言說話。MCP 想為 AI 工具生態做類似的事：少一點每家自創外掛格式，多一點可組合的 server。代理本體可以保持輕量，能力透過接入的 MCP server 擴張——搜尋趨勢、企業內部 API、瀏覽器、資料庫……對代理來說，理想上「呼叫一個 MCP 工具」與「呼叫本地 function tool」體驗一致。

2. 整合從 N×M 變成「實作一次介面」

過去：每個模型產品 × 每個內部系統 = 客製整合。
方向：系統側實作 MCP 暴露能力，任何相容客戶端（代理 runtime）即可發現使用。這是「隨插即用層」敘事的來源——仍取決於生態是否真的長出來，以及權限模型是否跟得上。

3. 與長時程、記憶的接縫

工具不是無狀態玩具：一次 Trends 查詢可以只是短呼叫；一次「建立工單並等人審核」仍要走系列②的檢查點與休眠。MCP 解決的是如何描述與呼叫能力；Session／State／Profile 解決的是過程與人是否還記得。兩者疊加，才是可上線的 Agent。

實務上仍要想清楚的風險

MCP 新，坑也真實：

• 權限與資料外流：模型可發現的工具，若 scope 過寬，等於擴大攻擊面與誤用面。
• 幻覺參數與幻覺成功：schema 降低亂猜，但不消滅錯誤推理；關鍵寫操作仍要確認與審計（系列②的評估器）。
• 生態與版本：server、客戶端、傳輸與安全機制仍在快速演進；「寫一次永遠通」過度樂觀。
• ** determinism 邊界**：API 擅長可預期；模型是機率系統。MCP 服務的是後者的接入方式，不把業務交易變成可以馬虎的事。

治理上的一句話：讓模型發現工具，不代表讓模型擁有無限工具。 白名單、環境隔離、人類閘門，與「會不會用 MCP」同樣重要。

和前兩篇如何組成一張圖

使用者目標
    ↓
記憶分層（①）：Session / State / Profile / Memory Bank
    ↓
長時程控制（②）：狀態機 · 休眠喚醒 · 檢查點 · 獨立評估
    ↓
工具接入（③）：本地函式 · 內建搜尋 · MCP 發現的外部能力
    ↓
可觀測的結果與審計

少了①，跨對話與重啟會失憶或亂記。
少了②，跨天流程會空轉或跳步。
少了③，代理只能在封閉的文字世界裡假裝做事。

結語

API 不會因為 MCP 而過時；過時的是「假設呼叫方永遠是另一段寫死的程式碼」。當客戶端變成會推理的模型，我們需要標準方式描述環境裡的能力，並把權限與驗證留在系統邊界上。

MCP 是這一層的重要嘗試：在 API 之上，讓工具對模型可發現、可組合，而不是在 prompt 裡永無止境地重教。它是否成為像 HTTP 那樣的預設，取決於生態與安全是否跟上——但模型原生架構的方向已經很清楚：代理輕、工具標準、狀態外置、評估獨立。

這三篇合在一起，是一組最小但完整的 Agent 系統工程素描：記得住、跑得久、接得上真實世界。

延伸閱讀

• 本系列 ①：Agent 記憶不是一個向量庫
• 本系列 ②：長時程 Agent：休眠、檢查點與獨立評估
• 告別單體式 AI：為什麼多代理人架構是處理複雜任務的務實解法

我是江中喬，專注於 AI Agent Architecture、Memory Governance 與 Cognitive Diversity，持續研究如何打造能夠長期協作、可信任且可治理的 AI 系統。