Model Context Protocol（MCP）是一套開放協定，讓 AI 應用以一致方式發現並使用外部資料、提示與工具。它降低每個 Agent 都要為每個系統重寫整合的成本，但只規範「如何交換能力與 context」；資料是否正確、工具能做什麼、誰能核准，仍由 host、server 與組織治理決定。
把 MCP 想成 Agent 的連接規格，不是智慧本身
USB 的價值不是讓硬碟變聰明，而是讓不同電腦用共同規格辨識裝置。MCP 的角色相近：一端是 AI 應用，另一端是提供資料或能力的服務；雙方透過標準訊息描述「我有哪些東西」與「你要怎麼呼叫」。
依 MCP 最新正式規格（2025-11-25），協定採 JSON-RPC 2.0，主要參與者有三個：
- Host：協調使用者、模型與多個連線的 AI 應用。
- Client：host 內與單一 MCP server 維持連線的元件。
- Server：提供 context 或可執行能力的程式。
Server 可暴露三種核心 primitive：
| Primitive | 它提供什麼 | 資料分析例子 |
|---|---|---|
| Resources | 可讀取的 context 或資料 | schema 文件、指標定義 |
| Prompts | 可重用的訊息模板或工作流入口 | 月報分析提示模板 |
| Tools | 可由模型請求執行的函式 | 查詢資料、建立 Plan、匯出結果 |
Host 也可能提供 roots、sampling 或 elicitation 等能力。實際支援哪些功能，取決於 client 與 server 在連線初始化時協商的 capability；「支援 MCP」不代表支援所有 primitive。
一次工具呼叫實際發生什麼事？
以「查詢訂單資料」為例，可以拆成五步：
- Host 與 server 建立連線並交換協定版本、capabilities。
- Client 詢問 server 有哪些 tools 或 resources。
- Server 回傳工具名稱、描述與輸入 schema。
- 模型根據使用者目標提出 tool call，host 依權限與同意流程決定是否送出。
- Server 執行後回傳結果，模型再解讀或進行下一步。
MCP 架構文件 特別指出，MCP 專注於 context exchange，不規定 AI 應用如何使用 LLM 或管理取得的 context。也就是說，同一個 MCP server 接到兩種 Agent harness，可能產生完全不同的審批、記錄與錯誤處理體驗。
這也是「MCP 是 Agent 的 USB」類比的限制：MCP 工具可能查資料、寫檔甚至執行高影響操作，遠比一般周邊裝置敏感。工具描述也不能自動視為可信。
MCP 解決了三個整合問題，沒有解決四個治理問題
MCP 的直接價值包括：
- 可發現性：Agent 能用標準方法列出能力，而非把每個 API 都硬寫進 prompt。
- 可組合性：同一個 host 能連多個 server，server 也能被不同 client 使用。
- 介面一致性：lifecycle、工具 schema、進度、取消與錯誤有共同語言。
但接通之後，仍要分別回答：
- 權限：這條連線能讀、能寫，還是能做管理操作？
- 正確性：工具回傳的資料是否新鮮，欄位與指標定義是否一致？
- 治理：高風險動作何時需要人核准，活動是否可查？
- 信任：server、tool description、輸入內容與 credential 由誰管理？
正式規格的安全章節也明確要求使用者同意與控制、資料保護及 tool safety，並說明協定本身無法在 protocol layer 強制完成所有安全原則。換句話說，MCP 是治理的載體之一，不是「接上就安全」的認證。
為什麼 2026 年更值得關注 MCP
MCP 2026 Roadmap 將 transport scalability、agent communication、governance maturation 與 enterprise readiness 列為優先方向。Roadmap 也坦白指出，企業部署正在遇到 audit trail、SSO 整合授權、gateway 行為與設定可攜性等問題；其中多數仍是發展方向，不該寫成已經由 core spec 完整解決的功能。
這個訊號的重要性在於：MCP 正從「本機工具整合」走向更廣的 production use，而規模越大，host 邊界、credential、approval 與 audit 就越不能靠預設值處理。
Lantide Data 的兩種 MCP 方向，不要混在一起
Lantide Data 同時支援兩個相反方向的整合：
方向一：Lantide 作為 MCP client
在 MCP Sources 中，Lantide 連到外部 MCP 來源，透過 stdio 或 HTTP 設定取得資料，再物化為側邊欄可查詢的表。這適合傳統 PostgreSQL／MySQL／SQLite 連線以外的資料或 API；如果只有標準資料庫與本機 CSV，未必需要 MCP Sources。操作與狀態見 MCP Sources 入門。
方向二：Lantide 作為本機 MCP Server
Lantide 也能讓 Codex、Claude、Cursor 等支援 Streamable HTTP MCP 的外部 Agent 連入其分析工作面。外部 Agent 可以依連線的 Observe／Execute／Admin 能力上限，讀取或建立 Plan、SQL evidence 與 Report；Lantide GUI 則保留審閱、Activity 與 audit。Server 僅綁定本機 127.0.0.1，bearer credential 只應交給信任的本機 client，不能貼到公開或遠端環境。詳見 外部 Agent 與 MCP Server 指南。
MCP Server 的連線、recovery 與 client compatibility 行為可能隨版本調整，導入前應以當版 User Guide 和實測結果為準。
兩者都不會讓 Agent 自動取得無限權限。MCP Sources 的來源權限由來源本身與設定決定；外部 Agent 的 access mode 由 connection 建立時設定，而 Plan 的 Approve & Execute 只核准該 Plan，不會提升 connection mode。
選 MCP 整合前的四問
評估任何 MCP server，不要只看「能不能連」，先問：
- 這個 server 暴露哪些 resources 與 tools？每個 tool 的副作用是什麼？
- credential 存在哪、多久過期、如何 rotate 或 revoke？
- host 是否在呼叫前顯示清楚的參數與同意介面？
- 執行後留下哪些 artifact、activity 與 audit，可否重現關鍵結果？
如果四題答不完整，先用測試資料與唯讀權限驗證。協定能縮短整合時間；可信任的 Agent 工作流，仍要由具體的 scope、approval 與 evidence 補齊。