生成式人工智慧（Generative AI）正從單純問答，逐步朝向能自主規劃、使用外部工具並完成多步驟任務的AI代理（AI Agent）發展。當AI代理需要同時存取資料庫、文件系統、搜尋服務、開發工具及企業應用時，技術挑戰也由「模型能否呼叫工具」，進一步轉變為「不同模型與工具如何以一致方式連接、發現與管理」。
從開發生態觀察，推出模型上下文協定（Model Context Protocol, MCP）的Anthropic指出，其Tier 1 SDK截至2026年7月每月下載量已接近5億次，TypeScript與Python SDK累計下載量均突破10億次，反映模型與外部工具標準化連接的採用程度持續提高。過去開發者多透過API或Function Calling逐一建立模型與外部服務的連接，但工具數量增加後，容易形成大量客製化介面。MCP即針對此問題提出標準化連接機制。2026年7月28日發布的新版規格，進一步調整核心通訊、路由、快取、長任務與授權機制。相較早期著重工具介面的標準化，新版MCP已開始處理AI代理規模化部署時的連線、效能與治理問題。
一、AI代理興起，「如何連接工具」成為新的技術問題
傳統大型語言模型（Large Language Model, LLM）的核心能力在於理解輸入並生成內容，即使搭配檢索增強生成（Retrieval-Augmented Generation, RAG），主要目的仍是取得外部資訊後產生答案。AI代理則進一步加入任務規劃與工具使用能力，模型需要根據目標判斷下一步行動，並可能反覆呼叫搜尋、資料庫、程式執行環境或其他應用服務。
例如，使用者要求AI代理進行「彙整專案進度並安排會議」，代理可能先查詢專案管理系統，再取得行事曆資料、整理可用時段，最後呼叫行事曆服務建立會議。此時模型主要負責理解任務、規劃及工具選擇，真正的資料取得與操作則由外部系統執行。
Function Calling可以讓模型按照預先定義的函式名稱與參數格式呼叫工具，但當AI代理需要連接的工具與外部服務持續增加時，開發者仍須分別處理工具描述、資料格式、連線及權限設定。MCP所要處理的，正是不同的AI應用如何以一致方式發現、描述與使用外部工具，藉此減少模型、應用與服務之間反覆客製化整合的情形。
二、MCP以Host、Client與Server建立工具互聯架構
MCP採取Host、Client與Server分工架構。Host通常是使用者直接操作的AI應用，負責模型整合、任務協調及安全控制；Host中的MCP Client負責與MCP Server通訊；MCP Server則將外部資料或功能以標準化方式提供給AI應用。
MCP Server可公開Tools、Resources及Prompts等能力。其中Tools是模型可呼叫的功能，例如資料查詢、API操作或檔案處理；Resources提供檔案、資料庫內容等Context；Prompts則提供可重複使用的提示範本或預先定義的互動內容。這種設計使AI應用可先取得Server提供的能力，再依任務需要選擇適合的工具，而不必直接理解後端系統的實作方式。
其技術意義在於將「模型推理」與「工具實作」適度分離。例如同一AI應用可連接文件搜尋、資料庫及開發工具等不同MCP Server；不同AI應用也可依相同協定使用這些Server。相較於每一項AI應用各自整合API，相較於各AI應用自行整合API，MCP的價值在於把工具描述與通訊方式抽離成較一致的介面，使同一項外部能力更容易被不同AI應用重複使用。當模型、應用與工具數量持續增加時，這種設計有助於降低多對多整合帶來的複雜度，也為後續規模化部署提供較一致的連接基礎。
三、新版MCP轉向無狀態核心，強化大規模部署能力
2026年7月28日發布的新版MCP規格，最重要的變化之一，是核心通訊模式由較依賴雙向、有狀態連線的設計，轉向以request/response為主的無狀態架構。新版移除原本的initialize∕initialized交換流程與Mcp-Session-Id，每項request均攜帶協定版本、Client身分及相關能力資訊，因此不同請求可被分派至不同Server instance處理。
這項改變直接影響MCP Server的部署方式。過去若依賴會話（session），水平擴充時可能需要黏性工作階段（sticky session）或共享session storage；無狀態架構則較容易搭配既有HTTP Load Balancer進行水平擴充，使MCP Server更容易沿用既有HTTP基礎設施與分散式服務部署方式。
新版規格另加入標頭驅動路由（Header-Based Routing），將method與tool name放入Mcp-Method及Mcp-Name HTTP Header，使API Gateway、速率限制器（Rate Limiter）或網頁應用程式防火牆（Web Application Firewall）可依Header進行路由、流量限制或授權判斷，而不必解析完整JSON (JavaScript Object Notation)內容。
此外，tools∕list、prompts/list、resources/list及resources∕read等回應新增快取提示，使Client可降低重複取得工具與資源清單造成的網路流量與延遲。這些改變顯示，MCP的設計焦點已不只是「讓模型能連接工具」，而開始處理AI代理規模化部署後的擴充性與效能問題。
表1 AI代理工具連接模式與MCP架構演進比較
資料來源：Model Context Protocol（2026），資策會MIC ITIS研究團隊整理(2026/8)。
由表1可發現，MCP的技術演進並非單純增加更多工具呼叫功能，而是逐步處理AI代理規模化部署後產生的架構問題。早期MCP主要著重於降低AI應用與外部工具之間的整合差異，使AI應用可透過Client與Server機制發現及使用外部能力；2026新版規格則進一步將核心協定轉向無狀態架構，並加入路由、快取、多輪請求與長時間任務管理等機制。整體來看，MCP關注的問題已從「如何讓AI呼叫工具」，延伸到規模化部署後的連線效率、工作管理與安全控制。
四、從單次工具呼叫走向長時間Agent工作流程
實際AI代理任務不一定能在單次工具呼叫內完成。例如大型程式碼分析、跨來源研究或資料處理可能持續較長時間，期間還需要取得進度、更新任務或取消執行。
新版MCP因此將Tasks納入正式Extensions framework。伺服器可在工具呼叫後提供task handle，再由客戶端（Client）透過tasks∕get、tasks∕update及tasks∕cancel等方式管理工作生命週期。這代表MCP處理的範圍開始由「呼叫工具並取得結果」，延伸至「啟動、追蹤與管理一項工作」。
新版同時導入多重來回請求（Multi Round-Trip Requests, MRTR），讓Server在處理請求期間需要額外資訊或使用者確認時，不必維持持續開啟的雙向連線，而可要求客戶端補充資訊後重新送出請求。這項設計兼顧無狀態架構與多輪互動需求，例如AI代理執行高風險操作前，可先要求使用者確認。Tasks與MRTR使MCP處理的範圍超出單次工具呼叫，開始涵蓋任務啟動、持續互動、狀態追蹤與完成等流程。這反映MCP的定位正在改變：除了負責工具連接，也開始支援較完整的Agent工作流程。
五、工具互聯規模擴大，授權與信任成為技術關鍵
MCP提高工具互通性的同時，也擴大AI代理的安全議題。傳統聊天模型的錯誤多半停留在輸出內容，但具備工具使用能力的AI代理可能讀取資料、修改檔案、呼叫API甚至執行程式，因此工具權限與身分驗證會直接影響系統安全。
新版MCP持續強化授權（Authorization）設計，包括要求客戶端驗證授權伺服器（Authorization Server）的issuer資訊，並將用戶端憑證（Client credentials）與其簽發來源綁定；同時推動Client ID Metadata Documents(CIMD)等客戶端註冊機制，以降低不同授權來源間發生混用的風險。當AI代理從讀取資訊進一步具備操作能力後，安全管理的範圍也隨之擴大。系統除了要確認使用者與代理能否存取資料，也必須界定代理可以代表使用者執行哪些操作。因此，授權機制不再只是附加的安全功能，而是MCP進入規模化部署後的重要架構條件。
此外，MCP規格亦強調使用者同意與控制、資料隱私及工具安全；在授權設計上，則要求依最小權限原則選擇適當的範圍（scope）。AI代理能使用的工具越多，主機（host）便越需要掌握哪些伺服器可信、哪些資料可以被存取，以及哪些操作必須取得使用者確認。因此，MCP在處理工具互聯之外，下一階段技術重點將進一步延伸至身分、授權、信任邊界及操作治理。
六、結論
生成式AI由問答走向AI代理，使技術發展焦點不再只有模型本身的推理與生成能力，也包含模型能否可靠連接外部資料與工具。MCP透過主機、客戶端與伺服器架構，將分散於不同AI應用中的工具整合方式轉化為較一致的能力交換機制；2026年新版規格再進一步導入無狀態核心、Header路由、快取、多輪請求、Tasks及授權強化機制，顯示MCP正由工具介面的標準化連接，逐步朝支援AI代理規模化部署的基礎協定層演進。
綜合觀察，此波MCP架構調整的重點，主要在回應AI代理規模化部署後出現的幾項實際問題，包括分散式環境下的連線狀態負擔、長時間與多步驟任務的管理，以及身分、權限與執行邊界的控制。也就是說，AI代理基礎架構關注的問題，已從「模型能否使用工具」，進一步延伸到工具能否在大規模環境下被穩定管理與安全使用。後續MCP能否成為跨模型、跨工具的通用連接層，仍需觀察協定標準化程度、工具生態系採用範圍，以及授權與安全治理機制的成熟度。