MCP 不只是 Connector：它正在變成 Agent Infrastructure 的能力邊界

摘要

MCP（Model Context Protocol）在 2026 年已不只是「讓 Agent 接外部 API」的 connector 規格。對技術人員而言，更準確的定位是：MCP 是 Agent 與外部系統之間的能力協議層（capability protocol），而真正的產品化價值來自它上方與下方的工程化邊界設計。

MCP 本身提供標準化的連線模型、訊息格式與能力抽象，讓 Host / Client / Server 可以用一致方式交換 context、tools、resources、prompts 等能力。
MCP 的 production 難題不是「工具能不能接上」，而是「Agent 應該看見多少能力、何時看見、由誰授權、在哪裡執行、如何觀測與治理」。
目前大廠與社群的收斂方向，是把 MCP 從大量裸露工具清單，推向 tool search / progressive disclosure、Code Mode / code execution、gateway / control plane、policy-based capability surface 等基礎設施設計。

1. MCP 當前扮演的角色：從 Connector 到 Agent Infrastructure

早期理解 MCP，容易把它看成「AI 版 USB-C」：只要各系統都實作 MCP server，Agent client 就能用標準方式接上資料與工具。這仍然正確，但對開發者來說已經不夠完整。

依照官方規格，MCP 是一個用來讓 LLM 應用與外部資料源、工具整合的 open protocol；它使用 JSON-RPC 2.0 訊息，讓 Host、Client、Server 建立通訊。Host 是發起連線的 LLM 應用，Client 是 Host 裡的連接器，Server 則提供 context 與 capabilities。

因此 MCP 的實際角色可以拆成三層：

Protocol layer：定義 Host / Client / Server、transport、JSON-RPC message、capability negotiation。
Capability layer：把外部系統包成 tools、resources、prompts 等可被 Agent 理解與調用的能力。
Infrastructure layer：在 production 中補上搜尋、授權、路由、沙箱、觀測、生命週期管理與成本控制。

真正產生強大價值的是第 2、3 層：MCP 讓工具介面標準化，但「哪些能力要直接暴露、哪些要封裝成高階動作、哪些要透過 gateway 管理」仍是工程與產品設計問題。

2. MCP 的基本結構：Host、Client、Server 與能力原語

一個 MCP 系統通常可以這樣看：

User / Developer
      │
      ▼
Host：AI IDE、Chat App、Agent Runtime
      │
      ├─ MCP Client A ── MCP Server A：GitHub / Repo / Issue / PR
      ├─ MCP Client B ── MCP Server B：Database / BI / Warehouse
      └─ MCP Client C ── MCP Server C：Internal business system

2.1 Host

Host 是使用者實際互動的 AI 應用，例如 IDE agent、chat agent、internal automation agent。Host 負責：

管理使用者會話與模型上下文。
建立 MCP client 連線。
決定哪些 server 與 capability 對當前任務可見。
實作使用者同意、授權 UI、資料保護與工具調用控制。

2.2 Client

Client 是 Host 內部對某個 MCP server 的連接器。它負責：

初始化連線與能力協商。
將 server 暴露的 tools / resources / prompts 轉成 Host 可管理的能力。
將模型產生的 tool call 轉送到 server，並把結果送回 Host / model。

2.3 Server

Server 是能力提供者。它把真實系統的資料與操作包成 MCP 能力，例如：

search_knowledge_base
get_customer_orders
calculate_refund_amount
issue_refund
read_repository_file
create_pull_request

Server 不只是 API wrapper。好的 MCP server 會把內部 API 重新整理成 Agent-friendly capability surface：命名清楚、schema 穩定、權限邊界明確、錯誤可恢復、輸出適合模型消化。

3. MCP 發揮價值的關鍵：Capability Surface 設計

MCP 產品化時，最重要的問題不是「多接幾個 tool」，而是：

Agent 看見什麼，它就會以為自己能做什麼；Agent 看不見什麼，系統就必須在後端替它完成或禁止。

這就是 capability surface 設計。它至少包含四個決策：

3.1 粒度：細工具還是高階任務？

客服系統可以暴露很多細工具：查 FAQ、查訂單、查物流、試算退款、執行退款、更新工單、寄通知信。但如果全部直接攤給 LLM，會出現三個問題：

工具定義吃掉 context。
模型選錯工具或漏步驟。
敏感底層 API 被過度暴露。

更適合 production 的做法通常是混合：

對探索性、低風險任務提供細工具。
對高風險、多步驟、固定流程任務提供高階 workflow tool，例如 resolve_refund_case。
把權限檢查、防詐欺、審批、人為確認放在 server / gateway / workflow 層，而不是期待模型每次都記得做。

3.2 可見性：一開始載入多少工具？

過去 tool calling 常把所有 tool definitions 一次塞進 context。工具數一多，模型尚未讀使用者需求，就先消耗大量 token 在工具描述上。

目前的主流緩解方向是 progressive disclosure：

初始只載入工具搜尋器、核心工具或 server instructions。
需要時再搜尋、載入相關工具定義。
支援 name-only、description、full schema 等不同詳細程度。

Anthropic 的 tool search / deferred loading 走的是這條路：延遲載入工具先不進 prompt prefix，模型需要時透過 tool search 找到 tool_reference，API 再展開完整定義。Claude Code 的 MCP tool search 也把 MCP tools 預設延遲，只有用到的工具才進入上下文。

3.3 執行位置：模型直接串工具，還是寫程式在沙箱裡串？

當任務需要多次 tool call、資料過濾、迴圈、重試、join、aggregation 時，讓模型逐步呼叫工具很浪費：每個中間結果都要進出 context。

Code Execution / Code Mode 的核心想法是：

把 MCP tools 呈現成 typed API 或 SDK。
讓模型寫程式呼叫這些 API。
在受控沙箱裡執行程式。
只把必要摘要或最終結果回傳給模型。

這會把「每一步都經過 LLM」改成「LLM 產生一段可檢查的計畫，執行環境負責跑完」。好處是：

工具定義可按需載入。
大資料可在 execution environment 裡過濾，不進模型上下文。
loop、condition、retry、error handling 可用一般程式結構完成。
中間敏感資料可留在 runtime，只有明確 log / return 的內容進入模型。

代價是需要沙箱、資源限制、監控、approval / rollback 機制，以及明確的 side-effect policy。

3.4 控制面：MCP server 越多，誰負責管理生命週期？

當組織內有數十個 server、數百個 tools、不同 team 維護不同能力時，MCP 需要 gateway / control plane。

Microsoft MCP Gateway 代表這個方向：它把 MCP server 放到 Kubernetes 環境中管理，提供 session-aware routing、authorization、lifecycle management、telemetry、observability 等 enterprise integration points。這類 gateway 的價值不是改變 MCP 協議，而是補齊 production 必需的營運面：

Server 註冊與版本管理。
Session affinity / stateful routing。
Tool registration / dynamic routing。
權限、角色、審計、觀測。
部署、更新、刪除與健康檢查。

4. MCP 的主要缺點與技術社群的緩解方式

4.1 缺點：Context inflation

問題：工具定義、schema、描述、範例都會吃 context。多 server、多 tool 場景下，成本、延遲與模型注意力都會惡化。

緩解：

Tool search / deferred loading。
Server instructions 做能力分類摘要。
將最常用 3–5 個工具保留 upfront，其餘延遲載入。
按任務動態選擇 toolset，而不是每次載入全宇宙。
對大型 API 改用 Code Mode 的 search() / execute() 小表面。

4.2 缺點：Tool selection accuracy 下降

問題：工具超過一定數量後，模型更容易選錯、漏選或混淆相似工具。

緩解：

清楚、一致、有 namespace 的工具命名，例如 github_create_issue、slack_post_message。
描述中放入使用者會用的任務語彙。
用 search / BM25 / embeddings 先縮小候選工具集合。
把固定業務流程封裝成高階 tool，減少模型自行拼裝流程。

4.3 缺點：Intermediate result bloat

問題：大型文件、表格、查詢結果在多步工具鏈中反覆穿過模型，浪費 token，也增加複製錯誤。

緩解：

Code execution：在 runtime 內 filter / map / join / aggregate。
只 console.log 或 return 必要摘要、前幾筆樣本、統計數字。
使用檔案或 runtime state 保存中間結果。
對敏感欄位做 tokenization / redaction，避免原始 PII 進模型。

4.4 缺點：安全與資料外洩風險

問題：MCP tools 可代表任意外部動作，甚至接近任意程式執行。server 描述、tool annotation 不應被無條件信任。若 Host 沒做好授權與同意流程，模型可能讀到或執行超出使用者意圖的操作。

緩解：

Host 端實作明確 user consent 與 review UI。
每個 tool 設定 least privilege scope。
高風險 side effect 要求人工確認或 policy approval。
Gateway 層做 authentication、authorization、audit logging。
對 server trust level 分級：trusted internal、third-party、experimental。
對 code execution 加 sandbox、resource limits、network policy、filesystem policy、timeout 與監控。

4.5 缺點：多步 orchestration 容易出錯

問題：退款、部署、資料遷移、客服結案這類流程有固定順序與例外處理；若交給模型每次臨場拼裝，可靠性不足。

緩解：

將穩定流程下沉到 backend workflow / tool。
MCP 暴露「業務語意動作」，不是只暴露底層 CRUD。
用 code execution 表達可檢查的流程計畫。
對 workflow 加 idempotency key、dry-run、rollback、approval gates。

4.6 缺點：Server 與 session lifecycle 管理不足

問題：本機 demo 可以直接啟動 server；企業 production 需要多租戶、水平擴展、stateful session、版本管理與觀測。

緩解：

MCP gateway / reverse proxy。
Control plane 管理 server lifecycle。
Session-aware stateful routing。
Telemetry、logs、metrics、traces。
Tool registry 與 dynamic routing。

5. 一個可落地的 MCP 產品化分層

┌──────────────────────────────────────────────┐
│ Product / UX Layer                            │
│ - 使用者授權、審批、工具可見性、任務模式       │
├──────────────────────────────────────────────┤
│ Agent Runtime / Host                          │
│ - context management、tool search、prompt cache │
├──────────────────────────────────────────────┤
│ Capability Surface                            │
│ - tools、resources、prompts、workflow tools     │
├──────────────────────────────────────────────┤
│ Execution Layer                               │
│ - direct call / code execution / sandbox       │
├──────────────────────────────────────────────┤
│ Gateway / Control Plane                       │
│ - authz、routing、registry、lifecycle、observability │
├──────────────────────────────────────────────┤
│ Enterprise Systems                            │
│ - DB、SaaS、internal API、knowledge base        │
└──────────────────────────────────────────────┘

這個分層的重點是：不要把 MCP server 當成「把所有 internal API 攤開」的地方。MCP server 應該是能力邊界；gateway 是營運邊界；Host 是使用者意圖與同意邊界；execution runtime 是可控自動化邊界。

6. 給開發者的設計檢查清單

Tool / Capability 設計

Tool name 是否穩定、具 namespace、可搜尋？
Description 是否說明何時用、何時不用、參數語意與副作用？
是否有高階 workflow tool 可以取代一串固定細工具？
是否把 dangerous operation 和 read-only operation 分開？
是否支援 dry-run / preview？

Context Engineering

工具數是否超過 10 個或工具定義超過 10k tokens？若是，應考慮 tool search。
是否只 upfront 載入核心工具？
server instructions 是否足以讓模型知道何時搜尋？
大型結果是否先在 runtime 過濾再回模型？

Security / Governance

每個 server 的 trust level 是否明確？
是否有使用者同意與高風險確認？
是否有 least privilege token？
是否有 audit log、trace id、session id？
code execution 是否有 sandbox、timeout、resource limit？

Operations

server lifecycle 是否可部署、更新、回滾、刪除？
stateful session 是否需要 affinity？
gateway 是否能做 auth、routing、telemetry？
tool schema 變更是否有版本策略？

7. 結論

MCP 的長期價值不在於「讓 LLM 多幾個工具」，而在於它提供了一個標準化切面，讓 Agent 能以可治理、可擴展、可觀測的方式進入既有軟體系統。

但 MCP 本身不會自動解決產品化問題。真正的工程重點是：

用 capability surface 控制 Agent 看見的世界。
用 progressive disclosure / tool search 控制 context 成本。
用 code execution / Code Mode 控制多步流程與中間資料。
用 gateway / control plane 控制路由、權限、生命週期與觀測。
用 consent、policy、sandbox 控制安全與副作用。

換句話說，MCP 是 Agent Infrastructure 的協議入口；它的強大，來自它讓我們能把「模型智慧」與「軟體工程邊界」清楚接合，而不是讓 LLM 直接面對整個系統的混沌。

摘要