為什麼 LLM 需要連接外部世界的協定？從 MCP 看 M×N 整合問題

當每個 AI 應用都要自己接工具，問題會怎麼變大？

大型語言模型（Large Language Model，LLM）擅長根據輸入產生文字，卻不會因為「知道」某個資料庫或天氣 API 的存在，就自動擁有讀取和操作它們的權限。真正的應用通常還需要把模型接到檔案、資料庫、搜尋服務或其他可執行功能。

如果每個 AI 應用都用自己的格式連接每個外部系統，新增一個應用或一個工具，就可能需要重新製作許多配對整合。這可以用一個簡化模型表示：M 個應用和 N 個外部系統，若每一對都各自整合，就是 M×N 條連線。這不是所有專案都會實際長成的精確成本公式，但它清楚指出了維護負擔的來源：介面被重複發明。

MCP 把哪一段介面固定下來？

Model Context Protocol（MCP）是一套開放協定，定義 AI 應用如何發現並使用外部系統提供的能力。它不是一個模型，也不是把資料自動送進模型的資料庫；它提供的是一種共同的訊息和能力描述方式，讓不同的 Host、Client 與 Server 可以在同一套規則下互通。

因此，MCP 的簡化效果比較接近 M+N：每個應用實作一次 MCP Client，每個能力提供者實作一次 MCP Server。這個模型仍然需要傳輸、權限、錯誤處理和各自的業務邏輯，但不必為每個應用與每個工具重新設計一套協定。

這也是「AI 應用程式的 USB-C」這個比喻有用、但不能照單全收的地方：USB-C 描述接頭標準，MCP 描述訊息與能力的互動方式；兩者都不會替使用者決定裝置是否值得信任，也不會自動解決供電、權限或資料品質問題。

MCP 的價值不只是少寫幾個轉接層

標準介面讓生態系統中的角色可以分工。應用程式可以管理模型、使用者介面與同意流程；MCP Server 可以專注在一個明確的資料或工具邊界；Client 則把兩邊的訊息接起來。後面的篇章會拆開這三個角色，這裡先保留最重要的邊界：Server 不應因為被接上，就取得整段對話或所有其他 Server 的資料。

這個邊界也提醒我們，不應把「支援 MCP」寫成「安全」或「可以可靠完成任務」。MCP 能標準化發現、呼叫與回傳資料的方式；是否允許一個工具執行、使用者是否看得到確認提示、資料是否正確，仍然是 Host、Server 與部署環境的責任。即使整合數量從 M×N 降到接近 M+N，錯誤權限仍然可能造成真實損害。

今天建立的模型，下一篇要補什麼？

現在可以先用一句話記住 MCP：它是 AI 應用和外部資料、工具之間的共同協定，主要價值是讓整合可以組合，而不是讓模型突然擁有外部世界的權限。

下一個問題自然是：這個共同協定裡，誰負責協調，誰負責連線，誰提供能力？答案是 Host、Client、Server 三個角色；它們的責任分界比「客戶端對伺服器」這個簡化說法更重要。

來源與版本邊界

本文的角色定義與安全邊界以 MCP 2026-07-28 Architecture 為準；MCP 的基礎訊息模型見 MCP 2026-07-28 Overview。M×N 與 M+N 是幫助理解整合成本的簡化模型，不是對所有實作的量測結果，也不代表 MCP 自動提供授權或安全保證。